如何review开发人员的代码
前置的一些概念
review级别：（参与人身份和方式不同划分）
● 相关开发自己看代码（非正式会议）
● 开发人员组内
● 相关开发+直接上级
● 相关开发+直接上级+总监
1.团队review制度
团队内根据实际情况规定流程
在我们团队内要求：
正式需求上线前要经过：组内，直接上级参加的，技术总监参加的review
小需求紧急问题视情况简化
2.review会议组织
相关开发人员自己review
找个时间找个会议室就可以了
有上级或非相关开发参加的
确定会议主持人（一般是被review的人）
主持人要做以下事情：
确定谁来参与，约会议日程
提前把要看的代码，相关需求发出去给参加的人
3如何开会议？
时间控制在一个小时内（太长了效果就差了）
做好会议记录
● 基本信息：时间、地点、参与人
● 记录问题：本次review发现了哪些问题，谁的问题，推荐怎么改【后续要跟进】
● 记录共性问题或好的写法，定期在周会上同步整个团队内，制定相应的规范
按照功能点看相关的代码，在看代码前先简单介绍一下代码实现了一个什么需求做了什么事情 让参与的人有认知
4. Review的时候怎么看别人的代码？
● 是否符合团队内规范
● 凭经验看哪里写的有坑
dto类不能有默认值，属性必须是包装类型
数据一致性考虑，执行失败是否有异常处理（日志、补偿）等等…
● 考虑这段代码自己写是否有更好的写法（优雅可读性好）
如果这个项目用了领域驱动设计，还要看
● 代码和设计是否一致
● 聚合、实体、值对象设计是否合理
● 代码的层级调用关系是否合理
● 各个层是否只承担了自己的职责（应用层编排领域服务 ，业务逻辑都在领域层，基础设施层只干技术的事情，只持久化实体 不包含业务逻辑）
不一定要代码彻底写完才进行review，先期可以把主体结构写好，细节写好 todo 如果review时有大的结构变动会很方便调整【要知道写完代码，都测试的没问题，还要大改，重新测试是很痛苦的】
