论代码审查的重要性

【编者按】本文做者为 Hugo Giraudel，主要从各个角度论证了代码审查的重要性以及实现方法。文章系国内 ITOM 管理平台 OneAPM 编译呈现。如下为正文。

最近，笔者在Twitter上看到这样一句话：

可悲的是，对于不少学生、自由职业者以及机构来讲，代码审查彷佛至关陌生。

很明显，代码审查的重要性并不为每一个人所熟知。你能够说我很天真，可是笔者确实认为全部的IT公司都离不开该过程。显然实际并不是如此，真是让我大吃一惊。

在本文中，笔者想给出关于代码审查的想法，以及为何我认为这是代码迁移过程当中很是重要的组成部分，怎样进行审查等。若是你目前不进行代码审查，或者想要作得更好，但愿本文能有助于你！

什么是代码审查？

咱们生活在维基百科的时代，因此开始以前，先引用一下其中关于代码审查的定义：

代码审查是计算机源代码的系统性检验（有时被称为同行评审）。其目的在于找到开发初期所忽略的错误，从而提升软件的总体质量。审查的形式多种多样，如结对编程，非正式走查，正式检查等。

顾名思义，代码审查就是审查一些代码，以确保其可以正常工做，并尽量改善其性能。

代码审查的方法

正如维基百科中的定义，代码审查有多种方法。然而，目前太多的代码都存在于GitHub上，代码审查也就常常伴随着所谓的“pull request”出现。

Pull request是一个请求，使用分布式版本控制系统（Git、SVN、Mercurial等）对代码库做出修改。它经过“牵引”原代码、写入更改，而后提交请求以便将更改合并。

得益于GitHub友好的用户界面，这个过程变得很是简单高效，GitHub也归纳了大部分Git知识需求。

为何代码审查很是重要

那么，既然咱们能够不通过任何审查与监督，直接进行代码迁移，为何代码审查还这么重要呢？毕竟，咱们都能胜任该工做。

从理论上说是这样。但在实践中，有不少缘由能够代表代码审查的重要性。让咱们来看看其中的几个。

下降风险

这多是最重要的缘由。有专人复核咱们的工做并非无关痛痒的，这能下降被忽视的错误所带来的风险。毕竟即便再好的开发人员也有可能一时失察。

而且，确保没有忘记任何事情老是有必要的。举例来讲，前端开发中常常会忽略适当的键盘导航，屏幕阅读器的可用性，适应国际化的灵活性，以及友好的非JavaScript行为等问题，在这里仅列出这四项。

显著提升代码质量

清楚点说，这不是单纯的代码标准和代码检查（至少不全是），而是使代码更高效。

在一个团队里，每一个人都有本身的背景和特长，而团队始终须要进步。所以总有人可能提出更聪明的解决方案，更合适的设计模式，或者能下降复杂性或提升性能的方法。

使每一个人都获得提升

经过合做，每一个人均可以相互学习并取得进步。提交代码者颇有可能从该工做中获得反馈，并意识到可能存在的问题和须要改进的部分；而审查者也能够经过阅读他人代码学到新的东西，并找出适用于他们本身的工做方案。

有助于熟悉项目

当一个团队在作一个项目时，想要每一个开发人员致力于应用的每一个部分，这是极不可能的。有时候，会出现这种状况：在某一段时间，一个开发人员正为项目的大部分模块辛苦地工做，而另外一我的则彻底在作别的东西。

所以，代码审查有助于人们了解其余人所写，但之后可能会须要本身来维护的那部分代码。它促进了代码库知识在团队中的传播，也有可能加快将来的发展。

怎样适当地进行代码审查

再次强调，有固定的代码审查过程很是有用，很是重要。无论用什么方法，每一个团队创造的代码都应该进行代码审查。

话虽这么说，但进行有意义的代码审查并不像看上去那么简单明了。不过，别担忧，即便作得很差也不会有什么坏处，就是浪费点时间。

最近，个人团队回顾了以前进行的代码审查。当咱们意识到12个开发人员中，只有3个在作代码审查时，咱们就明白有些地方出了问题。

为了改变这种情况，咱们的一位 Scrum 专家组织了一次回顾分析，以肯定还可能改进的空间，以及咱们将怎样改变。

提早规划

