代码审查思考

1. 描述

代码审查的目的不是指出某个功能性问题，也不是针对谁的代码写的不好，而是要用第三者的目光去审视这份代码(可能哪里不好，或者很难阅读，或者会出现潜在的问题)，从而加强代码质量(顺便提高开发人员开发水平)，提高项目的可维护性、扩展性

备注:如果是那种临时性功能或者临时性页面，一锤子的东西，可以不必特别关注，但是如果是那种重点项目，生命周期很长的项目，代码审查，优化重构，则必须当做工作重要的一个环节加以重视之。

2. 思考

2.1. 几处问题

基于这几次hox-fix修复过频，这几天阅读了部分源码，和借用alibaba-java-coding-guidelines工具扫描我们的代码，发现了很多问题:

1.大家的代码编写(接口定义，命名，注释)比较随意，缺乏重构的理念，比如魔法数字顺手拈来；

2.缺乏类的设计，一个类的做的事情非常多，甚至出现了很多几千行代码的类；

3.缺乏防卫意识，把很多参数校验逻辑校验 压给前端，如果前端不校验，数据一旦落到数据库，对后续可能会引起问题缺乏正确认识；

4.迭代开发(超过3天的工作量)，没有设计文档，想写就写，想改就改，想删就删；

5.业务需求涉及到第三方接口时，没有意识到接口就是约定，就是法旨，私下对接沟通，定义的接口谁便乱改；

6.缺乏敬畏代码、敬畏设计的思想，感觉看着不爽，就有想删乱改的冲动，完全不顾修改删除代码或者字段会有什么问题(比如设计的时候属性A必须在A表，因为开发方便结果放到B表里)，最终原设计文档与开发实现差之千里；

......

2.2. 问题根源

这些问题产生的问题根源，基于自己经验也思考了下(不局限于):
1.后端开发人手不足，既要对接多个前端(有时前端工作模块分配不合理，类似功能不同的前端人员，需要反复和后端对接)，有时还要对接第三方接口人员(跨部门沟通费时费力，有时沟通下来又变成了从需求开始说起)，导致任务下发时，给到后端开发时间不够，最终开发只以实现功能为目的(至于自测，分支自测，优化重构，思考什么的，基本没时间)；

2.和第三方接口对接，缺乏文档，私下对接，甚至口头对接，边写边对接；

3.缺乏重构的理念，不知道怎么重构或者什么时候重构，以为重构那是后面的事(重构再写下第一行代码的时候应该是);

4.测试人员更多是基于功能性页面测试，缺乏接口测试，导致很多接口定义不合理的问题被屏蔽(前后端抹平了接口问题)；

5.缺少代码审查的环节，特别是重要接口(如复杂功能，逻辑复杂，核心接口)，开发人员没有白板演示自己的实现逻辑；

......

2.3. 解决方式

解决方式:
1.补充后端开发人员，设计人员和开发人员任务分开(你设计我开发)，设计人员审查开发人员代码(你开发我审查)，开发人员可以针对设计提出质疑和见解(你建议我调整)；

2.迭代开发 只要超过3天工作量或者涉及流程改动，需要有设计文档，磨刀不误砍柴工；

3.区分核心项目、核心功能、核心接口，开发过程中，针对是重要接口需要做好代码审查，当开发和设计有冲突时，必须同步沟通好，如无法解决冲突则按设计来(不能按因为代码实现容易的来)，防止开发时随心所欲,,设计文档和代码实现完全脱轨、失控；

4.前后端人员分配任务以模块分配 而不是以页面来分配，一个模块是高内聚低耦合的，页面可能是松散的，不同页面同一个模块接口，反复过来沟通反复编写重复代码，毫无必要；

5.每个后端开发人员安装alibaba-java-coding-guidelines，每天下班之前扫描自己的代码,根据guidelines指导意见，修改完代码，如果无法修改的请注释文档；

6.每个月可以组织代码审查，相互审查对方代码(对事不对人)，写得好的可以给大家讲讲自己心得(可以给与及时奖励)，大家一起学习，写得不好的加强代码质量(自身学习代码重构之道等书籍)；

7.补充测试人员，基于测试，目前更多是页面功能性测试，每个项目都去做接口测试，收益比估计比较差也没必要，我这里建议，补充测试人员(特别要加强接口测试),针对C端场景的接口必须做好接口测试(后续可能需要压测,容错测试)，目前该应用层比较混乱(app,h5,小程序,web),这里可以剥离出C端接口，单独一个应用层，该应用层的接口是可以被接口测试且稳定的,针对该层开发必须稳定，测试必须做好接口测试；

......