代码之道-第3部分

按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！


为他们原以为功能已经完成了，但实际上测试人员却在疯狂抱怨他们实现的是一个“错误”的东西，这将导致大量的返工。更糟糕的是，开发人员当初实现的功能根本就没有在文档中被正确定义好。于是，大家对新的规范书展开争论，发现漏洞，然后再更改，搅动实现代码，直到项目失败——而这时候本该是产品的稳定化阶段。这下大家都“开心”了！
　　也许在极端情况下，变更还不止一次。但这的确有可能发生。即使变更没有那么晚，规范书常常也是不完整的，或者在尚未被开发人员及时复审和检查之前就匆忙交付开发了。
　　结果怎么样呢？搅动代码，一次又一次地更改以前的实现。开发人员开始编码的时间太早了！规范书本身就有问题，因此代码自然也有问题。当有人指出这些问题的时候，特别会议召开了，但有人被遗漏、缺席了这个会议，代码返工重写之后，那个被遗漏的人发现了其他地方的错误，于是需要召开更多的特别会议，就这样周而复始、永无宁日。
　　有什么办法可以解决这个问题呢？有些人可能会说：“项目经理是人渣，应该缠着他，直到他把工作做好。”这听起来有点残酷，哪怕是我也有这样的感觉。规范书来得太晚，这是生活的现实，问题在于你处理它的方式。我见到过有如下一些不同的方法。
　　作者注：我能想象，一些极限编程爱好者在那边嚷嚷了：“给他们一个房间！”（一个团队房间。）我在后面的一个栏目——“停止写规范书，跟功能小组呆在一起”——也会谈到这个观点。然而，微软是一个相当多样化的环境。不是每个团队都能呆在同一个地方的，文档通常是解决团队之间的相互依赖问题的必要手段。因此，也并不是一个解决方案能够解决所有的问题。
　　书　包　网　txt小说上传分享

走廊会议
第一种方法是走廊会议。当一个开发人员发现手头的规范书存在漏洞，这时候项目经理正好路过，于是一个走廊会议就开始了，一些问题通过这种方式得到了解决。那个开发人员很开心地回到他自己的座位，想着他终于搞清楚了接下去该做什么。那个项目经理也回到了他的办公室，想着开发人员写出来的代码肯定能够反映他真正想要的东西。也许他们在想同一件事情，也许不是。也许测试和实施人员会同意他们的解决方案，也许不会。也许他们方方面面都考虑到了，也许他们不曾做到。也许这是最好的方式去处理变更，也许猴子会冲出我的……好吧，至少你知道了有这种方法。
　　　。　想看书来

委员会议
第二种方法是委员会议。对于这种会议，不同的团队有不同的称呼，但它主要是用于讨论规范书变更的主管级会议。通常这种会议会定期召开，各个主管形成一个组织，他们聚在一起讨论规范书上的漏洞或者问题，并且以组织的名义寻找解决方案。主管的项目经理记录会议结果，并且发邮件告知整个团队。
　　这种方法的优点是：委员会议把该包含的人都包含了进来，达成了最终决议，记录在档，并且拿这些最终决议跟团队沟通。缺点是：委员会议也是可怕的噩梦。它们通常比较冗长、令人厌烦、使人筋疲力尽。它们占用了关键资源的巨大周期，阻碍了工作进展，成为了最要命的一种瓶颈——自我伤害和自我永续不断。
　　　电子书　分享网站

规范书变更请求
我最喜欢的方法是“规范书变更请求”（SCR，Spec　Change　Request），它还有一个扭曲的名字叫“设计变更请求”（DCR，Design　Change　Request）。这种方法是委员会议和走廊会议的组合，同时带有一些关键的改进。假设你现在想去改变规范书或者给规范书增加新的内容，你的这个想法可能是你自己想出来的，也可能源于一次走廊对话，也可能受到了一次主管会议的启发。
　　不管你是项目经理、开发、测试或实施人员，你都可以把你的想法写到e…mail中去，并且e…mail的标题定为“SCR：　　…　”。在e…mail结尾的地方，你用粗体字写下这么一句话，“除非有人强烈反对，否则这就是最新采纳的规范书。”然后，你把这封e…mail发给最直接受这个变更影响的项目经理、开发、测试和实施人员。几天之后，当你根据他们的建议做完了必要的修改，你就可以把你的SCR发给团队中剩下的所有人，并且把它放到RAID中或者一个公共目录中，跟其他SCR一起跟踪。
　　译者注：关于RAID，参见本书最后的“术语表”。
　　这里的关键是，规范书的变更现在文档化了，并且得到了相关人员的复审，而且不会阻碍工作的进展。反对几乎总是例外，不会有很多。开发人员在任何时候都可以继续工作，这里只是一个权衡问题——动手做之前花更多的时间等待是否有反对，或者冒着后来被反对的风险马上就动手做。典型情况下，开发人员会一直等待，直到SCR经过了初始的几次修改后发给团队全体成员的时候才动手做。
　　

预防是最好的治疗
当然，最理想的是规范书从一开始就不会迟到，至少你不能被它蒙蔽。这里就用得着T…I…M…E图表了。在T…I…M…E图表中，第一份规范书展示了对整个项目的设计。它不是简单的需求文档，也不是数个小型规范书的集合，而是项目的一个高级规范书，很像是开发主管写的那种高级架构文档。这个规范书应该展示项目将具有的功能和用户界面，以及它们怎样在一起协作，而把细节留给以后的规范书。所有后来的规范书和功能都必须参考这个高级规范书。
　　这样的话，开发、测试和实施人员就可以制定计划去说明未来所有的功能了。他们能够生产出集成得更好的产品，使用户体验更加流畅。项目经理也可以使用第一份规范书去安排剩下的其他规范书，先做优先级高的，而不必担心遗漏什么东西或者做出让别人吃惊的事情来。这种理想终究使T…I…M…E产生了（难以抗拒）。
　　作者注：T…I…M…E（Totally　Inclusive　Mutually　Exclusive）图表是由Donald　Wood首先提出的，但它从未像我的同事Rick　Andrews最初预期的那样流行过。然而，微软现在的价值主张、远景文档、跨产品案例和仔细设计的原型都能达到同样的目的。
　　　电子书　分享网站

