目的
查代码的好处很多，第一，让新同学快速熟悉代码，了解系统。 二是做好资金损失防控预检查，提前避免造成网络故障。 第三，通过一起讨论和审阅，增强团队代码的读取和编写能力，使其能够编写优秀的代码。 代码进度调查的优点很多，但最核心的是希望通过代码进度调查尽早发现问题，解决问题。
因此，基于以上目的，写代码的同学不需要太神经质，因为代码进度调查不是为了找到代码写得不好的程序员而批判，而是为了找到不好的代码而一起发现问题并共同成长。 但是，您可以在代码进度调查之前自己查看一次优化，但所有更改都需要通过单元测试进行涵盖。 否则，为了优化代码又会出现新的问题。
应该在什么场景下查代码？
我觉得有几个时间点需要做代码来查，第一个是定期，每几个月定期做代码来查。 第二，在发生重大更改时检查代码，例如第一次联机代码或添加了相对多的代码时。
如何查代码
代码检查的作用
主持人：负责主持整个调查活动，包括会议邀请和时间(通常1小时左右)进度的控制。 为了有效地检查代码，必须及时阻止不必要的讨论，例如讲解者的话过于发散，或者大家讨论一个点的时间过长。
说明者：负责解释代码，跟进修改计划。 一般来说，是系统Owner或代码作者。
记者：记录代码进度记录。 记录包括在代码进度记录中发现的问题、修复方法和最佳做法，问题需要指定给对应的人。
审阅者：审阅代码以发现问题和找到最佳实践的一般是资深的开发和测试同学。
参与者：参与代码检查，主要以学习为主。
在调查之前做好充分的准备
讲解者整理好这次跳过的代码分支、从属设计和代码入口，通过邮件通知大家。 参与查码行走的人员应提前阅读从属关系和代码，对无法读取的代码、有问题的代码和设计复杂的代码均提交Review记录。
人必须考虑查哪个代码。 一般来说，考虑到主流程和问题点，必须控制调查整个代码的时间。 我们花了三个多小时查第一次的代码。 因为太花时间了，在调查的过程中进行了一些开发。
调查并控制节奏
因为没有参加的同学会大多直接说代码，所以先大致说一下不同系的设计。 不是把设计全部说出来再说代码，而是先说一部分设计，然后再说一部分代码。 讲解员负责带大家逐行阅读代码，讲解代码的含义和思路，记录人员负责记录Review提出的问题和最佳实践。
代码检查的评价标准主要关注几个方面
编码规范：可以使用IDEA插件自动扫描是否存在编码问题。
设计规范
幂等性
逻辑问题：是否满足需求。
一致性问题
并发锁：并发时，代码的执行结果有问题吗？
性能问题：代码是否存在性能问题，预计高峰流量是多少？
分支覆盖率：未覆盖是否存在分支
我会调查总结的
代码进度调查后，为了优化代码进度调查，我们会发送调查问卷
参加代码检查能得到什么？
你对代码检查有什么建议吗？
我们查完之后有几个改进的地方
时间管理：第一段代码中查询主持人和讲解人的时间没有得到很好的管理。 我走了三个多小时调查了。 后续主讲人将讲述重点，主持人随时管理会场。 讨论超过几分钟的将记录以下内容并在线讨论。
重点优先：大家前面好后面分心，后续主讲人优先查重点码。