codeReviw层级和意义,业务后备

review意义

很多人以为codeReview的意义是保障质量.

但更多的是

     1.业务知识分享和反向check  2.组员互备,当有人忙于其他项目或者请假时,要顶上.  3.通过单测对输入输出来反向check业务逻辑. 4. 依托测试系统性的case去评审代码逻辑是否覆盖全 5.重点日志打印,日志比注释重要  6.设计评审中没有发现的模式和反模式.

     发现代码质量问题不是重点重点: review之后大家业务和技术知识的成长,了解剖析业务的方式才是关键.

    

    要建立在模块划分的基础上,并且团队内部要明确职责. 代码边界要清晰. (好的边界是放在不同的子工程里,通过api互相依赖.每一层要有interface. dao daoService bizService apiService integrationImpl integrationService bizService api)

目前模块划分后才能明确哪些是通知,而不是通过接口了解一大堆别人的业务(按需传递参数过去,应该是别人反向调用我的领域类接口组装,正向调用也可能是通知哦(修改类操作.))

1. 结对业务.

   正向:

       1.1 业务知识传播

        1.2 业务对应代码实现传播

   反向check:

       1.3 变量命名是否符合业务背景反向check,业务反向知识check

       1.2 反向check,保障规范执行.

       1.3 单测反向check,保障代码质量. (codeReview规范,如无特殊案例,没有对应单测空格,发红包10元)

业务后备还有一个重要的操作是 1.线上问题让其他相邻模块的人排查.  2.每周让相邻同学学习表结构,流程现场画和ppt.

2. 结对编程

   1.1 格式,变量命名

   1.2 设计模式

   1.3 模块化设计思维,边界思维.

review层级.

0.事先业务背景how,why和最终的what 1.格式化 2.从模块化的思维来考量业务,业务背景(变量,类,方法,背后的业务含义) 3.类层级关系控制 4.单测反向check和从单测了解业务,tdd角度,先看单测,了解输入和输出,质量保证.4. 依托测试系统性的case去评审代码逻辑是否覆盖全 5.重点日志打印,日志比注释重要 6.小模块owner和业务知识互通 7.设计模式演进