Eight guidelines and ten lessons for efficient code review

Code Review is a commonly used method in software development. Compared with QA testing, it is easier to find difficult problems related to architecture and timing. It can also help team members improve programming skills and unify programming styles.

　　1. Code reviews require teams to have a good culture
　　Teams need to recognize that code reviews are about improving the capabilities of the entire team, not individual checkpoints.
　　"A's code has a bug that was discovered by B, so A's ability is not good, but B's ability is better", this kind of trap is easy to spread and affects the cooperation within the team, so it needs to be avoided.
　　In addition, code review itself can improve the ability of developers to learn from their own mistakes and from the ideas of others. If developers are resistant or disgusted with this process, this purpose will not be achieved.
　　2. Carefully use the discovery rate of the problem in the review as the evaluation standard
. If a problem is found in the review, it is a good thing for the problem finder and should be encouraged. But for those found, we do not advocate using this method to punish them. Bugs are inevitable in software development, and being overly demanding is counterintuitive. To make matters worse, code reviews have no value and meaning if they cause participants to be afraid of taking responsibility and reluctant to point out problems during the review.
　　3. Control the amount of code per review
　　According to a survey conducted by smartbear at Cisco, 200-400 lines of code per review works best. Every time you try to review too much code, the ability to find problems will decrease. The specific proportional relationship is shown in the figure below
(I think it depends on the implementation situation. If you review it in combination with the documentation, then it doesn’t matter if there is more code.)
　We In practice, it has been found that the optimal amount of code review varies with the development platform and development language. But limiting the number of reviews per review is really necessary, as the process is a high-intensity, brain-intensive activity. Over time, the code is just letters in the eyes of the reviewers, without any logical connection, and naturally there will not be much output.
　　4. Bring questions to the review
　　In each code review, we ask reviewers to use their own experience to think about possible problems, and then verify that these problems have been solved through the review work. One trick is to start with user-visible functionality, assume a more complex usage scenario, and verify that this usage scenario works correctly in code reading.
　　Using this technique can make the reviewer feel immersed in the code and improve efficiency. Everyone knows that reading martial arts novels is not easy to fall asleep, but reading professional books is easy to fall asleep. The reason is that martial arts novels are more likely to generate a sense of substitution.
　　Some studies suggest setting goals each time to control the amount of code reviewed per unit time. This method is very mechanical and process-oriented in our practice, and it is not as effective as the above method.
　　5. All problems and revisions must be confirmed by the original author.
　　If a problem is found during the review, it must be confirmed by the original author.
　　This has two purposes:
　　(1) Confirm that the problem does exist and ensure that the problem is solved
　　(2) Let the original author understand the problems and deficiencies and help them grow.
　　Sometimes in pursuit of efficiency, experienced reviewers prefer to directly modify the code Even refactoring all the code, but this is not conducive to improving the efficiency of the team, and will increase the chance of introducing new bugs due to refactoring, which is usually discouraged.
　　6. Use code review to activate individual "motivation"
　　Even if the project schedule is relatively tight and the code review cannot be carried out completely, at least part of the code review should be carried out. At this time, it is a good way to extract some key parts.
　　The logic behind it is that software development is very creative work, and developers have a strong self-motivation and self-realization requirements. Letting the developer know that any code he writes is likely to be read and reviewed by others can help the developer focus, especially by avoiding submitting poor quality or even low-level buggy code to peer review. Open source software also makes good use of this mindset to improve code quality.
　　7. Conduct code reviews in an informal, relaxed environment
　　As mentioned earlier, code review is a brain-intensive job. Participants need to do this work in a relatively relaxed environment. Therefore, we believe that code review in the form of a meeting is not very effective, as some practices suggest, not only because long meetings are prone to inefficiency, but also because of the disputes and thinking that may arise during the meeting. It is not conducive to doing so complex work.
　　8. Self-review before submitting code and add a description of the code
　　All team members must conduct a review before submitting code to other members for review. In addition to checking the correctness of the code, this self-correction review can also complete the following tasks:
　　(1) Add comments to the code to explain the reason behind the modification, so that others can review it.
　　(2) Correct the coding style, especially the naming of some key data structures and methods, to improve the readability of the code.
　　(3) Review the design from a global perspective, whether all scenarios are completely considered. If there are ill-considered situations in the design made before implementation, this stage can be well remedied.
　　We have found in practice that even if only the original author does a code review, the quality of the code can still be improved.
　　9. Recording notes in the implementation can greatly improve the problem discovery rate.
　　Members should make casual records when coding, including expressing them in the form of comments in the code, or recording simple personal documents. This has several advantages:
　　(1 ) to avoid omissions. Any issues that were taken into account during coding were recorded and checked again during the review phase to confirm resolution.
　　(2) According to research, everyone is used to making some repetitive mistakes. Such problems are recorded in the code and can be used as a basis for inspection during review.
　　(3) After repeatedly taking notes and finding similar problems in the review, the occurrence rate of such problems will drop significantly.
　　10. Use good tools for lightweight code
　　review ". We are using the code hosting service provided by bitbucket.
　　Each team member independently develops features and submits the code to reviewers in the form of Pull Requests. The reviewer can easily read the code on the web page, add comments, etc., and then the original author will automatically receive an email reminder to discuss the review comments.
　　Even if the team members are distributed across the world, the tools provided by bitbucket can be used to conduct code review very well.
　　Source: Nut Cloud (a secure cloud storage service for mobile office).

