代码审查应该成为任何重要的软件开发工作中一个基本制度。并不单指产品程序――而是所有东西。而且代码审查也不需要花费很多的时间和人力，但它却能发挥巨大的效果。
从代码审查里能得到什么？
对于代码审查的认识，在代码提交前，用其他人的眼睛检查一遍，防止bug混入。这是最常见的理解，也是对代码审查的好处的最广泛的认识。
但是，在我看来，这并是它最不重要的。人们确实可以在代码审查中找到一些bug。可是，这些在代码审查中能发现的绝大部分bug，很显然，都是微不足道的bug，程序的作者花几分钟的时间就能发现它们。真正需要花时间去发现的bug不是在代码审查里能找到的。
代码审查的最大的好处在于,如果你是程序员，而且知道将会有其他同事来检查你的代码，你编程态度就完全不一样了。你写出的代码将更加整洁，有更好的注释，更好的程序结构。因为你很在意别人对你的程序的看法。没有代码审查，你可能会认为，你写的程序基本不会有人看到，除非有人用到了，它不会给你带来同等的紧迫感。除此之外，还有一个非常重要的好处。代码审查能传播知识，培养分享的氛围。在很多的开发团队里，经常每一个人负责一个核心模块，每个人都只关注他自己的那个模块。除非是同事的模块影响了自己的程序，他们从不相互交流。这种情况的后果是，每个模块只有一个人熟悉里面的代码。如果这个人休假或辞职了，其他人则束手无策。通过代码审查，至少会有两个人熟悉这些程序。审查者虽然并不能像程序的作者一样对程序和业务十分了解，但他会熟悉程序的设计和架构还有业务的架构，这个极其重要的。
刚开始，大家在代码审查时经常会犯一些错误，导致很多麻烦，特别是一些缺乏经验的审查者，他们在代码审查的时候会给了程序开发者的很不好的感觉，最终导致程序员抵触代码审查制度。
针对所有人的审查
* 首先必须承认：审查者都是根据自己的编程习惯来评判别人的代码。所以很多编程上的主张都是一种个人观点。所以应该讨论它们的利与弊，提出你倾向的观点，迅速的在团队达成一致。
* 对与审查者和被审查者，大家觉得有压力，感觉非要说点什么，非得找出点什么问题出来才好，别人都提出了点什么，自己多少也得说点吧。（完全不需要。只说一句“这段程序写的真不错。”就可以了）
* 尽量使用提问或是建议，而不是命令。(“把这个变量命名成:user_id,你觉得怎样？”)
* 请求说明。(“我不明白。你能解释一下吗？”)
* 避免代码的归属之争。(“我的”，“不是我的”，“你的”)
* 不要讽刺,嘲笑别人的代码,避免使用一些会被认为或可能会被认为是有关人身特征的词语。(“笨蛋”，“愚蠢”，“傻逼”，“二”)要把所有人都看作是有魅力的、聪明的、善意的。
* 要明确。要记着并不是每个人都能理解你的意图。
* 要谦虚。(“我不能确定——我们来分析一下。”)
* 不要用“总是”，“从不”，“永远”，“毫无…”这样的修辞语。
* 如果对于某个代码，有太多的我不理解或大家都有不同的看法，可以组织一个讨论会，或是技术分享，然后把你们的交流形成共识，总结成文档
* 代码审查，不能时间太短，这样没有太多的效果，但是时间也不能太长。毕竟大家还有其他的工作要做。
让别人审查你的代码
* 首先要达成共识，理解审查是对事不对人。审查的是你的代码，而不是你。
* 对审查者的建议表示肯定和感激。(“对，你说的没错。”,“谢谢提醒。我会把它改正。”)
* 解释为什么代码写成这样，可以说明这段代码的业务逻辑。
* 整理所作的改动，不必当场改掉，复杂的程序，也可以在以后的迭代中重构它们。
* 努力站在审查者的立场上理解,同样也要努力理解作者的立场。。
* 针对你感觉非常好的地方以及不是很好的地方与开发者交流。
* 找出既能解决问题又能简化代码的方法，让代码变得简单。
* 提出你的实现方案，但要表现出作者也在考虑这种方案。(“你觉得这里用一个自定义校验如何？”)
* 程序风格样式和注释，同样也是代码审查的范围，而不仅仅是程序。