代码审查作得不够，为了自圆其说，最经常使用的借口就是，它须要时间——其余人不能或不肯意在这上面花费时间。

我必须说，笔者并不太理解这种说法，由于个人观点是：若是一个同事直接来找我，让我帮他的忙，我就不会说“我没有时间，也不感兴趣”。反而，我会抽空来帮忙，可能不是如今，是一个小时以后——可是显然，我会花时间帮助他们。为何呢？ 由于：

• 这就是团队的意义；

• 他们询问我，这是由于他们看重个人意见，这就值得我去帮助他们。

“为何你不作代码审查呢？”
“我没有时间。”

对笔者而言，“pull request”和同事向我寻求帮助没什么不一样。有时候说你没时间是能够接受的，但系统性地拒绝帮助别人，就代表你正在积极地让本身脱离团队。这种行为不友好，也不积极。因此要肯花时间提供帮助。

为了让开发人员抽出时间，咱们就开始考虑让每一个程序员天天花一点时间（也许30分钟）审查代码。咱们完成天天半小时的代码审查时也不会发现什么意外惊喜：这只是一天中的一部分。

咱们之前还试着大幅度下降 “pull request”包含的代码量。由于曾经的“pull request”很是多——几十个文件中有数以千计的改动。

咱们如今尽可能不那么作了。经过建立较小的“pull request”，审查代码变得更加容易，反馈也更加中肯，开发人员也更愿意参与这个过程。“代码迁移量更小也更频繁”。

结合语境

咱们发现的第二大问题是，咱们一般缺少对代码背景的理解，若是你想要提供有用的反馈，这就颇有必要。离开了代码背景，咱们一般也只能进行语法检查——这虽然在必定程度上也有用，但远远不够。这时候你就变成了咱们所说的“人工审查器”。

幸亏，这个问题比较好解决：给pull request添加一个描述以解释你的目的，如何达到目的。这不须要一大段文字，一般短短几行足矣。将连接添加到and/or也会起做用。Liv Madsen是咱们的一位开发者，她甚至增长了截屏——或者相关的截屏视频——来解释她作的东西，这使人称奇。

实际询问

第三个问题就是咱们有时干脆没有意识到须要审查什么。的确，咱们天天都充斥着无数的电子邮件和通知 ——邮件太多了，所以很难保存。毕竟咱们只是普通的人。

一样，解决办法很简单：直接向别人询问须要审查的代码。这有不少方法，好比在办公室问一声，或者直接在Slack上给你团队的同事发消息。

咱们基于本身的活动在GitHub上建立了群组，当提交pull request时，老是ping一个群组。群组的成员都会收到通知，而且只要有时间就能够自由地选择如何解决。有时候，当请求特别针对某一个（或几个）人的工做时，咱们就直接ping相应的开发人员。

而后，收到ping消息的人就能够审查代码并发表评论。即便没有什么具体的事须要报告，咱们也会留言——代表代码能够合并了。

由于咱们可能会不考虑已有的评论，盲目合并一些pull request，因此就创建了严格的“回复或解决”制度。当收到反馈时，要么你把问题解决，要么在回复中解释为何不能解决。不管如何都不能留下悬而未决的评论，也固然不能将其与pull request合并。

总结

进行按期和高效的代码审查对于保持高质量的代码标准来讲必不可少，还有利于开发者之间的知识共享，以及团队的发展。

要求代码审查并不意味着能力弱，请求他人的帮助也并不值得尴尬，代码审查固然也没什么好羞愧的。另外一方面，接受你得到的反馈，并给提交pull request的人提供建设性的（理想状况下，积极的）的评论。

找到适合你的工做。审查代码应该在代码迁移过程当中占很大比重，因此你应该在团队中适时调整，以保证对每一个人都有益。

最后祝各位可以愉快地审查代码！

本文系 OneAPM 工程师整理呈现。OneAPM 能为您提供端到端的应用性能解决方案，咱们支持全部常见的框架及应用服务器，助您快速发现系统瓶颈，定位异常根本缘由。分钟级部署，即刻体验，性能监控历来没有如此简单。想阅读更多技术文章，请访问 OneAPM 官方技术博客。

本文转自 OneAPM 官方博客

原文连接：https://www.sitepoint.com/the-importance-of-code-reviews/