2. Code Review: What Everyone Should Do

As I mentioned in my last blog post (which I can tell you now clearly), I've left Google. Although I have received a lot of good offers, I have not yet decided where to go. I'm not technically employed by anyone during this time, and while it may make my relationship with my (former) co-workers or boss a little bit tense, I feel like I should write something interesting about technology.
As I mentioned in my last blog post (which I can tell you now clearly), I've left Google. Although I have received a lot of good offers, I have not yet decided where to go. I'm not technically employed by anyone during this time, and while it may make my relationship with my (former) co-workers or boss a little bit tense, I feel like I should write something interesting about technology.

　　Google is really a cool company. Google has done a lot of amazing things, both inside and outside the company. Here I would like to introduce some things that are not involved in commercial secrets, but little known to outsiders.

　　The reason Google's code is so good is actually quite simple: they take code reviews very seriously. Code review is not unique to Google, it is recognized as a great means (to improve code quality) and many people already use code review in their day-to-day development. But I haven't seen a big company (like Google) use it so widely. At Google, any product or project code needs to be effectively reviewed before it is checked in (the code repository).

　　每个人都要参与代码审查，而且这里我指的不是非正式的审查：它是软件开发环节中非常重要而且通用的规则。不仅是产品代码，所有的代码都需要进行审查。审查代码不需要投入很多的精力，但是（与不做审查相比）产生的效果却是天壤之别。

　　关于代码审查（code review），Jonathan Danylko 的看法是“代码要经常检查（包括自查和其他同事检查）。不要把别人的检查，看成是对代码风格的苛求。应该把它们看作是有建设性的批评。对个人来说，经常检查你的代码并且自问，“我怎样才能写得更好呢？” 这会加速你的成长，让你成为一个更优秀的程序员。”

　　你能从代码审查中收获什么？

　　事实显而易见，有另外一个人检查即将提交的代码，能够帮助找到bug。这是代码审查众所周知且经常被提及的好处。但依据我的经验，这是最没有价值的一个好处。人们确实可以在代码审查中找到bug。然而坦率地说，在代码审查中找到的bug绝大多数都是一些代码作者花上几分钟就能找到的小bug。那些真正需要花时间才能找到的bug在代码审查中是检查不到的。

　　代码审查最大的好处在于它是一种社交的途径。如果你编程的时候就知道会有同事检查你的代码，那么你的程序会有所不同。你写的代码会更加整洁，有着较好的注释，结构也组织的不错——因为你知道会有人来检查你的代码，而且你很在意他们的意见。如果没有代码审查，你知道代码会在最后才会审查。因为不是马上就要检查，所以对你而言并不紧迫，因而你不会想着先自检一遍。

　　代码审查还有一个更大的好处，就是可以分享知识。在很多的开发团队中，每个人都会负责并且专注于一个核心模块。除非别的同事负责的模块出现问题导致自己的代码不能运行，否则他们是不会去关注别人的工作。这样产生的结果是，每一个模块的代码只有一个人比较熟悉。假如事不凑巧，那位程序员正好休假或者离开了公司，那么没有人了解那些代码了。如果有代码审查的环节，那么至少会有两个人熟悉代码——代码的作者和审阅者。审阅者虽然没有作者对代码那么了解——但是他同样熟悉代码的设计和结构，这些信息是无价之宝。

　　当然，没有什么事情是那么简单的。以我的的经验看来，要做好代码审查需要一段时间练习。我注意到经验不足的审阅者通常会落入一些代码审查的陷阱，这些陷阱往往会造成很多的麻烦，给那些希望尝试代码审查的人们留下了坏印象，成为了他们采纳代码审查的一个主要障碍。

　　代码审查最重要规则是对即将提交的代码中查找问题——你需要做的就是确认代码是正确的。而通常会犯的一个错误，也是刚刚接触代码审查的新手容易犯的一个错误，即审阅者会判断这段代码是否按照自己思路来实现。

