1.前置的一些概念

1.1 代码审查的目的

代码评审最大的问题就是很容易形式化
就是老猴子这么干的，新猴子也这么干，然后就是每天定点大家一起看上去形式上过一遍代码，没有产生社交活动

代码评审是拉水平的一个手段，一定要不厌其烦
从大家有差异的认知，到形成一定共识的过程就是指的团队共识

团队内根据实际情况规定流程
在我们团队内要求：
正式需求上线前要经过：组内，直接上级参加的，技术总监参加的review
小需求紧急问题视情况简化

相关开发人员自己review
找个时间找个会议室就可以了
有上级或非相关开发参加的
确定会议主持人（一般是被review的人）
主持人要做以下事情：
确定谁来参与，约会议日程
提前把要看的代码，相关需求发出去给参加的人

时间控制在一个小时内（太长了效果就差了）
做好会议记录

按照功能点看相关的代码，在看代码前先简单介绍一下代码实现了一个什么需求做了什么事情让参与的人有认知

dto类不能有默认值，属性必须是包装类型
数据一致性考虑，执行失败是否有异常处理（日志、补偿）等等…

如果这个项目用了领域驱动设计，还要看

不一定要代码彻底写完才进行review，先期可以把主体结构写好，细节写好 todo 如果review时有大的结构变动会很方便调整【要知道写完代码，都测试的没问题，还要大改，重新测试是很痛苦的】