代码review总结

Code Review应该是软件工程最最有价值的一个活动，之前，本站发表过《简单实用的Code Review工具》，那些工具主要是用来帮助更有效地进行这个活动，这里的这篇文章，我们主要想和大家分享一下Code Review代码审查的一些心得。

首先，我们先来看看Code Reivew的用处：

1. Code reviews 中，可以通过大家的建议增进代码的质量。
2. Code reviews  是一个传递知识的手段，可以让其它并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码。
3. Code reviews 也鼓励程序员们相互学习对方的长处和优点。
4. Code reviews 也可以被用来确认自己的设计和实现是一个清楚和简单的。

你也许注意到了在上面的Code Reivew中的诸多用处中，我们没有提到可以帮助找到程序的bug和保证代码风格和编码标准。这是因为我们认为：

1. Code reviews 不应该承担发现代码错误的职责。Code Review主要是审核代码的质量，如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。代码中的bug和错误应该由单元测试，功能测试，性能测试，回归测试来保证的（其中主要是单元测试，因为那是最接近Bug，也是Bug没有扩散的地方）
2. Code reviews 不应该成为保证代码风格和编码标准的手段。编码风格和代码规范都属于死的东西，每个程序员在把自己的代码提交团队Review的时候，代码就应该是符合规范的，这是默认值，属于每个人自己的事情，不应该交由团队来完成，否则只会浪费大家本来就不够的时间。我个人认为“meeting”是奢侈的，因为那需要大家在同一时刻都挤出时间，所以应该用在最需要的地方。代码规范比起程序的逻辑和对需求设计的实现来说，太不值得让大家都来了。

10年前，上面这两件事会是理所当然的（10年前的中国的软件开发还没有Code Reivew呢），今天，在中国的很多公司上面这两件事依然被认为是Code Reivew最重要的事，所以，我能够看到很多开发Team抱怨Code Review就是一个形式，费时费力不说，发现的问题还不如测试，而评审者们除了在代码风格上有些见术，别的也就没什么用了，长而久之，大家都会开始厌烦这个事了。

所以，在今天，请不要把上面的那两件事分散了Code Review的注意力，取而代之的是，对于Bug，程序的作者要在Review前提交自己的单元测试报告（如：XUnit的测试结果），对于代码规范，这是程序作者自己需要保证的，而且，有一些工具是可以帮你来检查代码规范的。

当然，上述这些言论并不是说，你不能在Code Review中报告一个程序的bug或是一个代码规范的问题。我只是说，那并不是Code Review的意图。

Code Review的原则

1.- 经常进行Code Review

以前经历过几个相当痛苦的Code Review，那几次Code Review都是在程序完成的时候进行的，当你面对那近万行的代码，以前N多掺和在一起的功能，你会发现，整个Code Review变得非常地艰难，用不了一会儿，你就会发现大家都在拼命地打着哈欠，但还是要坚持，有时候，这样的Review会持续3个小时以上，相当的夸张。而且，会议上会出现相当多的问题和争论，因为，这就好像，人家都把整个房子盖好了，大家Review时这挑一点那挑一点，有时候触动地基或是承重墙体，需要大动手术，让人返工，这当然会让盖房的人一下就跳起来极力地维护自己的代码，最后还伤了团队成员的感情。

所以，千万不要等大厦都盖好了再去Reivew，而且当有了地基，有了框架，有了房顶，有了门窗，有了装修，的各个时候循序渐进地进行Review，这样反而会更有效率，也更有帮助。

下面是一些观点，千万要铭记：

• 要Review的代码越多，那么要重构，重写的代码就会越多。而越不被程序作者接受的建议也会越多，唾沫口水战也会越多。
  
• 程序员代码写得时候越长，程序员就会在代码中加入越来越多的个人的东西。 程序员最大的问题就是“自负”，无论什么时候，什么情况下，有太多的机会会让这种“自负”澎涨开来，并开始影响团队影响整个项目，以至于听不见别人的建议，从而让Code Review变成了口水战。
• 越接近软件发布的最终期限，代码也就不能改得太多。

我个人的习惯，并且也是对团队成员的要求是——先Review设计实现思路，然后Review设计模式，接着Review成形的骨干代码，最后Review完成的代码，如果程序复杂的话，需要拆成几个单元或模块分别Review。当然，最佳的practice是，每次Review的代码应该在1000行以内，时间不能超过一部电影的时间——1.5小时（因为据说那个一个正常人的膀胱可以容纳尿液的最长限度）

