【.com快译】如果你有过代码审查的经验，那你一定经历过pullrequest、commitconfirmation、approval这个高频、耗时、繁琐的过程.为了避免你凌晨5点独自review团队分配的代码，我们采访了该领域的专家和用户，收集了以下tips，方便你快速高效的完成任务。1.审查较小的部分一般来说，较小的提交会导致更小、更易于管理的代码审查。人们往往需要很长时间才能理解修改大块代码所涉及的大量依赖关系。微小的修改不仅可以节省代码审查的时间，还可以减轻审查人员的认知负担，促进审查过程的顺利开展。可以说，将工作量分解成更小的部分通常可以让团队成员更好地理解变更的意图和方式。有调查表明，一次review400行左右的代码效果最好。否则代码过多会直接导致审稿人发现问题的能力下降。当然，我们也可以根据实际使用的平台和开发的语言进行微调。现在每个人都在谈论“长期主义”。这种较小的评论提交一开始可能会让人不舒服，但如果你长期坚持下去，好处将是显而易见的。2、时限要求与代码测试相比，代码审查往往要求在限定时间内完成并提交。审阅者往往需要对代码有很好的理解，以便能够及时发现代码本身、其架构和时序以及其他相关问题。因此，在这种“时间紧，任务紧”的情况下，团队需要优先考虑代码的review重点。例如，我们可以根据实际情况从以下几个方面进行审查：条件判断语句或其他逻辑是否合理？代码中的字符串是否格式化？是否在不必要的地方使用了同步或锁定操作？原子变量？是否使用了不必要的线程并且它们安全吗？数据结构是否安全高效？基于以上几点，我们整理了一份reviewchecklist（下文会提到），方便团队合理安排时间和精力。当然，即使在项目时间紧迫，无法进行完整代码审查的情况下，我们仍然需要确保新的、关键的、依赖的代码部分能够被审查。3、不与人打交道。codereview强调的是“不与人打交道”的态度。全面提升代码质量。例如：A发现B的代码有问题，并不代表A编程能力强，B能力弱。我们不能据此惩罚B（当然应该奖励A）。否则，A可能会因为害怕破坏与团队其他成员的关系而不愿在审查中指出真正的潜在问题，从而导致代码审查效果扭曲。此外，一些团队会将代码审查的任务集中在专人身上。这不仅会造成人员安排上的单点风险，还会造成工作量大和认知局限。4.共享编码和审查指南由于将代码审查任务委托给一个人是不合适的，因此我们必须建立一个团队或小组。为确保集体智慧“在线”，我们需要让所有参与者提前知晓相关评审指南。例如：规范代码中添加的注释，明确代码修改的原因，方便后续解读。修改编码风格，特别是一些关键的数据结构和方法命名规则。检查是否已充分说明可能出现变量或异常的所有可能情况。当然，我们可以针对不同的编程语言和平台采用并记录略有不同的编码和审查指南。以下代码风格标准在社区中被广泛采用。他们可以促进和加速新成员，并在代码风格方面尽快融入团队。Ruby-http://www.caliban.org/ruby/rubyguide.shtml社区驱动-https://github.com/bbatsov/ruby-style-guideGithub的风格-https://github.com/styleguide/ruby所以答案-http://stackoverflow.com/questions/616037/ruby-coding-style-guidelinesRubydoc-http://ruby-doc.com/docs/ProgrammingRuby/Javascript-https://google-styleguide.googlecode。com/svn/trunk/javascriptguide.xmlCrockford的指南-http://javascript.crockford.com/code.htmlFelix的节点风格-https://github.com/felixge/node-style-guideMozilla-https://developer.mozilla.org/en-US/docs/JavaScript_TipsIdiomatic.js-https://github.com/rwaldron/idiomatic.jsPython-http://google-styleguide.googlecode.com/svn/trunk/pyguide。htmlGuido的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：自动加载器标准-https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.mdPSR-1：基本编码标准-https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.mdPSR-2：编码风格指南-https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md5、reviewchecklist俗话说“看图看效率最高”。大家可以参考下面的清单一一检查，提高codereview的流程和效率。编程习惯上，是否删除每行代码末尾多余的空格。是否有从未使用过的变量。是否对变量、方法和类使用相同的命名约定。括号、循环、if语句等是否采用统一格式。是否将常量写在单独的常量类中。不同的异常是否使用不同的catch语句。是否避免单一方法过于冗长。为了防止语句过长超出编辑工具的可见区域，是否已经按要求拆分。是否对各种方法添加适当的访问控制，而不是使用public。使用静态工厂方法而不是重载构造函数是否合理。在功能上，如果某个逻辑会被多次使用，就应该写成辅助类或者API，这样可以经常调用。不同语言的代码不要相互混用。例如，Java代码不应包含在JSP中。安全方面任何代码都不应在不转义的情况下直接执行用户输入。比如JavaScript中的eval函数，SQL语句。在代码层面，禁止在较短时间内大量提交的IP请求。是否为每个类、变量和方法设置了正确的访问范围。在性能方面，是否能及时关闭不需要的数据库实例和文件操作句柄。SQL语句的使用是否规范。是否按需创建不可变类。是否避开重物。是否在“应用程序上下文”中保存全局信息。文档方面，是否对代码中的每个类、方法、基本逻辑进行了说明。是否为复杂的HTML、JavaScript和CSS提供相关文档说明。是否在代码文件头部添加相关版权信息。如果是缺陷的修复，是否分配了相应的缺陷ID。同时可以参考如：DRY、SRP、KISS、YAGNI、Smell等原则，以及以下三个reviewchecklist模板：http://www.codeproject.com/Articles/593751/Code-Review-Checklist-and-Guidelines-for-Csharp-Dehttp://courses.cs.washington.edu/courses/cse403/12wi/sections/12wi_code_review_checklist.pdfhttps://www.liberty.edu/media/1414/%5B6401%5Dcode_review_checklist。pdf6.在使用自动化协同审阅工具应对Git仓库频繁提交等场景时，依靠一双眼睛进行人工审阅显然是非常低效和耗时的。为了发挥团队的优势，我们需要引入协同审稿工具，以实现更快、更自动化、更全面的协同审稿。目前，Github、Bitbucket和GitLab都通过拉取请求功能提供内置代码审查工作流程。当然，我们也可以使用诸如：CheckStyle、PMD、FindBugs、Upsource、Codacy等工具。7、使用短路如果你时间很紧，无法逐行查看代码内容，那么请采用“抓大放小”的循序渐进的方法。毕竟，在函数调用中可能导致缓冲区溢出的潜在错误，以及在生产中可能导致程序崩溃的潜在错误，远比一眼就能看出的代码风格问题重要。你可以在代码检查中插入所谓的短路元素，提前处理和纠正主要问题，而将小缺陷留到以后有足够时间的时候再纠正。8.提交和确认从某种意义上说，代码审查旨在提高开发人员的编程能力，让他们从自己的错误中吸取教训，并从他人的修改思路中吸取教训，但要避免冲突或反感。值得注意的是，代码审查人员对于发现的问题，不应以交付期限为由直接修改甚至重构代码，而应向代码开发人员寻求确认。这种方法不仅可以确认问题是否真的存在，共同得出最佳解决方案；也能让代码作者深刻认识自身的不足，协助其不断改进。作为参考，您可以使用链接——https://www.kernel.org/doc/Documentation/SubmittingPatches来了解Linux内核如何引导其开发社区提交和处理问题。原标题：Top10WaystoPerformFastCodeReviews，作者：GustavoSilva
