crm代码评审学习

 一 关于业务代码评审有感

最近在看组织代码评审的时候，发现还是很多值得总结的地方。

    1 缺乏校验：

      新人对边界缺乏必要校验

  2. 过渡校验：防卫性编程。

    本身项目是分了层的，比如web工程，到家有自由框架dwf.有controller，中间是service，当然service也可能包含了rpc的调用其他依赖的服务。

   底层dao。  也是防卫性编程，前面一层都做了入口校验，中间的service还要在校验。内部调用都不放心，导致真正的业务逻辑占比不大，

估计有1/3左右做各种校验及逻辑判断。

   简单的可以把检验抽出一个方法。这样以只关心核心业务逻辑、

当然team内可以开发一套公用的组件。基于注解的方式，去校验非空，长度，值大小等等。这样最好了，

3. 异常处理：

   前面说的校验本身各种校验不过会返回异常，参数多的话，这块会一大块代码，简化后会好很多。

   另外，业务内部出现异常时，有的就层层抛异常。

  还是要关注下，自己不去保存好现场，抛出异常给上级调用，调用者也容易晕，尽量的少传递错误，少去做兼容，

及时停止，返回异常。

  另外就是异常的处理流程本身：关键异常有没有捕获，文件打开关闭，流的关闭，超时设置等等、

4. 编程规范：

   命名，缩进，大括号使用等等。。。

   

*****************************************

多说两句：

1 。项目管理平台接入sonar，提测时自动检测。

    这个需要摸索，有时候sonar统计不准，单元测试覆盖率就容易出问题。

2. 还是推荐阿里的编码规范。