【编者按】本文作者为 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/
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
