最近在思考如何才能高效地完成review，让review不要变成形式化的空架子。
programming4scientists 上看到一个how to review code 的一篇博文。
关于review，有以下六点：
1. 首先需要对要review的东西有一个全局的认识。如果代码已经差不多完成，则对于架构层面、设计层面的改动则很少会发生因为这样代价很高；反之如果是设计阶段，则指出的问题便多多益善。
2. 必须提有建设性的意见。不只要指出问题，还有提出问题的解决办法。如果有bug，提出解决方案；如果代码风格方面意见，给出更好的风格以及why。
3. 问。会碰到很混乱或者含糊不清的代码，通常这种情况下，作者对这一块也会没有很清晰的认识，问他们，使他们思考，从而建立清晰的认识。
4. 代码风格是非常私人化的，除非非常不协调或者晦涩难懂，不要吹毛求疵。给出建议和解释为什么更好。
5. 跟随你的直觉，如果你有非常多的经验，你会“嗅到”坏代码，当然这种能力或者说本能是随着经验的不断丰富而形成的。
6. 不要将自己的意见强加给作者。你只是给建议，而不是接管编码权。
anything else ？
-----------------------------------------------
usernet上得到一些反馈，再补上以下四条：
7. Review meeting最好安排有专门的Moderator，控制整个Review过程：比如会议室的预定；会议时间的掌控等。
8. Reviewer的指定必须有针对性：他必须对你的代码流程比较熟悉,最好是一个项目组的同事。
9. 如果有测试报告,最好把测试报告也作为Review的对象。
10. 必须有一个书面性的东西追踪你的review和work after review。
Posts