当然，在敏捷开发中，他们不需要Code Reivew，其实，敏捷开发中使用更为极端的“结对编程”（Pair-Programming）的方法 —— 一种时时刻刻都在进行Code Review的方法，个人感觉在实际过程中，这种方法有点过了。另外，大家可以看看本站的另一篇文章《结对编程的利与弊》来了解一下这种方法的问题。

2.- Code Review不要太正式，而且要短

忘了那个代码评审的Checklist吧，走到你的同事座位跟前，像请师父一样请他坐到你的电脑面前，然后，花5分钟给他讲讲你的代码，给他另外一个5分钟让他给你的代码提提意见，这比什么都好。而如果你用了一个Checklist，让这个事情表现得很正式的话，下面两件事中必有一件事会发生：

1. 只有在Checklist上存在的东西才会被Review。
2. Code Reviews 变成了一种礼节性的东西，你的同事会装做很关心你的代码，但其实他心里想着尽快地离开你。

只有不正式的Code Review才会让你和评审者放轻松，人只有放松了，才会表现得很真实，很真诚。记住Review只不过是一种形式，而只有在相互信任中通过相互的讨论得到了有意义和有建设性的建议和意见，那才是最实在的。不然，作者和评审者的关系就会变成小偷和警察的关系。

3.- 尽可能的让不同的人Reivew你的代码

这是一个好主意，如果可能的话，不要总是只找一个人来Review你的代码，不同的人有不同的思考方式，有不同的见解，所以，不同的人可以全面的从各个方面评论你的代码，有的从实现的角度，有的从需求的角度，有的从用户使用的角度，有的从算法的角度，有的从性能效率的角度，有的从易读的角度，有的从扩展性的角度……，啊，好多啊，还让不让人活了。不管怎么说，多找一些不同的人会对你很有好处。当然，不要太多了，人多嘴杂反而适得其反，基本上来说，不要超过3个人，这是因为，这是一个可以围在一起讨论的最大人员尺寸。

下面是几个优点：

1. 从不同的方向评审代码总是好的。
2. 会有更多的人帮你在日后维护你的代码。
3. 这也是一个增加团队凝聚力的方法。

4.- 保持积极的正面的态度

再说一次，程序最大的问题就是“自负”，尤其当我们Reivew别人的代码的时候，我已经见过无数的场面，程序员在Code Review的时候，开始抨击别人的代码，质疑别人的能力。太可笑了，我分析了一下，这类的程序员其实并没有什么本事，因为他们指责对方的目的是想告诉大家自己有多么的牛，靠这种手段来表现自己的程序员，其实是就是传说中所说的“半瓶水”。

所以，无论是代码作者，还是评审者，都需要一种积极向上的正面的态度，作者需要能够虚心接受别人的建议，因为别人的建议是为了让你做得更好；评审者也需要以一种积极的正面的态度向作者提意见，因为那是和你在一个战壕里的战友。记住，你不是一段代码，你是一个人！

5.- 学会享受Code Reivew

这可能是最重要的一个提示了，如果你到了一个人人都喜欢Code Reivew的团阿，那么，你会进入到一个生机勃勃的地方，在那里，每个人都能写出质量非常好的代码，在那里，你不需要经理的管理，团队会自适应一切变化，他们相互学习，相互帮助，不仅仅是写出好的代码，而且团队和其中的每个人都会自动进化，最关键的是，这个是一个团队。

程序员必备的代码审查（Code Review）清单

在我们关于高效代码审查的博文中，我们建议使用一个检查清单。在代码审查中，检查清单是一个非常好的工具——它们保证了审查可以在你的团队中始终如一的进行。它们也是一种保证常见问题能够被发现并被解决的便利方式。

软件工程学院的研究表明，程序员们会犯15-20种常见的错误。所以，通过把这些错误加入到检查清单当中，你可以确保不论什么时候，只要这些错误发生了，你就能发现它们，并且可以帮助你杜绝这些错误。

为了帮助你开始创建一个清单，这里列出了一些典型的内容：代码审查清单。

设计常规项

• 设计是否合理符合mvpd，
• 逻辑是否考虑闭环全面考虑
• 扩展性是否考虑
• 是否存在安全漏洞

