近在与一位总经理交流的时候,他谈到他们公司的软件研发管理,说:“我们公司大的问题是项目不能按时完成,总要一拖再拖。”他问我有什么办法能改变这个境况。从这样一个问题开始,在随后的交谈中,又引出他一连串在软件研发管理中的遇到的问题,包括:
  . 现有代码质量不高,新来的开发人员接手时宁愿重写,也不愿意看别人留下的“烂”代码,怎么办?
  . 重构会造成回退,怎样避免?
  . 有些开发人员水平相对不高,如何保证他们的代码质量?
  . 软件研发到底需不需要文档?
  . 要求提交代码前做Code Review,而开发人员不做,或敷衍了事,怎么办?
  . 当有开发人员在开发过程中遇到难题,工作无法继续,因而拖延进度,怎么解决?
  . 如何提高开发人员的主观能动性?
  其实,每个软件研发团队的管理者都面临着或曾经面临过这些问题,也都有着自己的管理“套路”来应对这些问题。我把我的“套路”再此絮叨絮叨。
  1. 项目不能按时完成,总要一拖再拖,怎么改变?
  找解决办法前,当然要先知道问题为什么会出现。这位总经理说:“总会不断地有需求要改变和新需求提出来,使原来的开发计划不得不延长。”原来如此。知道根源,当然解决办法也有了,那是“敏捷”。敏捷开发因其迭代(Iterative)和增量(Incremental)的思想与实践,正好适合“需求经常变化和增加”的项目和产品。在我讲述了敏捷的一些概念,特别是Scrum的框架后,总经理也表示了对“敏捷”的认同。
  其实仔细想想,这里面还有一个非常普遍的问题。对于产品的交付时间或项目的完成时间,往往由高级管理层根据市场情况决策和确定。在很多软件企业中,这些决策者在决策时往往忽略了一个重要的参数,那是团队的生产率(Velocity)。生产率需要量化,而不是“拍脑门子”感觉出来的。敏捷开发中有关于如何估算生产率的方法。所以使用敏捷,在估算产品交付时间或项目完成时间时,是相对较准确的。Scrum创始人之一的Jeff Sutherland说,他在一个风险投资团队做敏捷教练时,团队中的合伙人会向所有的待投资企业问同一个问题:“你们是否清楚团队的生产率?”而这些企业都很难做出明确的答复。软件企业要想给产品定一个较实际的交付日期,首先要弄清楚自己的软件生产率。
  2. 现有代码质量不高,新来的开发人员接手时宁愿重写,也不愿意看别人留下的“烂”代码,怎么办?
  这可能是很多软件开发工程师都有过的体验,在接手别人的代码时,看不懂、无法加新功能,读代码读的头疼。这说明什么?排除接手人个人水平的因素,这说明旧代码可读性、可扩展性比较差。怎么办?这时,也许重构是一种两全其美的办法。接手人重构代码,既能改善旧代码的可读性和可扩展性,又不至于因重写代码带来的时间上的风险。
  从接手人心理的角度看,重构还有一个好的副作用,是代码重构之后,接手人觉得那些原来的“烂”代码被修改成为自己引以自豪的新成。《Scrum敏捷软件开发》的作者Mike Cohn写到过:“我的女儿们画了一幅特别令人赞叹的杰作后,她们会将它从学校带回家,并想把它展示在一个明显的位置,也是冰箱上面。有,在工作中,我用C++代码实现了某个特别有用的策略模式的程序。因为我认定冰箱门适合展示我们引以为豪的任何东西,所以我将它放上去了。如果我们一直对自己工作的质量特别自豪,可以骄傲地将它和孩子的艺术品一样展示在冰箱上,那不是很好吗?”所以这个积极的促进作用,将使得接手人感觉修改的代码是自己的了,而且期望能够找到更多的可以重构的东西。
  3. 重构会造成回退,怎样避免?
  重构确实很容易造成回退(Regression)。这时,重构会起到与其初衷相反的作用。所以我们应该尽可能多地增加单元测试。有些老产品,旧代码,可能没有或者没有那么多的单元测试。但我们至少要在重构前,增加对要重构部分代码的单元测试。基于重构目的的单元测试,应该遵循以下的原则(见《重构》第4章:构筑测试体系):
  - 编写未臻完善的测试并实际运行,好过对完美测试的无尽等待。测试应该是一种风险驱动行为,所以不要去测试那些仅仅读写一个值域的访问函数,应为它们太简单了,不大可能出错。
  - 考虑可能出错的边界条件,把测试火力集中在哪儿。扮演“程序公敌”,纵容你心智中比较促狭的那一部分,积极思考如何破坏代码。
  - 当事情被公认应该会出错时,别忘了检查是否有异常如期被抛出。
  - 不要因为“测试无法捕捉所有Bug”,不撰写测试代码,因为测试的确可以捕捉到大多数Bug。
  - “花合理时间抓出大多数Bug”要好过“穷尽一生抓出所有Bug”。因为当测试数量达到一定程度之后,测试效益会呈现递减态势,而非持续递增。
  说到《重构》这本书,其实在每个重构方法中都有“作法(Mechanics)”一段,在重构的实践中按照上面所述的步骤进行是比较稳妥的,同时也能避免很多不经意间制造的回退出现。