代码审查

高效代码审查的八条准则和十个经验 这篇文章写的很好，于是摘抄了几点比较重要的内容。

代码审查量不宜过多

根据smartbear在思科所作的调查，每次审查200行-400行的代码效果最好。每次试图审查的代码过多，发现问题的能力就会下降，

但是限制每次审查的数量确实非常必要，因为这个过程是高强度的脑力密集型活动。时间一长，代码在审查者眼里只是字母，无任何逻辑联系，自然不会有太多的产出。

带着问题去进行审查

　　我们在每次代码审查中，要求审查者利用自身的经验先思考可能会碰到的问题，然后通过审查工作验证这些问题是否已经解决。一个窍门是，从用户可见的功能出发，假设一个比较复杂的使用场景，在代码阅读中验证这个使用场景是否能够正确工作。
　　使用这个技巧，可以让审查者有代入感，真正的沉浸入代码中，提高效率。大家都知道看武侠小说不容易瞌睡，而看专业书容易瞌睡，原因就是武侠小说更容易产生代入感。
　　有的研究建议每次树立目标，控制单位时间内审核的代码数量。这个方法在我们的实践中显得很机械和流程化，不如上面的方法效果好。　

感概: 有的时候我们连所review代码的需求都没有了解清楚，谈何review　

在非正式，轻松的环境下进行代码审查

　　如前所述，代码审查是一个脑力密集型的工作。参与者需要在比较轻松的环境下进行该工作。因此，我们认为像某些实践中建议的那样，以会议的形式进行代码审查效果并不好，不仅因为长时间的会议容易让效率低下，更因为会议上可能出现的争议和思考不利于进行如此复杂的工作。

切身体验，通过会议集体review确实费时费力，而且效率很低

提交代码前自我审查，添加对代码的说明

　　所有团队成员在提交代码给其他成员审查前，必须先进行一次审查。这次自我修正形式的审查除了检查代码的正确性以外，还可以完成如下的工作：
　　(1)对代码添加注释，说明本次修改背后的原因，方便其他人进行审查。
　　(2)修正编码风格，尤其是一些关键数据结构和方法的命名，提高代码的可读性。
　　(3)从全局审视设计，是否完整的考虑了所有情景。在实现之前做的设计如果存在考虑不周的情况，这个阶段可以很好的进行补救。
　　我们在实践中发现，即使只有原作者进行代码审查，仍然可以很好的提高代码质量。

减少review你代码的代价 即利于他人减少review投入，同时也在push你提高代码质量

Be buddies

在我看来，称之为“buddy reviews”（别人会叫“over the shoulder”）非常好。A buddy review是指与其他团队成员每隔一到两天以非正式的形式讨论，并且快速的浏览（5-10分钟）对方的代码。这种方法可以帮助你：
1. 及早的发现问题
2. 总是很快的知道该干什么
3. 代码审查无须过长，因为你只需要查看新的代码，旧的代码会很快赶上
4. 这种非正式的场合——没有紧张感，很有趣！
5. 可以定期的交换想法
buddy reviewing在团队中是一种很好的工作方式，当某人在团队中出现问题时可以及早的发现。这不仅可以帮助大家，还可以交换彼此的进度和想法。
总之，如果你的项目正在进行代码审查，应该做到快速、有效、不浪费别人的时间。正如文章所说的，这几点非常重要。代码审查用意是在代码提交前找到其中的问题。

现在我们形成了backup review 机制，那么代码审查没有必要等到需求最后完工的那一刻，而是隔一两天即可review 一下别人的代码，关键点是: 非正式， 放松有趣， 快速 。 buddy 是 好友的意思，其实你的backup 也应该是你的buddy