编码常规项

• 代码是否内存泄漏，是否UI成红色，是否性能低下，是否会形成crash
• 各种异常逻辑是否处理
  
• 代码能够工作么？它有没有实现预期的功能，逻辑是否正确等。
• 所有的代码是否简单易懂？
• 代码符合你所遵循的编程规范么？这通常包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。
• 是否存在多余的或是重复的代码？
• 代码是否尽可能的模块化了？
• 是否有可以被替换的全局变量？
• 是否有被注释掉的代码？
• 循环是否设置了长度和正确的终止条件？
• 是否有可以被库函数替代的代码？
• 是否有可以删除的日志或调试代码？

安全

• 所有的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）并且进行了编码？
• 在哪里使用了第三方工具，返回的错误是否被捕获？
• 输出的值是否进行了检查并且编码？
• 无效的参数值是否能够处理？

文档

• 是否有注释，并且描述了代码的意图？
• 所有的函数都有注释吗？
• 对非常规行为和边界情况处理是否有描述？
• 第三方库的使用和函数是否有文档？
• 数据结构和计量单位是否进行了解释？
• 是否有未完成的代码？如果是的话，是不是应该移除，或者用合适的标记进行标记比如‘TODO’？

测试

• 代码是否可以测试？比如，不要添加太多的或是隐藏的依赖关系，不能够初始化对象，测试框架可以使用方法等。
• 是否存在测试，它们是否可以被理解？比如，至少达到你满意的代码覆盖(code coverage)。
• 单元测试是否真正的测试了代码是否可以完成预期的功能？
• 是否检查了数组的“越界“错误？
• 是否有可以被已经存在的API所替代的测试代码？

总结

你同样需要把特定语言中有可能引起错误的问题添加到清单中。

这个清单故意没有详尽的列出所有可能会发生的错误。你不希望你的清单是这样的，太长了以至于从来没人会去用它。仅仅包含常见的问题会比较好。

优化你的清单

把使用清单作为你的起点，针对特定的使用案例，你需要对其进行优化。一个比较棒的方式就是让你的团队记录下那些在代码审查过程中临时发现的问题，有了这些数据，你就能够确定你的团队常犯的错误，然后你就可以量身定制一个审查清单。确保你删除了那些没有出现过的错误。（你也可以保留那些出现概率很小，但是非常关键的项目，比如安全相关的问题）。

得到认可并且保持更新

基本规则是，清单上的任何条目都必须明确，而且，如果可能的话，对于一些条目你可以对其进行二元判定。这样可以防止判断的不一致。和你的团队分享这份清单并且让他们认同你清单的内容是个好主意。同样的，要定期检查你的清单，以确保各条目仍然是有意义的。

有了一个好的清单，可以提高你在代码审查过程中发现的缺陷个数。这可以帮助你提高代码标准，避免质量参差不齐的代码审查。

5个开源的代码审查工具

1. Review board:
Review board 是一个 基于web 的工具，是由 django 和python设计的。 Review board 可以帮助我们追踪待决代码的改动，并可以让Code-Review更为容易和简练。尽管Review board 最初被设计在VMware项目中使用，但现在其足够地通用。当前，其支持这些代码版本管理软件： SVN, CVS, Perforce, Git, Bazaar, 和Mercurial.

Yahoo 是review-board的其中一个用户。

“Review board 已经改变了代码评审的方式，其可以强迫高质量的代码标准和风格，并可以成为程序员编程的指导者。每一次，当你访问search.yahoo.com 时，其代码都是使用 Review board工具Review过的。 We’re great fans of your work!” – Yahoo! Web Search

2. Codestriker:
Codestriker 也是一个基于Web的应用，其主要使用 GCI-Perl 脚本支持在线的代码审查。Codestriker 可以集成于CVS, Subversion, ClearCase, Perforce 和Visual SourceSafe。并有一些插件可以提供支持其它的源码管理工具。

David Sitsky 是 Codestriker 的作者，并也是最活跃的开发人员之一。 Jason Remillard 是另一个活路的开发者，并给这个项目提供了最深远最有意义的贡献。大量的程序员贡献他们的代码给 Codestriker 项目，导致了这个项目空前的繁荣。