　　当有一个问题需要解决时，通常会有几十种的办法。当选定一个解决方法时，会有百万种代码实现。因此，作为一个审阅者，你的工作不是确保代码是按照你的方式来编写的——因为这是不可能的事情。审阅者的工作是确保原作者编写的代码是正确的。如果你没有遵守这个规则，你可能会到处碰壁，审查结束时你的心情很糟糕，对你来说肯定不是一件好事情。

　　问题在于这是不自觉就会犯的一个错误。假定你是一个程序员，当你在看一个问题的时候，你会得到一个自己的解决方案——并且你认为你看到的就是这个问题（应该采用的）解决办法。如果想要成为一名好的审查者，你需要知道这是不对的。

　　第二个误区就是人们感觉一定要说点什么（才算是做了代码审查）。代码的作者花了很多的时间和精力来编写代码——你难道不应该说点什么吗？

　　答案是：你不应该。

　　如果只是说“哦，这看起来这不错！”，这永远没错。反之，如果你不断地去查找一些“问题”并加以指责，那么我肯定你的信誉会荡然无存。如果你不断地去制造一些事情来说些什么，那么代码的作者会认为，当你的言论只是为了避免冷场。从此，你的意见不会受到重视。

　　第三个误区就是速度。你不应该匆忙完成一次代码审查——但是也不要拖延。你的同事在那里等着你的审查结果。如果你和同事不愿意抽出时间来做代码审查或者一直拖延，大家会对这次的审查感到厌烦，也会认为以后的代码审查也只会带来麻烦。看起来好像代码审查会打断你的工作，其实不必如此。你不必要在别人要求你审查的时候马上丢掉手头上的事情。但是在几个小时之内，当你工作中间休息的时候——喝杯茶，去一下洗手间或者聊聊天，散散步。当你再回来工作的时候，你可以开始并完成这个代码审查。如果你这么做了，没有人会站在你身边一直等着你给出审查结果。

21世纪的代码审查

在软件工程领域里代码审查可以结束程序员之间无谓的争执。开发者常常会因为一些愚蠢的小事斗嘴，冒犯对方，甚至是在Q&A问答之前抓住Bug而喋喋不休，争执总是围绕在你左右。OK，千万不要误会我的意思，因为我们有理由相信代码审查绝对是个不错的好方法。原因如下：
1. 越早发现bug也就意味着可降低项目成本。无须释放一个修复补丁，因为它正处在开发阶段。
2. 代码变得越来越重要。
3. 知识贯穿于你的团队中，不再像以前那样一大块代码只有某一个人知道。
4. 开发者需要加倍的努力。如果开发者知道别人要对他的工作进行评估时，就会采取额外的努力做好工作，同时他还喜欢用文档注释标出异议。

如今，在21世纪的今天很多项目都没有使用代码审查。本文将提供8条准则，供开发者学习与参考。
1. 永远别忘了TDD
再确认测试代码前，先找别人帮你检查下是否无误。在别人做之前尽量检查出bug并且将其处理好。代码审查最重要规则是对即将提交的代码中查找问题——你需要做的就是确认代码是正确的。
2.尽可能的自动化
这里有几个非常好的Java工具比如：PMD, Checkstyle, Findbugs等等。问题是当利用这些工具查找后人们还肯花时间去做代码审查吗？
使用这些工具前，为这些工具制定一套细则是非常重要的。这能够确保你使用同一个代码审核标准从而区别于那些常被用于20世纪老式的代码审查规范。在理想的状态下，这些工具可运行在各种版本控制系统上通过hook审查每个代码。如果该代码不好将被阻止在外。
3.尊重设计
在我开始从事Java项目早期时，用代码审查的方式已为时已晚。因为当你检查代码问题时实际上给你的设计造成了缺陷。设计模式被误解，一些繁杂的附属物质混入进来或者开发者脱离了主题。
审查会混乱你的观点。或许你会反驳：“这是代码审查而不是设计审查”。这时一些烂摊子必然会接踵而至。为了避免这些问题发生，我们改变了设计的初衷。代码审查会牵连到很多面，无论是设计还是设计审查。事实上，我们通过设计审查要比代码审而得多的冲击要多的多。设计需要更高的质量和灵感，我们应该避免一些复杂的思维。
4. 统一的风格指南
即使是使用自动化工具（诸如Checkstyle，Findbugs等）也应避免不必要的风格冲突，你的项目应该具备有风格指南。（在尽可能的情况下）坚持Java协议的规范标准。尝试着为你的项目介绍制定一个“词典”，这就意味着，当涉及这个代码时，查看该代码的用法和环境是否适宜，这些都很容易被检测出。
5. 挑选适宜的工具
如果开发者都在使用Eclipse开发工具（ Eclipse IDE插件Jupiter），你可以通过你的方式来查看代码、调试代码甚至可使用Eclipse IDE上的一切东西当来帮助你在审查代码时更加的便捷。但是，如果大家没有使用同一个IDE（或者该IDE没有给你的工作带来方便）你可以考虑Review Board. ，它是个不错的选择。
6.请记住每个项目都不同
也许你在采用以前的项目方法工作，但是，请记住每个项目之间是不同的。每一个项目都有特定的架构（高并发或是高分散），有特定的文化（或许很多人喜欢使用Eclipse），并使用特定的工具（maven or ant）。难道你想照葫芦画瓢？OK，请记住，不同的项目有不同的工作方法。
7.懂得取舍
代码审查需要积极和细致而不是卖弄学问。你会因为一些细微的琐事让你紧张而导致项目失败或是花费公司成本吗？记住，千万不要这样。理清头绪，换个角度想想，改变自己的心态而不是记挂着去改变别人。
8. Be buddies
在我看来，称之为“buddy reviews”（别人会叫“over the shoulder”）非常好。A buddy review是指与其他团队成员每隔一到两天以非正式的形式讨论，并且快速的浏览（5-10分钟）对方的代码。这种方法可以帮助你：
1. 及早的发现问题
2. 总是很快的知道该干什么
3. 代码审查无须过长，因为你只需要查看新的代码，旧的代码会很快赶上
4. 这种非正式的场合——没有紧张感，很有趣！
5. 可以定期的交换想法
buddy reviewing在团队中是一种很好的工作方式，当某人在团队中出现问题时可以及早的发现。这不仅可以帮助大家，还可以交换彼此的进度和想法。
总之，如果你的项目正在进行代码审查，应该做到快速、有效、不浪费别人的时间。正如文章所说的，这几点非常重要。代码审查用意是在代码提交前找到其中的问题。

