代码之道——对于每次变更,搅动,搅动,搅动

    也许在极端情况下,变更还不止一次。但这的确有可能发生。即使变更没有那么晚,规范书常常也是不完整的,或者在尚未被开发人员及时复审和检查之前就匆忙交付开发了。     结果怎么样呢?搅动代码,一次又一次地更改以前的实现。开发人员开始编码的时间太早了!规范书本身就有问题,因此代码自然也有问题。当有人指出这些问题的时候,特别会议召开了,但有人被遗漏、缺席了这个会议,代码返工重写之后,那个被遗漏的人发现了其他地方的错误,于是需要召开更多的特别会议,就这样周而复始、永无宁日。     有什么办法可以解决这个问题呢?有些人可能会说:“项目经理是人渣,应该缠着他,直到他把工作做好。”这听起来有点残酷,哪怕是我也有这样的感觉。规范书来得太晚,这是生活的现实,问题在于你处理它的方式。我见到过有如下一些不同的方法。     作者注:我能想象,一些极限编程爱好者在那边嚷嚷了:“给他们一个房间!”(一个团队房间。)我在后面的一个栏目——“停止写规范书,跟功能小组呆在一起”——也会谈到这个观点。然而,微软是一个相当多样化的环境。不是每个团队都能呆在同一个地方的,文档通常是解决团队之间的相互依赖问题的必要手段。因此,也并不是一个解决方案能够解决所有的问题。     走廊会议     第一种方法是走廊会议。当一个开发人员发现手头的规范书存在漏洞,这时候项目经理正好路过,于是一个走廊会议就开始了,一些问题通过这种方式得到了解决。那个开发人员很开心地回到他自己的座位,想着他终于搞清楚了接下去该做什么。那个项目经理也回到了他的办公室,想着开发人员写出来的代码肯定能够反映他真正想要的东西。也许他们在想同一件事情,也许不是。也许测试和实施人员会同意他们的解决方案,也许不会。也许他们方方面面都考虑到了,也许他们不曾做到。也许这是最好的方式去处理变更,也许猴子会冲出我的……好吧,至少你知道了有这种方法。     委员会议     第二种方法是委员会议。对于这种会议,不同的团队有不同的称呼,但它主要是用于讨论规范书变更的主管级会议。通常这种会议会定期召开,各个主管形成一个组织,他们聚在一起讨论规范书上的漏洞或者问题,并且以组织的名义寻找解决方案。主管的项目经理记录会议结果,并且发邮件告知整个团队。     这种方法的优点是:委员会议把该包含的人都包含了进来,达成了最终决议,记录在档,并且拿这些最终决议跟团队沟通。缺点是:委员会议也是可怕的噩梦。它们通常比较冗长、令人厌烦、使人筋疲力尽。它们占用了关键资源的巨大周期,阻碍了工作进展,成为了最要命的一种瓶颈——自我伤害和自我永续不断。