做了一百万次代码评审后，学会了这些经验
极客时间编辑部
讲述：初明明大小：3.82M时长：04:10
LinkedIn 的每个团队都使用同样的代码评审工具和流程，任何一个工程师都可以评审别人的代码，甚至可以为其他团队贡献代码。
2 年前，LinkedIn 的代码评审总量达到了里程碑式的一百万次。为此，LinkedIn 社交网络服务工具部门负责人什切潘·法伯（Szczepan Faber）总结了代码评审的经验和教训，以下为重点内容。
1. 我真的了解“为什么”代码要这么写吗？
为了促成最好的代码评审，每一个代码提交都应该包含设计概要，大致解释做出代码变更的动机是什么。如果只能从代码中推敲出代码变更背后的缘由，是很难实现高质量的代码评审的。代码提交者应该主动提供变更说明，把它们包含在提交日志里，这样也有助于提高代码文档的质量。
2. 我提供正向反馈了吗？
在一个到处都是聪明人的公司，获得干净的代码和整洁的测试覆盖率是理所应当的。正因为如此，代码评审一般都只关注代码中出现的问题。但问题是，大部分人需要从正向反馈中获得鼓舞和参与感，工程师也不例外。如果评审人员发现代码中有值得称道的地方，就要把它们指出来，并给出正向反馈，这样有助于提升团队士气。对于代码评审注释，任何正向反馈都应该是明确的，如果认为代码写得好，就要说清楚好在哪里。
3. 我的代码评审注释够清楚吗？
不管是正面的还是负面的反馈，每一个注释都应该清楚地表达评审人员的想法。面对太过简陋的评审注释，代码提交者根本无法领会评审人员的意图，尽管这些东西对于评审人员来说是显而易见的。如果有疑问，过度解释总比简单的反馈要好得多，因为简单的反馈会导致更多问题，需要来回沟通，浪费时间。评审人员可以在注释里写上“减少重复”、“提升覆盖率”或者“让代码更容易测试”，等等。这样做除了可以让评审人员的注释更清晰明了，也有助于让团队达到更高的设计水准。
4. 我是否认可代码提交者所付出的努力？
我们应该认可努力工作的人，不管其产出的成果是什么，这样有助于培养高士气的团队。有些代码质量不高，需要反复修改，对于这类情况，我们应该对代码提交者的努力给予肯定，对他们表现好的方面表示认可，并使用礼貌用语，比如“谢谢”，再解释需要返工的原因。
5. 这是个有用的评审注释吗？
通过问自己这个问题，可以想清楚一个评审注释是否必要。对于工程师来说，代码评审应该是有用的开发工具，而不是无用的负担。如果你觉得某个评审注释不是必需的，就把它删掉。
6. “测试完毕”里的内容够详尽吗？
在 LinkedIn，提交的每一个代码变更都必须包含“测试完毕”部分。以 GitHub 为例，开发者在提交代码时会把“测试完毕”的内容放在 PR 描述里。“测试完毕”应该包含哪些信息呢？这取决于代码变更的重要程度和测试覆盖率。如果变更引入新的或者修改过的条件性复杂度，就有必要进行单元测试。在集成测试覆盖率不高的情况下，有些变更需要进行手动测试。对于这类情况，“测试完毕”部分应该包含测试场景描述和测试结果。如果代码变更会导致程序的输出发生变化，“测试完毕”部分需要包含新的测试结果。
7. 我是不是太“学究”了？
有些代码评审注释里包含了太多信息，以至于一些不是很重要的建议把真正重要的问题给“埋没”掉了。太痴迷于抠细节容易拖慢评审速度，还会挑起评审人员和代码提交者之间的矛盾。清晰的评审期望和积极正向的代码评审文化有助于避免出现拖沓冗长的评审。
以上就是 LinkedIn 从过去的一百万次代码评审中得出的经验，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论