3. Groogle:
Groogle 是一个基于WEB的代码评审工具。 Groogle 支持和 Subversion 集成。它主要提供如下的功能：

• 各式各样语言的语法高亮。
• 支持整个版本树的比较。
• 支持当个文件不同版本的diff功能，并有一个图形的版本树。
• 邮件通知所有的Reivew的人当前的状态。
• 认证机制。

4. Rietveld:
Rietveld 由Guido van Rossum 开发（他是Python的创造者，现在是Google的员工），这个工具是基于Mondrian 工具，作者一开始是为了Google 开发的，并且，它在很多方面和Review board 很像。它也是一个基于Web的应用，并在Google App Engine 上。它使用了目前最流行的Web开发框架 django 并支持 Subversion 。当前，任何一个使用 Google Code 的项目都可以使用 Rietveld 并且使用 python Subversion 服务器。当然，它同样支持其它的Subversion服务器。

 

5. JCR
JCR 或者叫做 JCodeReview 也是一个基于WEB界面的最初设计给Reivew Java 语言的一个工具。当然，现在，它可以被用于其它的非Java的代码。

JCR 主要想协助：

• 审查者。所有的代码更改都会被高亮，以及大多数语言的语法高亮。Code extracts 可以显示代码评审意见。如果你正在Review Java的代码，你可以点击代码中的类名来查看相关的类的声明。
• 项目所有者。可以 轻松创建并配置需要Review的项目，并不需要集成任何的软件配置管理系统（SCM）。
• 流程信仰者。 所有的评语都会被记录在数据库中，并且会有状态报告，以及各种各样的统计。
• 架构师和开发者。 这个系统也可以让我们查看属于单个文件的评语，这样有利于我们重构代码。

JCR 主要面对的是大型的项目，或是非常正式的代码评审，从这方面看来，他并不像上面的那些工具。

Jupiter：最后我们要提一下Jupiter，这是另一个代码review的工具你可以去考虑使用的，它是一个Eclipse IDE 的插件。

如何有效开展CodeReview活动？

要想在团队内部有效运作CodeReview活动，必备四要素（如下图）。如果您的团队没有把CodeReview活动有效开展下去或者正深受烦恼，这部分内容希望您仔细看看。

1、代码规范：明确Coding规则

如果一开始不定义好团队Coding标准，那在检视过程中就会存在两种情况：一种是各种不同的意见很难快速达成一致，影响review效率，另外一种是团队根本就不会重视代码规范的检视， 如果是前者还好，毕竟大家都还在关注什么写法是好的或对的这个问题，只要中途愿意建立起Coding规则，问题就能很快解决。而笔者跟进过的一个团队恰恰就出现了后者的情况：该团队由于前期没有明确Coding规则， 过程中大部分开发人员对规范类问题直接无视，CodeReview运作一段时间后代码中依然存在命名不规范，可读性较差等问题，直接影响了活动效果，这是我们非常不愿意看到的。

当然也有团队负责人说了，每天纠结于空格少了，行数字符多了等细节问题没意义啊，不想浪费这个时间，因此我们不需要代码规范。我个人不认同这个观点，因为代码规范并不只包括空格和字符等约束纬度，还包括了注释的要求，命名的规范，命名是否词能达意，代码结构安排等等影响代码可读性的因素， 如若这些方面连基本规则都没有，那一定会出现之前说的那两种情况（争议太多 or 完全忽视），效果可想而知。所以你可以根据自己的看法或需求做一定的规则定制，但不能没有Coding规则。

2、检视指南：消除困惑和迷茫

检视指南又名CodeReview-checklist。一个团队并不是所有人都是老司机，有很多同学是没有代码review经验的，他们往往不知道应该重点 check哪些点。

这个时候结合自身业务特点和团队之前踩过的坑，制定一个checklist是非常必要的:

• 什么写法可能导致性能低下？
• 哪个接口要慎用？
• 哪些设计方式需要规避？
• 什么习惯容易引发内存泄漏？
• 等等。。。

这样可以让经验不足者在不知道要review什么时，能有的放矢，过程中逐步积累起经验。

以下是一个团队建立起检视指南前后，CodeReview发现问题数的变化，足见建立检视指南的重要性。

当然也有人说，我的团队代码检视都是让资深骨干做的，不存在不知道怎么review的情况。