代码审查

代码审查可以帮助提高代码质量，避免由于代码习惯而造成的 bug。下面列出的这些要点因该可以作为大部分代码审查的指导，如果是 Java 应用的话，这些建议应该被视作最佳实践。

文档

1. 1. Javadoc 应该在每一个类和方法中添加。

1. 1. 如果是修复某个 bug，应该添加 bug ID。

1. 1. 走捷径的方法或者复杂的逻辑要有解释。

1. 1. 如果代码会被公开，每个文件头都要标注版权信息。

1. 1. 复杂的 HTML，JavaScript，CSS 应该包含文档。

功能

1. 1. 如果类似的逻辑被使用了多次，应该把它写成一个帮助类，然后在多出调用。

1. 1. 鼓励使用 API 而不是重复编写代码解决相同的问题。

1. 1. 要强调代码的单元测试。

1. 1. 任何新加的代码不应该破坏已有的代码。

1. 1. 假如是 Web 应用，JSP 不应该包含 Java 代码。

安全

1. 1. 任何代码都不能执行用户的输入，除非转义过了。这个常常包含 JavaScript 的 eval 函数和 SQL 语句。

1. 1. 禁止那些在短时间内提交非常多请求的 IP。

1. 1. 任何类，变量，还有方法都应该有正确的访问域。

1. 1. 尽量避免使用 iframe。

性能

1. 1. 所有数据库和文件操句柄在不需要的时候都应该被关闭。

1. 1. SQL 语句的写法会导致性能千差万别。

1. 1. 鼓励创建不可变（immutable）的类。

1. 1. 类似的逻辑代码，尽量通过 if else 语句来实现更多的重用。

1. 1. 尽量避免使用重对象（heavy objects）。

1. 1. 如果是 Web 项目，请检查是否使用了合适的图片尺寸，CSS sprites 和浏览器缓存等技术。

1. 1. 全局都需要的信息保存在 application context 中。

编码习惯

1. 1. 没有被使用的变量要删除。

1. 1. 针对不同的 Exception 要用不同的 catch 语句，而不是一个 Exception 解决所有问题。

1. 1. 针对变量，方法和类要用相同的命名方法。

1. 1. 常量应该被写在独立的常量类中。

1. 1. 每行代码的尾部不要有多余的空格。

1. 1. 对于括号，循环，if语句等等要用统一的格式。

1. 1. 每一个单独的方法不应该超过100行。

1. 1. 一个单独的语句不应该超过编辑器的可视区域，它可以被拆分成几行。

1. 1. 检查 String 对象既不是null也不是空的最好方法是 if(“”.equals(str))

1. 1. 假如类有很多成员变量，并且实例化的时候只需要少数变量传入的话，最好使用静态工厂方法，而不是重载构造函数。

1. 1. 给方法添加适当的访问控制，而不是所有都是 public。

1. 1. 遵守项目中使用的框架的最佳实践建议，例如 Spring，Struts，Hibernate，jQuery。

以上的某些注意点可以通过静态代码检查工具完成，例如 CheckStyle，FindBugs 和 JTest。

 

原文转载自：http://www.eoeandroid.com/thread-257098-1-1.html