言之无物

我说的一切都是错的

LinkedIn工程实践——百万行代码评审

英文原文:https://thenewstack.io/linkedin-code-review/

《LinkedIn工程实践——百万行代码评审》
在LinkedIn,代码评审最近达成了100万行的里程碑。这家社交网络工具的领头羊,分享了一路走来获得的收获。

代码阅读和检视是工程师每天都要做的事。正式的代码评审流程,有一点点不同——每一次代码更新,在部署到正式环境之前,都需要经过其他团队成员正式的评审。自2011年以来,代码评审在LinkedIn已经变成了开发流程中必须的一部分。它的目标是尽可能平滑的衡量快速成长的工程队伍。

有意义的代码评审反馈,对提升整个工程组织的水平很有帮助。在LinkedIn,评审已经成了质量保证和知识分享中的核心部分。拥抱代码评审让整个工程文化在某些关键方面变得更好。

在公司层面实施代码评审,一个最大好处是提升了开发流程的标准。每个团队用的是同一套工具和流程,意味着每个人都能帮助别的项目团队评审或贡献代码。能消除诸如“我可以修复那段代码中的bug,但我怎么构建并提交修复呢?”之类的问题。 并且有助于增进组织中不同团队之间的协作。

把代码评审作为一个必需的流程,有助于促成健康的反馈文化:工程人员愿意提出或接收工作中各方面的反馈,不仅仅是代码,因为这已经变成了日常工作的一部分。

工程师并没有把代码评审看成是批评或负面的,而是把它作为一个提升专业的机会。事实是,高质量的代码评审是linkedIn晋升流程的一个重要部分,因为它提供了衡量工程技术的客观证据。

多年来,对于如何真正做好评审,我们打磨了一些最佳实践和技巧。下面给出一些指导方针,以问题的形式来展现。在代码评审中问一问自己,可以帮助双方获得最大的价值。

我理解“为什么要这么做”吗?

为了促进最大可能的评审,并帮助团队衡量,每次代码变更的提交都需要包含整体设计,用来简单解释变更背后的动机。如果需要从代码本身去推断实现原理,就很难做到高质量的代码评审。

在评审之前,期望提交人解释下代码变更的动机,这样的要求也是很合理的。同时也是鼓励提交者在提交时写好注释, 提高代码文档的质量。

我提供了积极的反馈吗?

在一个都是聪明人的组织里,干净的代码和整洁的测试覆盖率被认为是理所当然的。因此,代码评审仅会关注代码中的问题。

非常不幸的是,大部分人需要获取积极的反馈,才能让自己有参与感或者被激励——工程人员也不例外。
当评审者看到代码中好的方面时,应该说出来,给予积极的反馈。这有利于改善团队动力,经常性的正面反馈会有感染力。

正如代码评审的评语(后面会详细介绍)一样,任何积极的反馈内容需要非常明确,指出为什么那段代码写的特别好。

我的评审反馈解释清楚了吗?

无论反馈是积极的还是负面的,任何评语应该是自解释的。不怎么完善的评语评审者自己能看懂,但对于代码提交者来说,却不会那么清楚。当有疑问时,解释充分点会比较好,太简洁反而会掩盖更多问题,并需要来回多次的沟通。

当然,解释也可以很简单,比如使用“减少重复”,“完善覆盖率”,或者“让代码更容易测试”这样的重构术语。不但让评论更清晰,也会帮助团队进一步巩固设计原则,

我感激提交者的努力吗?

无论结果怎样,努力工作总是值得赞赏——这会增强团队的积极性。有些代码变更的质量不是很高,需要返工。即使这样,仍然要承认提交者的努力,这点很重要。

展示感激的最好办法是在代码评审中给出高质量的反馈,得体的解释,承认做的好的部分(任何提交的代码中总有好的一面),以及说声“谢谢你”。

代码评审的评语对我有用吗?

在验证评审评语是否必要时,这样问自己一下,简单又有效。

最终,工程师会把代码评审看成利于开发的工具,而不是无关紧要的额外工作。如果你认为某条评语没用,就删掉。无用评语很典型的例子就是关于代码格式的。代码风格和格式应该由自动化工具来验证,不是工程人员。

“测试完成” 区足够充分吗?

在LinkedIn,每次代码变更提交都必须填写“测试完成”区。在开源领域,比如GitHub,工程师能够在拉取请求(pull request)的描述中填写“测试完成”信息。

测试完成区里填写的信息取决于变更的比重以及当前的测试覆盖水平。假如变更包含新的或者更改的条件复杂度,应当有相对应的单元测试。如果集成测试覆盖率并不充分,则需要运行手工测试。

以上的情况下,”测试完成”区应该包括测试场景以及输出结果。当变更改变了程序的输出时,把新的输出结果放在“测试完成”区是非常有用的。

在评审中我是否太学究派了?

有些代码评审评语太多,使得真正重要的问题(确实需要解决的)被淹没在不重要的建议中。评审太关注于细节,会拖慢团队的评审循环,让评审双方人员产生摩擦。为避免冗长,令人疲惫的评审循环,需要有清晰的评审期望,评审案例,以及积极的,吸引人的评审文化。

总之,正式的代码评审流程帮助团队改善代码质量,团队学习和知识分享。当团队的每个成员意识到以下2个要点时,工作质量将得到提升:

别人会读我的代码,因此最好写的好点。还有,我需要处理收到的评审反馈,为节省以后修改的时间,我应该第一时间就把代码写好。

当代码评审变成了每个人的习惯, 团队每天都在实践反馈的输出输入。这是成长和改善的关键。

在LinkedIn,我们从过去100万行的代码评审中学到了很多,我们也期待从下一个100万中学到更多。

代码评审中投入的精力越多,团队在评审中就会给出更好的反馈,提交的代码质量也更高,从而构建的产品质量也更好。高质量的代码评审具有传染性。

The author thanks James Miller, Oscar Bonilla, Joshua Olson, Andrew Macleod, Scott Meyer, and Deep Majumder for insightful feedback on this article.

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注