通过一次真正彻底地代码审查（code reviews），仔细阅读你的代码，找出问题，这是我知道的好的方式去检测早期的bug，但是他们很少去这样干过。某种意义上是因为他们花了大量的时间去写好代码，但是我认为主要是因为绝大部分程序员害怕其他人审查自己的代码。作为专业的程序员我们要克服阻力，如果你不愿意别人阅读你的代码，然后只是按照自己的意愿写，如果其他人没法读懂它，又怎能让别人使用呢？”Jim Waldo

　　Code Review已经成为软件开发一个必备活动。它帮助我们提高代码的质量，让代码更加可读，尽早地发现存在的bug。Code Review也是提高团队凝聚力的活动，通过交流，提升团队能力。

　　Code Review作为要的实践，它跟测试、静态代码分析合作，能够发现软件中99%的bug。越早发现Bug，代价越小，因此Code Review变成了重要的实践。做好Code Review，需要快速有效，不浪费他人的时间（浪费别人时间等于谋财害命），也需要调整自己的心态：

　　Code Review是做好工作的一次机会，而不是试图否定自己。代码的自我审查应该在同行审查以前进行。

　　Code Review是合作，是团队合作交流的机会。

　　Code Review是分享。代码贯穿于团队，不再是一个人掌握一块代码。

　　Code Review必然面对重构，这是很好的锻炼编码技巧的机会。可以统一代码的风格，提高可读性，当然效率和质量上也应该有提升。

　　Code Review是一个长期的活动。即使总结错误，提高今后设计开发的预见性。对Code Review的阶段性总结对团队是有益的。

　　Code Review需要激励。对自己负责的心态会破坏团队的能力，正在做到像Coder一样的对等Review，需要激励措施。

　　如何建立适合自己的Code Review流程？可能不同的团队对代码审查的需求不一样，但终目的是一致的。要正确的人来做Code Review，并且能快速完成，并且让Code Review成为一次愉悦的团队交流。常用的Review形式有：

　　Pair Programming，在一人编码的同时，另一人进行Review。这种方式的好处在于都对改动非常熟悉，容易快速找到优的解决办法。方法的缺陷在于，可能存在单人主导的误导，不能跳出Code的思维圈，有一定的Review局限性。（尽早参与）

　　Online Review。通过合适的工具与CVS的相结合，代码的提交需要Reviewer的Review和Approve。此类方法的好处在于节省时间，缺点在于对突然的代码更改，Reviewer可能没有完整全面的评审思维来进行Review，容易错过一些隐藏的bug。（快速高效）

　　Review Meeting。把大家召集到一起，通过面对面的Meeting来代码审查。 Review Meeting需要进行Rre-review，让所有的Reviewer有备而来。这样的方法代价很高，需要控制Review带来的额外负担。（流程保证）

　　我喜欢buddy reviews的方式，随时交流，非正式的形式，轻松的环境对Coder很重要。

　　Code Review不是的，多做测试总没有错！