谷歌都在用的 code review 技巧

最新推荐文章于 2024-10-21 17:38:42 发布

帅德布耀德

最新推荐文章于 2024-10-21 17:38:42 发布

阅读量108

点赞数

文章标签：代码复审

本文链接：https://blog.csdn.net/lyd0813/article/details/132479356

版权

最近读了几篇code review 的文章：

读了之后，感触很深，发现我所任职的公司对于 code review 的重视程度还远远不够，很多时候都把它视为一件麻烦事。

任何软件都是协同开发的，所以 code review 非常重要，它可以帮助你减少代码质量问题，提高开发效率，提升稳定性，同时还能保证软件架构的稳定性，防止代码结构被恶意破坏导致难以维护。

首先 code review 是一个活动，从最简单一个人读小伙伴的代码开始，到团队在办公室内一起读，一起剖析代码，这都是可以叫做‘code review’

从上图我们可以看到一共有两种角色：

好的 code review 会检查代码的正确性、测试覆盖率、功能变化、是否遵循代码规范与最佳实践、可以指出一些较为明显的改进点，比如难以阅读的写法、未使用到变量、一些边界问题、commit 数量过大需要拆分等等。
良好的 code review 会检查引入代码的必要性，与已有系统是否适配，是否具有可维护性，从抽象角度思考代码是否与已有系统逻辑能够自洽。

好的 code review 会轻易通过那些开放式 PR，至少在其被得到充分讨论前，但每个 Review 者对自己关注的部分完成 Review 后需要进行反馈，无论是 “看起来不错” 或者用缩写单词 “LGTM”，之后需要有明确的跟进，比如通过协作软件通知作者进行进一步反馈。
良好的 code review 实际执行中会更加灵活一些，对于一些比较紧急的改动会留下改进建议，但快速通过，让写代码的 author 通过后续代码提交解决遗留的问题。

关于代码风格的争吵在 code review 中是非常浪费时间的。一致的代码风格当然是非常重要的，但 code review 的时间并不该浪费在讨论圆括号该放在哪里。最好的做法是通过维护一份代码风格规范来避免这里的争吵。

总的来说 code review 的过程中，双方都应该保持谦逊学习的态度，在 review 过程中，尽量避免僵持和冲突，一旦发生冲突时，leader 一定要快速找到平衡点，如果持续时间长，就会影响彼此的合作关系，代码问题可以慢慢去解决，和谐互助友好的团队关系才是更重要的。

结合前面有以下总结：

注意上面的 5，因为想要把代码从 F 提升到 A，理论上是可行，当时会耗费作者和 reviewer 太多的精力和时间，可能还会在一来一回中造成不愉快。方法是，先从 F 提升到 C，下次他就会从 C 到 B 甚至是 A
相同的问题，注明个 2-3 次即可，剩下的告诉作者修复其他类似问题
不在变更范围的代码，有问题也不应该放在这次 review 里。如果是顺手可改的命名问题或极其容易修复的问题，可以作为 optional 提出来
Review 多个 300 行的变更体验好过 review 单个 600 行的变更
看到代码里好的地方，让自己受益，可以适当表扬
如果剩下的都是变量命名和拼写错误，以及 optional 的修改点，也可以直接 approve，无需过于纠结。不拖延是要点；
author 和 reviewer 之间出现僵局怎么办？尽快的让步，或找管理者寻求帮助。僵持的时间越长，对合作关系的破坏越强，而这个关系远重要于代码质量不要试图一次解决所有问题。

作者：Rick_Lee
链接：https://juejin.cn/post/6844904103802306568