敏捷开发之LinkedIn的高效代码评审技巧

阅读和代码评审是每一个工程师在平常工做中都要作的事情，然而一个标准的code review流程，实际上很难落地，它要求每次代码变动在部署到生产环境前，甚至是在提交合并前，都须要被另一个小组成员进行正式的评审。在LinkedIn公司，自从2011年起code review成为了开发流程中法定、强制的一部分，也意味着它成为代码质量保证和知识分享中必不可少的一部分，目标是让团队成员可以迅速提高本身的技能水平

实施公司级的code review最大的一个收益是提高了研发流程的标准化，在LinkedIn公司每一个团队使用相同的工具或者流程进行代码评审，意味着任何一我的对其余团队的项目能够提供评审帮助或者贡献代码，这消除了诸如“我能够修复代码中的错误，但如何构建代码并提交修复程序？”这样的问题，这反过来有助于增长工程组织中不一样团队之间的协做

咱们在将代码评审变成一项法定流程的过程当中，为公司创建了良好健康的反馈文化，工程师在他们领域中乐于提出或者接收反馈，而不仅是埋头苦干写代码。实际上，高质量的代码审查经验是在公司晋升参考中是举足轻重的，由于那是工程技能最直接的客观证据

经过过去很长一段时间实践，咱们总结出了在代码评审中的一些最佳实践和技巧，以下面所示，经过问题的形式呈现，尽可能让审查双方都能从中得到最大的价值

我真的明白代码变动的目的是什么吗？

为了加快高质量的code review流程和有效提升团队技能，每次变动提交的代码文件中应该包括变动概要，简要说明背后的需求或者动机是什么，而不是须要从代码更改自己反向推断。实际上，为提交代码写说明文档是从新梳理的过程，从中你可能会发现本身把需求实现搞复杂了，应该再简化下，因而就回头改代码，从而改善已有代码的设计，甚至培养出作事以前先进行推演等等好习惯

我提出的建议是积极反馈吗？

整洁的代码和高度测试覆盖率被视为理所固然的，然而有些code review过于关注代码问题，侧重点变成代码怎么修改才能变得更好，这很是很差，大部分人须要积极的反馈才能获得鼓舞和提升积极性，工程师也不例外，咱们不能忽视正面赞扬的价值。当审查员发现代码中好的设计时，应该提出来并给予确定，这种积极的反馈每每具备传染性，它能让整个团队变得更加有活力

个人代码评审评论表达清楚了吗？

和全部的代码提交同样，任何积极或者消极的反馈都不该该空谈，应该有针对性的解释，若是以为代码提交者收到反馈后可能一头雾水，能够进行过分解释而不是简洁，否则会产生更多的问题，并须要更多来回沟通。固然，注释也能够很是简洁，好比”消除了重复代码”、“增长了测试覆盖率”，这种类型的解释有助于让团队的价值观得以明确

我是否须要感谢提交者的努力？

某些代码质量不高，须要返工从新编写，在这种状况下，重要的是仍然认可他为之付出的努力，他以前可能只是对业务熟悉程度不够，最佳方式是提供高质量的code review反馈和正确的解释，好比提出“谢谢你，每次代码提交中始终有好的设计”之类的话语，而不是帮他写代码，从长远来看，这实际上是在必定程度上复制你的生产力

咱们能够从代码评审中获益吗？

这个问题可让咱们很是强有力而且粗暴地评估code review是否有必要。在下班前，工程师应该像对待一个有帮助性的开发工具同样正视代码评审结果，优先级应该比其余工做还要高，若是认为没有做用，就将其删除。没有意义的code review评论的典型示例是与代码格式相关的，那些应该由自动化工具而且是在编写过程当中验证，而不是最后由工程师来完成

“测试完成”部分是否足够完全？

code review中，不但要审查提交者的代码，还要关注作过的测试，除了一些单元测试，还有一些多是手动的测试。提交者最好列出全部测试过的案例，这样可让审查者作出更多的测试建议，从而提升质量

在review反馈中，我是否太迂腐了？

一些code review在重要的问题上提出了至关多的修复意见，而不是强有力的建议，也就是说过于关注细节，过于炫技，从而拖慢了整个进度，甚至会形成双方的隔陔。创建一个清晰的、有明确目标、积极的、有吸引力的code review流程是避免上述问题的好方法

总结一下，一个标准的code review流程可以提高代码质量、团队技能和知识互通。当团队中每一个工程师都意识到，其余人会阅读个人代码，同时我须要认真对待评审结果，下次代码编写要参考评论而后制做得更好，从而提升工做质量，这是增加和改善的关键

文章来源：www.liangsonghua.me
做者介绍：京东资深工程师-梁松华，在稳定性保障、敏捷开发、JAVA高级、微服务架构方面有深刻的理解