做过代码 Review 吗？

ost 在会议过程中负责组织大家发言和维护秩序，让代码 Review 更高效;Recorder 则负责将整个 Review 过程中提到的需要优化和改进的点进行文档形式的记录，记录的信息需要言简意赅，将哪个文件哪一行代码，问题是什么，建议怎么优化都需要记下来，并且在会议结束过后以邮件的形式发送给 Author 和抄送大家。

Review

在进行代码 Review 的时候 Author 需要从文件的第一行开始进行一行行的代码走读，对每一行的代码进行描述，这里需要注意的是不要认为某个功能很简单，就可以一句带过，往往很多线上 Bug 都是因为这种忽略导致的。走读代码的时候 Author 需要解释清楚每一行代码的含义，说明这行代码是干嘛的，为什么要这样写。Reviewer 则需要根据 Author 的描述再结合自己之前阅读代码的理解进行提问或者改进方案。

代码走读的过程持续进行的同时 Recorder 需要及时记录需要改进的内容，并把提出的优化方案记录下来。代码走读的过程是整个 Review 的核心，在这个环节中我们需要注意很多东西。知乎上面有个提问大家的公司的 Code Review 都是怎么做的?遇到过哪些问题?，上面有个回答提出的几个点很不错，我觉得有必要分享给大家，对我们的整个 Review 会很有帮助，特别是当自己是 Reviewer 的时候，需要格外注意。

• 对事不对人。要记住大家都是同事，今天自己是 Reviewer 来对别人的代码进行 Review，哪天别人就会对自己的代码进行 Review，所以在整个代码 Review 的环节中，我们可以提出自己的建议，但是需要注意自己的用词和语气，虽然程序员有鄙视链，并且都认为别人的代码垃圾，但是这种时候不能瞎说，容易打架的，还是要谦虚点。
• 用正面的词汇进行评价。跟上面说的一样，我们需要用正面的词汇进行评价代码，考虑 Author 的情绪，即使代码写的不好。这个很好理解，毕竟代码 Review 是在很多人面前的，对 Author 来说，让别人看自己写的代码就像在别人面前裸奔一样，所以我们不仅要提出意见在好的地方我们也要进行正向的表扬。
• 如果有更好的方案一定要提出来。代码 Review 的目的就是优化代码，找出代码中的隐藏 BUG 以及逻辑问题。所以如果发现了代码有任何不优雅的地方或者会出现问题的地方一定要及时的提出来，不要担心自己说的不对，或者考虑 Author 的面子问题，不指出来，提供更好的解决方案，让大家一起进步。
• Review 会议是 Review 代码，而不是讨论需求。这一点也是很容易被带偏的一个点，经常我们会发现在 Review 的过程中，慢慢的就变成了讨论需求了，这种情况一定要避免发生，不然整个代码 Review 环节就是失败的，无法进行下去了。所以 Author 在发起代码 Review 邀请时一定要确保自己理解的需求是正确的，避免浪费大家的时间。
• 高效的进行。进行代码 Review 的时候我们需要注意一定要高效，如何做到高效就需要每个人都做好相应的准备，Author 需要对自己的代码进行熟练的讲解，Reviewer 需要在参加会议之前将需要 Review 的代码看一下，提前找到可能隐藏的 Bug，对于不懂地方需要做好记录，方便开会的时候及时指出。
• 避免形式主义。这一点也是被很多小伙伴忽略的一点，随着代码 Review 的次数越来越多，很多小伙伴可能就把这个当成一个任务，慢慢的就变成了形式主义，而不是注重实际，每次代码 Review 的时候就很随意，长期这样下去对公司，团队以及自己都不好，而且还浪费时间。

总结阿粉今天给大家介绍了一个如何做一个合格的代码 Review，当然这只是阿粉自己的一些见解，大家有任何意见可以在评论区给我们留言，大家一起交流学习。

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!