目的

代码走查的好处非常多，第一个是让新同学快速熟悉代码并了解系统。第二个是做资损防控的事前检查，在事前规避引发线上故障。第三个是通过一起讨论和审查，加强团队代码阅读和编写能力，让大家编写出优秀的代码。代码走查的优点非常多，但是最核心的还是希望通过代码走查提前发现问题并解决问题。

所以基于以上目的，代码走查不是为了找到代码写的差的程序员加以批评，不是为了找到差的代码，而是一起发现问题共同成长，所以对于写代码的同学不需要过于紧张，但是在代码走查前自己可以先看一次优化一遍，不过所有的变更必须有单元测试覆盖，否则为了优化代码又会引发新的问题。

什么场景应该做代码走查？

我认为有几个时机点是需要做代码走查的，第一个是定期，每几个月定期做一次代码走查。第二个是有重大变更时做代码走查，如代码第一次上线或增加了比较多的代码。

如何进行代码走查

代码走查的角色

• 主持人：负责主持整个走查活动，包括会议邀约和控制时间（一般一小时左右）进度。为了让代码走查高效，需要及时阻止不必要的讨论，比如讲解人讲的太发散、或者大家针对一个点讨论时间过长。
• 讲解人：负责对代码进行讲解并跟进修改计划，一般是系统Owner或代码编写者。
• 记录人：记录代码走查记录，记录中包括代码走查中发现的问题点、修复方法和最佳实践，问题需要指定到对应的人。
• 评审人：对代码进行评审发现问题并找出最佳实践，一般是资深开发和测试同学。
• 参与人：参加代码走查，主要以学习为主。

走查前做好充分准备

讲解人整理本次要走读的代码分支、系分设计和代码入口，然后发邮件通知大家，参加代码走查的人提前阅读系分和代码，针对看不懂的代码、有问题的代码和设计复杂的代码全部提交Review记录。

讲解人必须想好走查哪些代码，一般是主流程或有问题的点，控制整个代码走查的时间，我们第一次代码走查花了三个多小时，由于时间太长，走查的过程中开发都走了几个。

走查中控制节奏

直接讲代码很多没参与的同学会很晕，所以先大致讲下系分设计，不需要全部讲完设计再讲代码，而是讲一部分设计，再讲一部分代码。讲解人带着大家一行一行读代码，讲解代码的含义和思考，记录人负责记录Review出的问题和最佳实践。

代码走查的评判标准，主要关注几个点

• 编码规范： 可以使用IDEA的插件自动扫描有没有编码问题。
• 设计规范
• 幂等性
• 逻辑问题：是否满足需求。
• 一致性问题
• 并发和锁：在并发情况下，代码执行结果是否有问题。
• 性能问题：代码是否存在性能问题，预计峰值流量能到多少。
• 分支覆盖率：是否有分支没有覆盖

走查后总结

在代码走查之后，要优化代码走查，所以会发一个调查问卷给大家

1. 参加代码走查有什么收获？
2. 对代码走查有什么建议？

我们走查完之后有几个改进点

1. 时间把控：第一次代码走查主持人和讲解人时间没控制好，走查了三个多小时，后续主讲人讲重点，主持人随时控场，讨论超过几分钟的就记录下面，线下讨论。
2. 重点优先：大家前面精力比较好后面就分神了，后续主讲人优先走查重点代码。