【51CTO.com快译】如果您有过代码审查的经验,一定经历过高频、耗时且繁琐的拉取请求、提交确认、以及批准等过程。为了避免凌晨5点,您还在孤独地审查着从团队分配来的代码,我们走访了该领域的专家与用户,收集到了如下小贴士,以方便您快速高效地完成任务。


1、审查较小部分

通常而言,更小的提交会导致更小、且更易于管理的代码审阅。人们往往需要花较长的时间,去理解由大块代码的修改所涉及到的大量依赖项。而小块的修改不仅能够节省代码审查的时间,而且能够减轻审查人员的认知负担,方便审查过程的流畅开展。可以说,将工作量分成较小的部分,往往可以使团队成员加深对于变更意图与方式的了解。

有调查表明:一次性审查约400行代码的效果是最佳的。否则,过多的代码量,会直接导致审查者发现问题能力的下降。当然,我们也可以根据实际使用的平台、以及开发的语言,略作调整。如今大家都在谈论“长期主义”。一开始,大家可能会不太适应这种较小的审查提交方式,但是如果能长此以往地坚持下去,它的好处将非常明显。


2、时限要求

与代码测试相比,代码审查环节往往被要求在有限的时间内完成并提交。为了能够及时地发现代码本身、及其架构和时序等相关问题,审查人员往往需要对代码具有充分的了解。因此,在这种“时间紧、任务急”的情况下,团队需要对待代码的审查重点排定优先级。例如,我们可以针对如下方面,根据实际情况进行审查:

  • 条件判断语句或其他逻辑是否合理?

  • 代码中的字符串是否已格式化?

  • 是否在不必要之处使用了同步或锁的操作?

  • 是否采用了原子变量?

  • 是否使用了不必要的线程,且是否安全?

  • 数据结构是否安全且高效?

根据上述要点,我们整理出一份审查清单(下文将会提到),以方便团队合理地安排时间与精力。当然,即使在项目进度紧迫,无法进行完全代码审查的情况下,我们也需要保证新的、关键性的、具有依赖关系的代码部分,能够被审查到。


3、对事不对人

代码审查讲求的是以”对事不对人”的态度,全面提高代码的质量。例如:倘若甲发现了乙的代码中存在着问题,这并不意味着甲的编程能力强,而乙的能力弱。我们更不能据此去惩罚乙(当然,奖励甲是应该的)。否则,甲可能因为害怕破坏了与团队中其他成员的关系,而不愿在审查中指出真实潜在的问题,进而导致代码的审查效果失真。

此外,有些团队会将代码审查的任务集中在某个专人身上。这样除了会造成人员安排上的单点风险以外,还会造成其工作量上的繁重和认知度上的局限性。


4、共享编码与审查准则

既然不合适将代码审查任务固定地托付给一个人,那么我们势必要构建一个团队或小组。而为了保证集体智慧“在线”,我们需要让所有参与者都事先了解相关的审查准则。例如:

  • 规范化针对代码添加的注释,阐明代码修改的原因,以方便后续者的解读。

  • 修正编码风格,尤其是一些关键性的数据结构、以及方法的命名规则。

  • 审查是否充分考虑到了变量或异常可能出现的所有情况。

当然,对于不同的编程语言与平台,我们可以采取略有不同的编码与审查准则,并记录在案。下面是在社区里被广泛采用的代码样式标准。它们可以促进和加速新的成员,在代码风格上尽快地融入团队。

  • Ruby - http://www.caliban.org/ruby/rubyguide.shtml

  • Community-driven - https://github.com/bbatsov/ruby-style-guide

  • Github’s style - https://github.com/styleguide/ruby

  • SO Answer - http://stackoverflow.com/questions/616037/ruby-coding-style-guidelines

  • Rubydoc - http://ruby-doc.com/docs/ProgrammingRuby/

  • Javascript - https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml

  • Crockford’s guide - http://javascript.crockford.com/code.html

  • Felix’s Node style - https://github.com/felixge/node-style-guide

  • Mozilla - https://developer.mozilla.org/en-US/docs/JavaScript_Tips

  • Idiomatic.js - https://github.com/rwaldron/idiomatic.js

  • Python - http://google-styleguide.googlecode.com/svn/trunk/pyguide.html

  • Guido’s PEP8 - http://legacy.python.org/dev/peps/pep-0008/

  • python-guide.org - http://docs.python-guide.org/en/latest/writing/style/

  • PHP - https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/

  • Pear - https://dev.topear/

  • PHP-FIG - http://www.php-fig.org/

  • PSR-0: Autoloader Standard - https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

  • PSR-1: Basic Coding Standard - https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md

  • PSR-2: Coding Style Guide - https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md


