代码评审

代码评审，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动（也有工具支持自动检查）。 

评审内容：

1. 编码规范（包括注释规范、变量命名规范、System.out<日志使用>、代码可读性），

2. 代码结构（重复代码、大方法、耦合性等需要合理重构的点），

3. 复杂业务逻辑的实现代码（这是个问题，业务逻辑实现是否需要评审呢？）

    复杂业务逻辑的评审应该以代码作者讲述流程为主，大家梳理流程的同时评审代码质量，可以顺带让大家在共同梳理这个负杂逻辑的过程中发现逻辑的合理性。

4. 系统基础资源的使用是否合理等

 

评审方式：

交叉评审：团队成员互相检查代码。

会议集中评审：项目组成员共同评审，由负责人主导，应该选择关键、逻辑复杂或者容易出问题的模块进行重点评审。

 

评审时机：可以考虑在每个短周期期迭代的代码实现完成时？还是...？

 

评审准备：评审提纲、评审模块、参与者预先浏览相关代码，可以先通过邮件评审方式，提出各自意见，包括优质代码和劣质代码，以便在真正评审会议时有重点针对性，减少逐行读代码的时间。

 

评审案例：用评审前的代码与评审后优化的代码做对比 ，触发参与者对代码评审的积极性
问题跟踪：对评审中发现的问题代码应加以跟踪，确保问题得以解决，防止复发 

 

评审的意义：提高代码质量，大家共同梳理复杂问题的过程，统一大家对公共、复杂逻辑的理解一致性等，加深对系统的理解。

 

参与人员：代码评审很容易流于形式，尤其在外围不了解逻辑，不了解系统架构及具体实现技术的人员参与时，个人认为，很难取得好的效果。应该以项目组内成员参与为主，同时引入外围 技术 大拿可以从一些宏观层面、公共技术层面给出意见，并对不确认问题给出结论，防止各持己见、争论不休，当然，有争论问题需要记录并在会后达成一致性意见作为规范。

 

很多东西不写下来，仅仅是脑袋里模糊不清的意识，零散的东西无法起到具体作用。以后得强迫自己多写，不管当时想法有多少，尽量写下来，慢慢丰富，集中整理应该会有好的效果。