阅读代码记录

前段时间内部组织了一次代码评审会议，在评审中发现一些问题，在此记录下一些建议：

问题1 ：代码共享问题

        团队组员存在不清楚代码具体提交目录，只有负责代码提交人才知道提交目录，这种现象体现出团队的问题，既然是一个团队， 就应该要共享开发代码到团队中。

问题2： 阅读别人代码方式

       接触新的代码组件，首先建议先看代码提供哪些功能和api方法，然后通过阅测试用例，通过debug方式断点代码走向，理解代 代码数据流转，最后可以根据理解程度编写自己一些测试用例；

问题3：工具类定义问题

      像代码中经常出现一些验证手机号码，验证长度，验证不为空等可以抽离为一个工具类，这对于代码

复用是很有帮助的。

问题4：代码注释问题

      代码的注释合理性能够帮助阅读代码的人能够快速理解代码实现逻辑，注释基本可以分为类级别上的注释、方法上的注释、变量的注释以代码实现逻辑中的某些行的注释。类级别上的注释能够体现当前类的作用、作者、创建时间等，有关联类的话，可以采用{@link 具体类} 方法说明，方法中的注释要包含方法实现什么功能，入参与出参说明，入参数据格式要求等。

问题5：业务代码术语列表问题

        项目中经常会遇到一些判断为某一个值而走当前值的流程，经常是直接if("1".equals(type))｛｝而且出现同样业务逻辑判断的地方有多处，后期修改也比较麻烦，建议建立术语列表，通过公共静态变量或者枚举统计。

问题6：操作数据库类命名问题

        数据库操作类命名带有Dao的，对于这种命名方式各有说法，这种命名已经落后了，现在操作数据库类的命名是用mapper定义

问题7：单一职责问题

        设计模式中单一职责，分离不同类职责，将职责进行隔离，方法只能处理单任务职责。

问题8：命名规范问题

       类名与方法名要具有意义， 类名和对象名应该是名词或名词短语； 方法名应该是动词或动词短语； 属性访问器、修改器和断言应该根据其值命名，并加上get、set、is前缀等，推荐一本书《代码整洁之道》，值得一看。

问题9：范型使用的问题

       在使用范型的时候出现直接用Object代码具体的范型类(像：Map<String,Object> map）,这样会存在一些问题，一但出现某个对象不对称就会出现问题。

问题10：表驱动的问题

      业务代码经常会使用if(..){...}else if(...){...} else { ...}，这样看起来并不优雅，而且看起来难于忍受，像这种可以借助表驱动方法解决这类逻辑控制结构。

问题11：日志记录问题

     业务实现时需要记录一些关键业务日志逻辑，对于后期问题定位、统计有帮助。

问题12：抽象和具体问题

      抽象，指在认识上把事物的规定、属性、关系从原来有机联系的整体中孤立地抽取出来；具体是指尚未经过这种抽象的感性对象。

问题13：防范性的措施

     对于暴露出第三方的服务接口，需要进行认证与鉴权，这样可以抵御一些非法访问的问题。

问题14：接口容断问题

    在调用第三方接口的时间如果存在超时或者调用不了的时候，为了避免再去调用等待而把系统拖垮，需进行容断与超时处理。

问题15：代码3秒原则

    在看别人代码的时候，最好能够在3秒内能够看懂代码的逻辑，在3秒内如果看不懂就说明代码还是存在些需要改善的地方，同时对于方法

代码量要保持一个一屏原则。推荐一本书《代码整洁之道》

问题16：数据库时间字段问题

      在操作Postgresql数据库的时间字段时，datetime和timestamp时，建议选择用datetime，在查询的时间方便些。

问题17：代码就近原则

       把相关的操作放在一起，如让注释靠近所描述的代码，让循环的代码靠近循环的代码靠近循环本身。