宝宝做了件极坏的事情（1）
2002年6月1日：“闲置人手”
　　你的开发团队两周前达到了“零Bug反弹”（ZBB，Zero　Bug　Bounce），　你突然意识到，你又迎来了一个“工作淡季”。任何从事零售软件产品开发、并且碰到过零Bug反弹的开发人员都知道这个“工作淡季”。但如果你的团队是提供互联网服务的，你现在可以停止阅读了。（等一下，你一开始读本栏目的时间哪来的？回去干活！）
　　作者注：零Bug反弹（ZBB，Zero　Bug　Bounce）描述了第一次出现项目中的所有功能都完成了、并且所有工作条款都解决了的那个时刻。这个时刻很少会长时间持续。通过进一步的系统测试，通常在1小时之内就会有新的问题暴露出来，随后团队又必须埋头去工作。尽管如此，零Bug反弹意味着项目在可预见的将来就要结束了。
　　零Bug反弹标志着项目状态从“瓶颈在开发方”到“瓶颈在测试方”的转变（“瓶颈在项目经理”没有类似的这种转变）。在处理完产品出货后最初几周内的一批新发现的Bug之后，大部分开发团队进入了“时而加速，时而等待”的模式——当有新Bug分配过来的时候奋力去解决它，否则就闲着不知道该做什么了。
　　最可怕的是，“工作淡季”有时候可能从零Bug反弹开始，一直持续到下一个版本产品的第一个里程碑。这在大项目中可能有几个月之多！开发经理手上总是忙着各种各样的事情，因而很容易就会忽略，其实三分之二的团队成员都闲在那里。你知道他们怎么说闲置人手的——嗯，不是很好听！
　　以下是闲置的开发人员经常做的一些坏事：
　　？ 抢修Bug。零Bug反弹之后，你的团队应该处于“禁闭”状态，这意味着，所有Bug在被修复之前都要通过分诊会议的慎重考量。闲置的开发人员有时坐在他们的位置上，敲击RAID（现在叫Product　Studio）上的F5功能键等待Bug的出现。如果通过这种方式没有发现Bug，他们就会把视线转到正在被分诊讨论的那些Bug上，挑一个有趣一点的，然后开始研究它。在你知道之前，他们可能已经有了一个修复方案，并且正伺机悄悄地把代码签入进去呢……这就是抢修Bug！一个有自尊的开发者不应该做这样的事情。
　　作者注：在软件工程中，Bug通常是指代码中的错误。然而，微软内部使用“Bug”这个词泛指跟产品相关的所有增加、删除或者修改。但大家对外一般称这些为“工作条款”，其中有一些也可能是代码错误。我更喜欢“工作条款”的说法，这样就能把那些真正的Bug区分出来。
　　谁知道分诊团队是否会决定修复那个Bug呢？谁知道那个Bug是否被正确地修复了，并且也不会引起相关的另一个更大的或者小一点的Bug呢？对于潜在的重大问题投入一点调研是可以的，但绝对不要抢先去修复！
　　？ 修复尚未报出来的Bug。现在有一个Bug通过了分诊，你正在进行修复。这时你注意到，在你修改的代码附近有其他更多的Bug（通常这些Bug是由以前的修复引起的）。但不知怎么搞的，这些Bug还没有被人报出来。你看到了这些代码，而其中的错误也尽收你眼底。为什么不一起把它们都修复了呢？喂！就此打住！！！
　　开发团队通过代码复审来避免这种可怕的事情。在“可信计算”时代，团队应该在整个项目周期内复审每一次代码签入。当团队处于“禁闭”状态时，要保证有3双眼睛（即代码改动者本人和另外两个开发者）同时审查每一次的代码改动。至于开发人员在修复一个Bug时发现的其他Bug，则要通过如下方式来跟踪：先把它报出来、登记到Bug数据库中，然后再分诊……
　　作者注：《凯文与霍布斯》连环漫画系列中有这么一个故事：凯文对一只苍蝇慈悲为怀，打开前门让它飞出去。结果呢？这只苍蝇非但没有飞出去，反而另外3只苍蝇飞了进来。这就是为什么你必须在项目逼近尾声时，要对每一个Bug进行研究和分诊的原因了。我的团队曾经在我们的产品发布前一个月的时候改变了一个参数的值，结果一周之后，全公司的测试人员都发现：只要打开CD托盘，所有的应用程序都会停止响应。最后，我们往回追踪到那个看起来无关紧要的参数，并把那个改动撤销了才解决问题。这种事情真实地发生在我们的周围，只是你未必知道而已。　。。

宝宝做了件极坏的事情（2）
？ 修复标为“延期”的Bug。大家知道，被标为“延期”的Bug在产品发布给制造商（RTM，Release　To　Manufacturing）之前是不能去修复的。那么，是不是应该在计划下一版产品的时候去修复它们呢？不对！当初在项目的进行过程中，产品的相关团队对“哪些Bug对我们的客户影响最大，因此必须在发布之前修复”作了判断，但这种判断在产品没有真