java 代码走查_代码走查如何保证软件质量

目的

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

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

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

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

如何进行代码走查

代码走查的角色

主持人：负责主持整个走查活动，包括会议邀约和控制时间(一般一小时左右)进度。为了让代码走查高效，需要及时阻止不必要的讨论，比如讲解人讲的太发散、或者大家针对一个点讨论时间过长。

讲解人：负责对代码进行讲解并跟进修改计划，一般是系统Owner或代码编写者。

记录人：记录代码走查记录，记录中包括代码走查中发现的问题点、修复方法和最佳实践，问题需要指定到对应的人。

评审人：对代码进行评审发现问题并找出最佳实践，一般是资深开发和测试同学。

参与人：参加代码走查，主要以学习为主。

走查前做好充分准备

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

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

走查中控制节奏

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

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

编码规范： 可以使用IDEA的插件自动扫描有没有编码问题。

设计规范

幂等性

逻辑问题：是否满足需求。

一致性问题

并发和锁：在并发情况下，代码执行结果是否有问题。

性能问题：代码是否存在性能问题，预计峰值流量能到多少。

分支覆盖率：是否有分支没有覆盖

走查后总结

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

参加代码走查有什么收获？

对代码走查有什么建议？

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

时间把控：第一次代码走查主持人和讲解人时间没控制好，走查了三个多小时，后续主讲人讲重点，主持人随时控场，讨论超过几分钟的就记录下面，线下讨论。

重点优先：大家前面精力比较好后面就分神了，后续主讲人优先走查重点代码。