Code Review

过程：

Code Review协作过程：

a）先由代码的开发人员向检查人员进行大体的介绍，包括设计思想、数据结构、程序代码结构介绍等。

b）双方进行讨论、交流。

c）检查人员单独进一步进行Code Review，并记录Review结果和建议。

d）由检查人员和开发人员一起，检查人员反馈Code Review结果，并和开发人员一起讨论改进方法，重构。

e）最后把可重用的Code Review的经验总结编码规范，或者记录到“地雷区”中。便于整个团队复用经验。

 

 

代码评审的可操作性，首先需要评审团队具备经验丰富的系统架构师和精通业务的行业专家。其次团队需建立其开发规范或指南，在项目初期建立少量的Sample代码与checklist为评审提供依据。

 编码规范

 

目的：   

1 设计合理性

     1.1 实现方法

     1.2 数据结构

     1.3 设计模式

     1.4 扩展性考虑

     1.5 是否存在大量重复代码

     1.6 其他组件是否有重复的代码

     1.7 包结构设计是否合理 

 

 

 

 

 

 

2 互为Backup

     2.1 Code is Document，传递了技术，开发人员互为Backup，方便后期的维护，也减少了项目风险。

 

 

3 分享知识、设计、技术

   集中控制到个体发挥积极性，知识和好的经验，Code Review是一个学习和享受的过程，

   让好的知识、设计在团队中分享，实现整体团队的成长和整体的效益最大化。

 

4 代码可读性

  4.1 敏捷开发中强调高质量的代码胜过冗余的文档，Code is Document。

  4.2 代码的要求不止是能运行功能正确的代码，

  4.3 而是有了更高的要求，即Code for maintenance。

      可维护的代码，需要清晰，可读性强，

      a 这里可读性代码检查不是指代码格式（代码格式可以通过工具检查出），

      b 而是指代码语义。

      可读性及维护性影响也越大，又由于一些人可能限于水平，在编码过程当中引入了较低级且显而易见的错误，比如，资源没有释放，造成泄漏

 

 

5 业务逻辑

  5.1 满足业务需求； 

 

6 技术逻辑(实现逻辑)

      6.1 数据库打开忘记关闭

      6.2 异常处理

      6.3 内存释放

    7 性能问题 --> 10

    8 命名

    9 代码格式：过大的类、太长的方法和未使用的变量，重复的代码

   10 优化

 

Code Review任务、问题、建议

 

1：检查开发人员编码是否规范。     2：检查特定开发人员所做模块是否是否影响其他的模块。
3：特别是软件升级时，检查修改或添加的代码是否会影响其他部分。

 

 

雷区(注意事项):

    代码中的逻辑，除了业务逻辑，还应该包括技术逻辑。技术逻辑就是实现逻辑， 比如数据库连接打开是否忘记关闭，是否正确使用线程，Exception 处理，密码是否加密存储等。

我把这些最常出现错误的地方，而且是测试不容易发现的地方，称为Code中的“地雷区”。这些“地雷区”在Code Review 中是值得花费一些时间进行维护和检查的。

建议，在整个团队中维护并共享“地雷区”注意事项列表，以及统一的处理方式和机制。并在编码和Code Review过程中都按照团队的最佳实践进行。

 

 

 

发现代码中的业务逻辑错误

业务逻辑指的是代码开发的功能是否符合业务需求，如一个加法函数，检查其是否真的实现了加法的功能。

笔者了解的一些敏捷团队中，把发现代码的业务逻辑错误当做目标和内容，但往往效果都不是很好，基本都是从形式上泛泛检查一番。原因有两个：

1．业务逻辑的检查是从需求到代码的全方位检查，需要花费大量时间，投入产出比失衡。

2．业务逻辑的检查和业务需求紧密关联，已经超出了检查人员的能力范围（一般Code Review是开发人员，不是业务人员）。

笔者认为，发现逻辑错误，不应该是Code Review 的目的和内容。应该是Unit Test，功能测试，集成测试的目的。从投入产出比考虑，不应该花费太多时间在Code Review 阶段去进行逻辑错误检查。