5、审查清单

常言道,“按图索骥,效率最高”。我们可以参考如下清单,来逐条检查并提高代码审查的流程与效率。

编程习惯方面

  • 是否删除了每行代码尾部的多余空格。

  • 是否存在从未被用到的变量。

  • 是否针对变量、方法、以及类采用了相同的命名规则。

  • 对于括号、循环、if语句等是否采用了统一的格式。

  • 是否将常量写在了独立的常量类中。

  • 是否针对不同的异常(exception),采用了不同的捕获(catch)语句。

  • 是否避免了单个方法过于冗长。

  • 为了避免一条语句过长,且超过编辑工具的可视区域,是否按需对其进行了拆分。

  • 是否给各种方法添加了适当的访问控制,而非一律采用public。

  • 是否合理地用到了静态工厂方法,而非重载构造函数。

功能方面

  • 如果某个逻辑会被多次使用到,那么就应该将它写成帮助类或是API,以便被频繁调用。

  • 不同语言的代码不应被相互混用。例如,在JSP中就不应包含Java代码。

安全方面

  • 任何代码在未经转义之前,都不应直接执行用户的输入。例如JavaScript中的eval函数,以及SQL语句。

  • 在代码级别上,禁止那些在较短时间内,被大量提交的IP请求。

  • 是否为每个类、变量、以及方法都设置了正确的访问域。

性能方面

  • 是否能及时地关闭不需要的数据库实例、以及文件的操作句柄。

  • SQL语句的用法是否规范。

  • 是否按需创建了immutable的类。

  • 是否避免使用了heavy对象。

  • 是否将全局信息保存在“application context”中。

文档方面

  • 是否说明了代码中的每一个类、方法、及其基本逻辑。

  • 是否提供了针对复杂的HTML、JavaScript、以及CSS等相关文档说明。

  • 是否为代码文件的头部添加了相关的版权信息。

  • 如果是对某个缺陷的修复,是否分配了对应的缺陷ID。

与此同时,您可以参考诸如:DRYSRPKISSYAGNISmell等原则, 以及如下三种审查清单模板:

  • http://www.codeproject.com/Articles/593751/Code-Review-Checklist-and-Guidelines-for-Csharp-De

  • http://courses.cs.washington.edu/courses/cse403/12wi/sections/12wi_code_review_checklist.pdf

  • https://www.liberty.edu/media/1414/%5B6401%5Dcode_review_checklist.pdf


6、使用自动化协同审查工具

在处置Git存储库里的频繁提交等场景时,光靠一双眼睛式的人工审查方式,显然是非常低效且耗时的。为了发挥团队的优势,我们需要引入协同审查工具,以实现更快速、更自动化、更全面的合作式审查。目前,Github、Bitbucket和GitLab都能够通过拉取式请求的特性,提供内置的代码审查工作流。当然,我们也可以用到诸如:CheckStyle、PMD、FindBugs、Upsource、以及Codacy等工具。


7、使用短路

如果您时间非常紧迫,并且无法去逐行检查代码的内容,那么请采用“抓大放小”渐进的方法。毕竟,那些在函数调用时可能引起缓冲区溢出的问题,以及在生产环境中会导致程序崩溃的潜在缺陷,比起一眼可以看出的代码样式问题,要重要得多。您可以在代码检查中,插入所谓短路(short-circuiting)元素,以事先处置和纠正重大的问题,而将较小的缺陷,留待将来时间充沛时,再予以更正。

8、提交与确认

从某种意义上说,代码审查旨在提高开发者的编程能力,让其从自身犯过的错误中吸取教训,从他人的修改思路中学习进步,而应当避免其产生抵触或反感情绪。

值得注意的是,代码审查人员不应以交付时限为由,针对其发现的问题,直接对代码进行修改,甚至予以重构,而应当提请代码开发人员进行确认。此方法不但可以确认问题是否真实存在,并共同获取最佳解决方案;而且可以让代码作者深入了解其自身的不足,协助其不断进步。作为参考,您可以通过链接--https://www.kernel.org/doc/Documentation/SubmittingPatches,借鉴一下Linux内核是如何指导其开发社区进行问题的提交与处置的。

原文标题:Top 10 Ways to Perform Fast Code Reviews,作者:Gustavo Silva

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】