但是我想说，骨干员工的时间毕竟很宝贵，他们也往往很忙碌，为什么不让更多的成员一起来参与review工作呢，毕竟CodeReview不仅仅是找茬，也是代码的交流和学习！

3、总结优化：透明问题，持续优化（非常重要）

我们看到很多团队的CodeReview活动坚持不下来或逐步流于形式，其实最主要原因是过程中缺乏定期回顾和总结，从而不知道如何有效促进和帮助团队更好运作。

为了更好地促进这项活动，手机管家高权限应用组就专门成立了CodeReview组委会，这个组织每月都会对CodeReview运作状况进行总结，分析问题，解决问题，持续优化，其最后的效果能在团队内外均获得较高的认同度，可以说总结优化这个环节起到了非常关键的作用。

4、激励机制：激发主观能动性

由于CodeReview本身跟人的经验或者意识都有很大关系，很多时候我们会为调动不起开发同学的积极性而烦恼，所以为了让大家更好的参与这个活动，我们一般都需要制定相应的激励机制。也有人说了，如果是leader强制跟考核挂钩，那就不需要这个东东了，嗯，但换个角度看，跟考核挂钩难道不是另外一种“激励”方式吗？哈哈。。。

激励机制的设立有很多种，一般来说，都是在定期回顾的基础上根据CodeReview的实际情况对表现积极的同学进行一定的礼品奖励（选择什么礼品，要看组织的经济状况，哈哈）。

笔者跟进的团队每月会从CodeReview提交次数和发现问题数等纬度进行质量之星选举，礼品包括了书籍，公仔，徽章等等，效果不错，做法供大家参考。

总之，代码规范、检视指南、总结优化和激励机制这四个因素对成功运作CodeReview活动都非常关键，但每一项里面的内容具体要如何定义，团队在参考业界做法的基础上可根据实际情况进行一定的定制。

CodeReview方式很多，用哪种会比较好

呢？

目前业界运作CodeReview的方式有多种方式：强制&非强制、线上交流&线下会议、小片段&大模块、事前&事后、高频率&低频率，等等……据了解，目前每种形态都有各自的市场，被不同的团队运用着。

接下来笔者个人角度分析下各种形态的优缺点，供大家参考：

1. 强制&非强制： 按照经验，CodeReview启动前期建议采用强制要求，否则很难有效开展起来。坚持一段时间待习惯养成后再考虑自由度。

2. 小片段&大模块：如果想要让问题暴露更充分或降低review的难度，建议采用细粒度方式进行，即小片段提交小片段review。如果更关注全局设计和逻辑思路的学习和找茬，那么可以用模块方式统一review。但很多时候这两种方式是可以结合运作的。

3. 线上交流&线下会议： 如果想提高效率，建议采用线上方式进行交流，这里要推荐公司的Code平台，上面支持CodeReview的功能都已经比较齐全。如果更喜欢全员一起找茬的那种快感，那么可以采用线下会议方式开展，但采用开会的方式，一般成本较高，可看团队接受度。

4. 事前&事后：这里指的是发布前还是发布后。版本发布后统一进行CodeReview的方式更多是一种代码交流活动， 起不到代码质量把关的作用。反之，如果在版本发布前就对代码进行CodeReview，就可以对质量问题起到很好的把关作用。这里是时间和质量之间的权衡。

5. 高频率&低频率：笔者建议的是把代码交流放在每一天，所以频率越高越好。具体根据团队实际情况进行安排即可。

6. 此外，也有团队采用模块owner把关质量的CodeReview方式，这种更多是从质量风险规避角度上考虑，在代码提交前owner检查是否有质量问题，确认没有问题后方能发布，有这方面需要的团队也可以考虑这种方式。

最后组合一下，笔者个人推荐的CodeReview方式是强制+事前+小片段+线上交流+高频率，同时，如果能结合线下的大模块方式开展代码交流活动，效果会更好，这个经验来自手机管家高权限应用组的接地气实践。

但是，团队状态不一样，选择方式允许有差异，所以具体选用哪种方式组合，还是要由团队自己作主。

五、结语总结

为了让这篇文章能给读者带来一定帮助，笔者反复进行了review和相应的修改操作，且不论最终目的有没有达到，至少态度和行为上都已努力做到最好。

同样，笔者认为，开发编写的Code, 要想让别人更容易读得懂，一定也需要review才有可能达到目的