iWeb 学院

代码审查的重要性

我最近在Twitter上看到:

很遗憾,好像代码审查对于很多学生,自由职业者以及机构来说是一种很陌生的实践。

显然,代码审查对每个人来说的有用性并不是特别明显。也许是我太天真,但是我真的认为这是在所有IT公司都应该有的流程。显然我错了,这让我害怕。 在这篇文章中,我将谈谈我对于代码审查的看法,为什么我相信在代码交接(code shippng)的过程中,代码审查很重要,我们应该怎样开始使用它。如果你没有代码审查,或者你想要做的更好,我希望这篇文章能够帮助到你!

什么是代码审查?

我们生活在维基百科的时代,所以请允许我从给出代码审查Code review的定义开始:

代码审查是对计算机源代码的一种系统性检查(有时也称为同行检查)。它的目的是找到在最初的开发阶段被忽视的错误,改善软件的质量。审查有很多种形式,比如结对编程,非正式和正式的检查。

代码审查,正如它的名字所展示的,是一项通过审查代码以确保代码能够正常运行以及尽可能的改善它的流程。

代码审查的方法

作者的更多内容

Inline CSS in Jekyll A Tale of CSS and Sass Precision 正如维基百科所定义的,有很多实现代码审查的方法。然而,在一个很多代码都放在GitHub的世界中,代码审查通常通过我们称作“pull request”的方法进行。 pull request 是使用分布式版本控制系统(Git,SVN,Mercurial等)向代码库提交更改的一种请求。它通过“pulling”原始代码进行修改,随后通过一个请求将更改合并的方式工作。 Github通过友好的用户界面和掌握一定的Git知识来让这项进程变得简单和高效。 3

为什么审查代码值得注意

所以,为什么代码审查值得引起我们的重视呢?毕竟我们都是有能力的人。当然我们可以在交接代码时,不用好像有人在我们的身后看着我们做所有事情一样。 理论上来说是这样。但是在现实中,有许多原因告诉我们有一个既定的代码审查过程是很有帮助的。让我们来看一些。

它限制了风险

这可能是所有原因中最重要的一点。让某人双重检查我们的工作不会让我们受伤害,并且显示了没有注意到的错误。即使是好的开发人员有时也会在某一方面思考的不够完善。 确认没有遗忘任何事情通常很棒。比如,适当的键盘导航,屏幕阅读器可访问性、国际化的灵活性和友好性、非JavaScript的行为等往往在前端的世界被遗忘。

它极大地提高了代码质量

让我们把事情说的更清楚一些:这不是关于标准和代码静态分析(至少不完全是)。它是关于使代码更有效。 在一个每个人都有自己的背景和习惯的团队中,要求改进(因为这就是代码审查相关的)总是一个很好的想法。有人可以提供一个更聪明的解答方案,更合适的设计模式,更好的方法来减少复杂度,或者提升性能。

它让所有人更好

通过强行制定,每个人都能学习并且变得更好。代码提交者能够在他们的工作中收到反馈,让他们更注意到可能的问题和能够改善的区域。代码审查者能够通过阅读代码学习到新的东西并且将合适的方法应用到他们的工作中。

它帮助人们更熟悉项目

当一个团队实施一个项目时,不可能每位开发者都工作于该应用的每一个方面。有时一名开发者可能在一段时间内工作于一个大的方面,此时另一名正工作于其他方面。 代码审查帮助人们熟悉他们没有编写但将来可能会被分配去维护的代码。它促进了整个团队的代码库的知识,并有可能加快未来的开发。

怎样合适的使用它

再次强调,有一个既定的代码审查过程是非常有用的和重要的。每一个编写代码的团队都应该有代码审查的一种或其他方式。 这是说,做有意义的和有用的代码审查并不总是所想象的那么简单。不用担心,如果它做得很差它不会咬你。它可能没有那么有用,可能是浪费时间。 最近在我工作的地方,我们对我们的代码审查流程进行了一个回顾。当我们发现我们的12名开发者中只有3名人员参与到代码审查中时,我们意识到可能有些事我们做的不对。 为了帮助我们改变这种情况,我们的一位Scrum大师组织了一场回顾会来决定哪里还有改善的空间,以及怎样执行它。

