Morning@Weblog

近日在BJUG的maillist里听到冰云在感慨“我们做agile的方法还不够细”。其实我感觉，要做到task的细粒度其实也不难，有时候只是大家的惯性思维在作怪。想想把一个任务划分到2小时内，那一定是相对单一而明确，且易于达成的。这也很符合控制理论：当自身控制力不够时，应该想办法通过任务分割的方式，将处理所需的控制成本降低。不过，我觉得这并不代表我们要将一个长周期的安排都细化到小时，原因有二：这本身也是要计入成本的，所谓“计划成本”；情况时常在变化，这么做反而落入了以往传统软工的“陷阱”了，与“over engineering”、“over design”如出一辙。

如何让新人快速融入已有团队，这是团队发展的必修课。正好，最近部门招了些新同事，实践中，让我也有了些许心得。我以为，如下三点实践是具有普遍性的，同时也是值得采纳的：

＊mentor制度。团队中身经百战、阅历丰富的老成员应该担当起新员工的mentor来，不求多，一帮一即可。mentor的作用有二：
　＠ 对于技术新手，大拿们有义务为其指点迷津，答疑解惑，或者甚而对于己所不能者，起码也可以当作倾听者，不时发表自己的见地，这就是XP中的Pair Programming了；
　＠ 对于技术以外，mentor也需要通过言传身教，将团队“积习”传授于新人，比如：开发过程、做事习惯、或者大而话之的“团队文化”；
其实，intern的表现对于mentor来讲也会起到督促和鞭策的效果，毕竟身为mentor，如果连自己都还是半桶水，又如何“震得住”intern呢。所以，自认为还有些心虚者就赶紧在私底下补补课吧：）

＊实战演练。为新人们设计一个有针对性的实战性练习，将必要技能与开发方法融入其中，有专人（老员工）负责监督与跟踪，并在练习结束后给出评价。当然，练习者也要做些总结。期间，结对的mentor也可以适时的做些指导。比如：前阶段在我的提议下，部门给新员工分配了一个JPetStore的改良练习，要求新人们组建起一个虚拟的XP小团队，采用快速迭代的方式，共同协作完成既定任务。从反馈效果来看还算不错。不要认为这样的练习没有必要，相反，为了让新人们快速成长，这样的实验性项目是最好的切入点。你可以大胆的将很多实际工作中需要掌握的技能和工具融入其中，让练习者有切身体会并学有所成。而真正的实际工作，其环境往往不会有如实验练习那么理想，因为要顾及到开发进度和客户压力等诸多外界因素，新工具新技术新方法的引入往往比较谨慎，而人们也往往不能做到时刻专注，长进的效果也就必然会打折扣。作为这一观点的印证，在我前面提到的，部门在给新员工做实战练习的同时，也为另一部门的几位老员工安排了同样的功课，最后从完成的效果来看，则明显差于新员工组建的临时团队。

＊安排力所能及的独立性任务。在熟识了团队氛围之后，就该给新人安排真正的工作任务了。此时，不必急于将与现有系统耦合较多的任务交给他/她来完成，这样只会让新人一头雾水。比如在产品研发的团队中，可以安排完成一些具有相对独立性的，与既有系统关系不大的Feature。这样，便可以进一步弥补“实战练习”中的缺失与不足，进一步增进团队融合。随着对系统的逐渐深入了解，那时再将复杂任务交于他们也尤未晚矣。此时，新人也便成了老人：）

团队的Wiki开始真正发挥效用了，这让我感到很欣慰，记得这是我半年多前一手搭建起来的。想来一件新事物从引入到被大家自然而然的认可，并非是很容易的事情。

如今，有的同事会主动想到，要在Wiki上开辟专门的栏目，来统一管理团队交流之用的文档和资料，这是意识上的提升。于是，Wiki就担当起了它本该有的功能和职责——团队的知识文档库。得益于Wiki的“轻量”特点，其实做起来也挺简单的：我使用的是JSPWiki的“改良版”。因为集成了blog，因此所有人都可以将一些日常零散的内容作为个人blog来发布。日后当积累到一定程度，既可在Wiki上单开栏目，并将blog做整理，只要写一个简单的导向链接即可。如果是专门的，正式的文档，则可以直接作为栏目文章，而不是做导向链接。

好的Wiki应该还具备：版本管理、mail通知、RSS订阅、PDF格式导出等诸多功能。这其中，尤以版本管理甚为重要。因为有了它，实际上，Wiki就成了一个SCM系统了，那么基于文档的变更管理就也可以成为Wiki的职责范围了。

前段时间在做部门平台的再工程，其中有一项工作是去除原先核心模块的EJB代码。这实际上是一个典型的重构过程，因为它非常符合重构的定义——在保证外部功能不变的情况下，对现有代码的调整。于是，我在每次修改代码之前，都会先将原有代码所反应出来的外部逻辑用测试用例表达出来，从而保障修改过程是在严格的契约控制之下进行的。这可以说是在我开始实践TDD&Refactoring至今，所遇到的最为典型的一个案例了。

不过期间也发现一些问题，比如：既有代码本身的易测性对TDD的施行是至关重要的。一个难于测试的软件系统，会导致编写测试用例异常困难（比如代码中大量的使用Factory或Single模式）。开始阶段，我花费了大量时间在编写测试用例上（实际上，在代码修改上花费的时间所占比重并不大）。其中的一个测试用例，直到最后完工时，才跑通，整个周期非常之长。于是这就很容易导致一种倾向：即使有心实践TDD/Refactoring者，在经历了一段费劲周折而进展甚微的过程之后，就干脆放弃了测试，冒险直接修改代码。

结合TDD，重构遗留系统的过程中遇到的另一个常见问题是，系统的耦合导致测试用例很难写。这一点在我的这次实践中也有所体现。也许针对某一个类的测试会牵涉多方“利益”，此时，最为有效的办法就是借助于mock test。假如只关心系统某个部分的测试，那么就务必要利用mock object来将之隔离。当然mock object的编写也是需要计入成本的。同时，这也教会我们，在编写实现代码时，务必要考虑可测试性，诸如针对接口编程这样的实践是一定要贯彻执行。