代码review问题总结

1. sql层不要太复杂，一些计算比如同比环比最好放到业务层。如果之后数据库要分表，sql太复杂会很难处理。

2. 一个实体类的属性要干净，一些不想关的属性可以另作为一个字段放到map中传给前端。

3. 请求体不要直接用map，可读性太差。如果参数数量少就直接放到param当中，数量多就弄成实体类放到请求体中。

4. 给属性赋值时，减少对单个属性set。能同时赋值的就都放到实体类中用构造函数或静态build方法统一赋值。

5. try catch的异常务必打印日志。

6. 特殊异常定义到全局异常Handler中。

7. 日期的处理单独建立日期处理类。

8. 实体类名称命名不是很好理解的话，加注释。

 

review的时候提到一些代码优化的问题，建议一些东西写死在代码里，如果出错的话再找负责人。

开发过程中我一般避免写死，因为在开发过程中需求还在不断调整，如果写死的话会在开发的时候带来不必要的麻烦。

两种做法有利有弊，写死的话代码逻辑简单，相当于用代码和数据端做了约定，如果约定的东西出错了就能直接追责；缺点就是不够灵活，需求调整或数据类型调整代码丢可能会有多处改动。不写死的话需求调整代码的改动量不大（但是还是会有改动量），但是会导致代码逻辑较为复杂，可读性变低。

另外这次需求表结构设计的不够好，一些应该由数据端提供的东西放到我们这边的维表里，取数的时候经常要join、sql复杂，并且无法做到数据端和工程端完全解耦。

优点（个人觉得）代码复用挺好，没有太大的问题。问题集中在实体类功能不够精简这一块。