审查

　　我从别人那里听到这个实践，但自己从未用过。在审查过程中，资深程序员审视你的整个项目，深入到具体主题。我说的“深入”其实是顺藤摸瓜的意思。为何你要选择某某设计？你有哪些数据证明你的假设？如何证明（或测试）你的实现是正确的？要是它能扔木头，它每秒可以扔多少木头？明白了吧。

　　准备审查是件大事，因为你不知道审查员会问什么。你必须准备任何事情。我在这里唯一的建议就是：在编程时，问自己同类问题。要是你的程序是从文件中读取数据，问问自己，我对文件格式做了什么假设？我是如何测试这些假设的？文件可以有多大？我如何证明？

　　当然，你目前可以只采用一种方式。但这种思维方式的回报总会在某个时间点开始递减；这个时间点取决于项目的类型和它的生命周期阶段。对于产品代码，小心谨慎为佳；对于商展示例或概念证明，只需完事就万事大吉了。

　　代码审核策略

　　关于代码审核策略的范围从不存在直到有制度保证。若团队的开发风格处于极度混乱的状态，除非迫不得已，他们不会去做代码审核。那时，等待你的将是侵蚀生命的逐行审核。若团队采用像极限编程这样的开发实践，代码审核就是常态：XP的结对编程，在效果上就是边写代码边审核。

　　有的行业出于认证的目的要求代码审核。如果你正在为航空电子或核电站写软件，在发行软件之前，会有一个令人发抖的审核过程。你知道有好多软件都附带一个最终用户许可证协议，上面基本上写的都是软件没有保修期且随时有可能崩溃吗？在航空电子业可没有这种好事—你的代码可是人命关天的。

　　然而，对于我们中的其他人，并不存在唯一正确的审核方法。最好的代码审核策略就是能带来最大好处的那个，依不同的团队和项目而不同。（提示：答案永远不是“从不审核”。）有经验的经理或技术领导应该根据需要设定策略。

　　不管怎样，你总是可以召集审核。当想让他人看你的代码时，只管去找，不必害羞。有经验的程序员总是这样做。若是初级程序员不请求审核，那肯定是麻烦滋生的信号。

　　行动指南

　　主动要求下次代码审核：在准备将下一次变更集检入团队的代码库之前，找位同事审核你的代码。但在找他之前，得做点功课：

　　1、产生改动的文件列表。源代码控制系统应该可以方便地告诉你这些信息；一般是“status”命令。

　　2、收集每个文件的差异，最好用图形化的对比工具，它会让你同时看到原始副本和当前副本，变动部分会突出显示。

　　3、现在，不要省去这一步，自己整体看看变更，确保你可以解释它们每一个。我不是指的是像审查风格那样，逐行深入了解你的动机，而是寻找明显的疏忽。里面很可能会有无意间引入的错误，把它改过来，重新获取新的差异。

　　现在，找个伙伴。要是你的团队没有明令这样做，只要找另一位程序员（最好是比你资深的人）就行，像这样说：“你愿意在我把代码检入之前看一下我的改动吗？”

　　拉上你的伙伴，在屏幕上展示差异，解释你修改的目的，然后对每个文件的差异逐个审阅。可以是你或伙伴来主导，只要效果好，哪种都行。假如你的编程风格很优雅（为什么不这样要求自己呢），伙伴应该可以很快看完你的变更。

　　除了解释代码外，还要解释你的测试方法。理想情况下，你会有一个自动化测试套件；也审核这些代码。要是没有，说明一下你做过的任何手动测试或证明代码的正确性。

　　甚至在叫伙伴过来之前，你也很可能会找到一两个疏忽。此外，你的伙伴会问一两个你没有想过的问题。你可能会发现，每次提交时都需要一个检入伙伴。