提前规划

最常出现的争论,人们没有参与到代码审查的理由是它需要时间——人们不愿意或者不想花费时间。 我必须说我自己真的很不能理解这个理由,因为我这样认为它:如果一个同事直接来我,并要求我帮助他们,我不会说——“没有时间,不感兴趣”。我会找出时间去帮助他们。可能不是现在,可能一小时以后——但是我会为他们腾出时间。为什么呢?因为

  • 这是团队的意义的一部分
  • 如果他们需要我的意见,这是因为他们认为这是一种或另一种方式,因此,帮助他们很有意义。

“你不参加代码审查?” “我没有时间”

对于我来说,一个pull request与同事需求帮助没有任何差别。有时说你没有时间的确是一个很好的借口,但通过系统地拒绝帮助,你正在积极的把自己推出团队之外。这种行为既不友好又不积极。找到时间去帮助。 为了让开发者找到时间,我们开始考虑让每位开发者每天花费一点时间(大概30分钟)来进行代码审查。当我们结束一天半小时的代码审查时没有更多的惊喜:这是一天的一部分。 我们还试图显著减少构成代码量的pull request。我们过去有特别多的pull requests - 几十个文件中的数千个变化。 我们试图不再那样做。通过少量的pull requests,我们让审查更简单,反馈更相关,开发者更愿意参与到这个过程中来。“交接小而经常交接。”

提供上下文

我们发现的第二大问题就是我们通常缺乏对代码上下文的理解,当你在提供帮助性的反馈时尤其需要。在缺少上下文时,我们做的通常就是一个语法审查——有时很有用,但并不够。你可能仅仅成为了一名“人工检查器”。 幸运的是,这个问题的解决方案相对简单:给pull request增加描述来解释主题是什么,以及如何到这里。它不需要很多文字;短短几行通常就足够了。给issue添加一个链接或者故事也很有帮助。Liv Madsen,我们的一位开发者,甚至添加了截图——或者相关的视频——来说明她做了什么,这很令人惊喜。

询问

我们提出的第三个问题是有时我们并不知道有代码需要我们去审查。让我们面对它,我们每天被淹没在大量的邮件和提醒中——我们很难跟踪记录他们。毕竟我们只是人。 解决方案很简单:请求别人进行代码审查。有很多方法可以做到,比如在办公室里鸣喇叭或者在Slack上ping某人给自己团队的人。 我们根据自己的活动在Github上建立团队,随后提交pull request,我们通常在唤起某个团队。成员将收到提示并且当他们有时间时就能处理它。有时,当这个工作很明确属于某人时,我们直接告诉一名或者多名开发者。这也很有用。 在这里,告诉人们可以审查代码并且留下注释。有时没有明确的需要报告的——比如只是提醒这个代码可以被整合,我们也会留下注释。 由于有时我们盲目的整合代码而不管留下的评论,我们提出了一项严格的“回复或者修复”的政策。当收到反馈时,你需要修复代码或者回复你不整合的原因。任何情况下,你从不留下一个悬而未决的评论,也从不整合一个没有处理的评论的pull request.

总结

有一个经常有效的代码审查流程是保持高质量高标准代码的本质,同时也能帮助团队成长和在开发人员中互相分享学习。 寻求代码审查并不是虚弱的表现。寻求帮助没什么好尴尬的,代码审查也如此。接受别人给你的反馈,并且给提交pull request的人们建设性的评论。 找到适合你的方法。审查代码应该是代码移交流程很大的一部分,所以你应该在你的团队中用上它。让它按着你想的做以致能帮助所有人。 Happy reviewing!

400-710-1024
北京市昌平区禧乐汇商城5层(iWeb学院)