摘要:    昨天难得几家公司的一些开发人员聚集在一起讨论了些项目实施中的问题，摘录两个比较有趣的问题： 关于工作日志问题：大家都认识到做工作总结的重要性。但是以什么方式做总结，以及在实施情况都不大一致。其中有的是以硬性规定程序员必须每天下班前填写工作日志，每周周五填写周报形式进行总结；有的则是以小型随便的圆桌会议进行项目组内部面对面沟通，周五则在会议室召开例会进行周总结；有的则每周只有周五进行一次例会；有的公司甚至好几次反复执行填写工作日志制度。但是，大家这样做的目标都是为了了解当前项目进度，同时进行计划调整与安排，增进成员间各种交流，方面上级领导视察工作情况，作为绩效考评之一。[个人观点]：填写工作日志是好的，一份好的工作日志确实能反映出很多问题。但是工作日志毕竟只是一种工具，那就要看怎么去用，才能用好它了。ZDNet里就有一篇《工作日志的好处》的文章。但是看似非常好的东西往往在执行过程中就变味了。比如有的工作日志是只填写给项目经理或上级领导看的，那就缺少了成员间技术等多方面交流的环节；有的工作日志简单到只写了“今天我做了XXX事，完成了XXX模块”之类，而没有把碰到的问题，解决的思路，最后的解决方案等写出来，形成了无用的信息垃圾；有的为了写给项目经理或领导看，夸大了自己的工作成绩，如果项目经理片面相信工作日志，就会埋下一定隐患。等等诸如此类问题。所以我觉得能做到象《工作日志的好处》里写的，那么你可以考虑执行。如果在你执行一段时间后，发现碰到上面所说的一些问题，你就该考虑出了什么问题，要不要纠正然后继续执行然后采取其他更适合自己团对的工具与手段？ 测试与版本管理等软件工程实施问题：这个问题可能比较受忽视，但却是真的十分严重的问题。几家公司中，讨论后发现这块比较好知名度也比较高的一家公司，它略去单元测试，他们采用MSF，在版本管理和变更管理上也算达到百分六七十成功了（套用那晚一个PPT上一句话，100%成功的配置管理耗费资源太多，能做到百分六七十就算实际了）。另一家采用类似XP编程方式，单元测试、代码重构、持续集成等都相对靠拢，当然结对编程也没实施（我怀疑结对编程在中国是否存在）。而另外一家也没单元测试，就进行功能测试性能测试，版本管理差不多也在去年初才使用SourceSafe管理。这之间讨论出现的问题就是，版本混乱、BUG跟踪、BUG报告等问题。我印象最深的是上述第一家公司用Excel做BUG跟踪、第二家之前也用Excel后来因为购买了Rational系列软件而采用Rational ClearQuest，但用不起来；第三家不清楚。[个人观点]：我想这个问题更多的是要求要有思想上的转变以及管理上的配合。现在的软件工程中的开发方法开发方式等呈现百花齐放景象，问题在于这些软件工程的方法生搬硬套并不能解决问题。我一直理解软件工程方法为一套实施参考指南，而非一套标准，这是我个人的理解。所以在实施一系列过程中，就应该在实践中去总结出自己最行之有效又合乎实际的方法。你能说出用Excel跟踪BUG的多点坏处，但是在目前情况目前财力物力下，如果管理通顺配合Excel管理BUG跟踪却是十分实际的做法。你能说没采用结对编程，参考实施XP其他有点就无法发挥其优势了吗？...[阅读全文]

摘要: Reflector 4.0 ：真感谢Lutz Roeder一直在升级Reflector，一个.NET反编译软件。这几天最新的4.0版本的反编译效果又有进一步改善，把以前3.x里的变量定义杂乱的问题也修正了。 PInvoke.NET（下载）：一款VS.NET Add-In工具，可让你直接把查找到非托管函数插入代码里，免去了你手工输入的困扰。同时对于非托管函数的声明都可以在http://www.pinvoke.net/里找到。安装完后，在代码文件里可从鼠标右键看到“Insert PInvoke Signatures...”的菜单，点入即可进一步进行插入非托管代码声明的操作。 .NET下的极限编程工具：大家应该都听说过极限编程Extreme Programming(XP)了，它是一种全新的、生气勃勃的开发方式。正如我们大家都这样认为的，软件开发融艺术和工程于一体。虽然目前有着各种各样的开发工具、千奇百怪的开发方式，但是，检验软件的唯一途径，只有测试。测试就要求我们倾听客户的需求，然后编写程序，最后再同客户进行核实，然后不断重复这一过程，直到完成所的工作为止。相对于诸如瀑布式、原形法、分步交付法、RUP等的开发方法，个人认为XP（属于敏捷开发Agile）的厉害之处，在于不仅达到了满足客户需求，而且提高的软件质量（主要体现在降低Bug数量）上。也许，你有看过〈重构〉一书，没错，XP和重构背后都有一个居功至深的人——Kent Beck，因此XP和重构之间的关系想必大家也就清楚了。XP的价值观在于“简单、交流、反馈、勇气”。简单即为在管用能完成事情的前提下，做最简单的事；交流即整个开发过程应该都需要及时交流，这里交流侧重口头交流和能简单明了说明问题的文档交流，屏弃烦琐杂乱的文档和计划等；反馈即整个项目任何时候都需要客户和内部人员的反馈，以保证整个软件不断处于设计与编程与修复BUG的状态中；勇气即要求你必须有足够信心对自己的代码乃至别人的代码进行重构。呵呵，我在刚被XP思想吸引不久，又看到一个测试驱动编程，真感觉变化真快。在.NET下的极限编程主要工具，主要有：NUnit（单元测试工具）：http://sourceforge.net/projects/nunit。     ◇使用NUnit在.Net编程中进行单元测试     ◇在.NET环境中使用单元测试工具NUnit     ◇Get Test Infected with NUnit: Unit Test Your .NET Data Access Layer     ◇Adventures in C#: Using NUnitNAnt（自动编译工具）：http://nant.sourceforge.net/。      ◇“蚂蚁”爬进.NET?     ◇Nantpad——一款不错的NAnt build文件编辑器推荐书籍：《敏捷软件开发—原则、模式和实践》、《极限编程--基础、案例与实施》 改进了一个活动目录操作辅助类ADHelper，以后要改进的将主要在配置信息的存放、AD里对象基本属性操作的增强、与DSML结合等。如有修改会立即更新上来。里面用到了Kaneboy的用户模拟类，在次表示感谢。J...[阅读全文]