1.对外暴露接口必须要有返回，必须response类型，禁止使用void返回。
    2.尽量避免用“异常”，“系统错误”之类的文字，这是为了防止具体操作人员认为代码质量不高。
    3. log记录是写给我们自己看的，尽量描述清楚出错位置，原因，最好还要附上错误信息。
    例如，log.error(“projectService.update更新项目时，根据projectId查询customerId异常，此时req是{}”，projectRequest)；
    4.不参与更新的，不要写更新语句中，尤其varchar类型，要加非空判断。
    5.手写魔数容易出错（601010），建一个常量，直接计算，防止手写错误。
    6.对象与数据库类型不匹配。
    7.实时时间从java中获取传入数据库，防止时间记录不准确，sql还有问题，还有没有记录更新者信息 。
    8.同一mapper对应一张表。如有连接查询的情况，哪张表是主表，就写到那张表对应的mapper.xml中。
    9.Integer类型，不需要验证 status != ‘’，只需要验证null != status即可。
    10.数据库中查询只能查询出对应的实体（Entity）、VO、DTO。查询出做转换得出response返回前台。
    11.结束时间、开始时间均是long类型，不需要做 !=’’ 判断，且传入多少就是多少，校验不等于0没有必要，只需要在传入时做valid判断是否是正整数即可。
    12.更新结果不符合预期，有抛出异常，没有回滚，应该添加事务注解，这样在更新出现异常时（如预期更新一条记录，结果更新了10条），可以回滚到更新之前。
    13.update 操作时，不可变的信息不要放到更新语句中，为了防止出现意外错误。
    14.SQL格式，保持可读性，堆积在一起的代码，可能没有错误，但是可读性不佳。
    15.命名是获取项目详细信息的方法名，结果就获取这么几个信息，名实不符，应该更改为符合结果名称。
    16.List检查是否非空，使用StringUtil是不对的。
    17.如果数据库中不存在记录，则查询出来的就是null。使用long类型接收，会被转换成0，导致无法获取最新提交时间，只有在类似count统计、update更新之类的操作才允许使用基本类型接收返回值。
    18.一个业务在一层内开始和结束，不要跨多层代码，SQL应保持通用性。
    19.request不要直接作为mapper的查询参数。
    20.代码错误，应为unitId。这是必传的字段，需要添加@Valid注解。
    21.不存在unitId对应的数据， 单独equals判断会报空指针异常。改为 if (StringUtils.isEmpty(customerId) && !customerId.equals(req.getCustomerId)){}。
    22.需保证单日至少提交一次有效代码。（每日下班前自查、走查）。
    23.页面组件需有明显注释。
    24.除非使用vue动态绑定，禁止在行业出现 style 属性。
    25.console.log() 需要加注释内容，避免没有注释的控制台输出。
    26.class避免定义单个动词，应改为 save-btn 或 save-icon 等。
    27.禁止出现此类无用注释。
    28.尽量在 if 语句中明确判断理由，或将条件维护成常量。
    29.首页缺少路由重定向，发送请求的写法基本都是重复性的劳动,可以写个公用方法，提取url和method，精简项目和减少加载的资源体积。
    30.路由映射页面，引入组件的写法重复性太高，可以提取个公用的引入方法，直接写在路由选项中。
    31.路由拦截器最好移到路由模块中，现在在main.js中。
    32.接口地址最好都放到一起，并且区分不同环境，element-ui组件的按需加载，减少项目体积。
    33.建议使用ref获取dom，组件名称混乱，js方法调用后建议加“;”结尾，css属性顺序混乱。
    34.尽量去除css的模板中的嵌入式写法，统一进行管理，多个class，换行书写， css缺少结束分号，颜色值尽量采用简短写法。
    35.统一规范，查询实体和数据实体分离。
    36.不做全字段查询，影响性能。需要哪些字段，查询哪些字段。
    37.超过3个参数，强烈建议使用对象封装。
    38.打印业务流程关键字段，不是打印全部入参、出参，没什么意义，增加日志压力。
    39.删除无效代码，合理使用虚拟字段。
    40.多次需要使用的值，单独定义出一个公共变量，多个地方公用的订单转换方法，抽取出一个公用方法。
    41.数据量大需要更新时，可采用批量更新。
    42.避免使用多重for循环，尽量用lambad表达式处理。
    43.常用属性字段，定义枚举类进行封装。
    44.List 对象copy 应用框架方法，比较不同对象中部分属性值是否相同，生成一个中间类进行属性copy并比较。
    45.保存询价单时对商品做了去重处理，修改为对商品重复提示。
    46.接口的版本尽量是兼容旧版本数据结构，后端返回全逻辑数据(前后端分离实现业务逻辑合交互逻辑分离）。
    47.数据公开-暴露过多数据是否存在数据安全隐患。解: 一般内部业务接口的业务数据是完整的，大多情况下对用户都是可见的，在不存在商业用途情况下可以适当忽略数据公开的问题，一定程度上便捷开发。
    48.流量问题-返回数据多对接口的性能会有影响，相应的数据流量也会增加。解: 对于当接口返回的数据量达到或超过了一定量的时候，数据的传输量的多少是一个比较重要的因素考虑，对于我们现在的网络传输速度，一般对于1kb以下数据的可以不用过多考虑
    49.热更新问题。解: 对于APP,版本审核更新后如果要热修只能是后端修改发布，所以要实现热修必须是在后端实现完整的数据逻辑
    50.代码现状：业务线负责自己代码维护,出现了同一个板块的功能不统一，杂而不专。
    51.服务池返回Resp：方便聚合服务直接返回对象,出现了一些情况下API的接口和服务池返回数据结构不隔离，出现了API的接口数据结构和服务池返回的接口数据杂在一起不好维护。
    52.包结构问题：订单、收集、权益应该脱离cms，单独一个项目或者cms同级。
    53.对象注入问题：推荐使用构造器注入，在编译阶段能识别对象不能为空。
    54.rabbitmq的使用：使用时要充分利用mq的特性，解耦，一个mq消费夹杂过多的业务线数据，且尽量要保证支持重试
    55.rabbitmq重试使用注意：需要考虑接口的幂等性。
    56.方法命名、注解问题：命名能表达方法作用、方法注解必须要写。
    57.rabbitmq的消费业务隔离问题：需要区分业务功能，不能把功能杂糅在一个服务里面，需要把不同业务功能放在不同服务里面，通过MQ广播模式可以实现。
    58.使用MybatisPuls时使用表的字段名: 不能在实体类、*mapper.xml之外出现表字段。
    59.魔法值问题：定义常量、枚举类、局部变量等方式，注解link/see关联常量查看。
    60.功能冗余：同一个业务的功能在多个地方有重复代码，不利于代码维护。
    61.自动代码优化【CTRL+ALT+L】、自动导包优化【CTRL+ALT+O】。
    62.Feign接口删除没用的接口，不能直接使用自动生成的fegin文件。
    63.Fegin本地联调优化：url=”${local.url:}”,需要本地联调时在启动参数里面配置local.url即可。
    64.Lombok 使用 建议尽量不要使用 @Data 注解 而是使用 @Getter @Setter 来生成get/set 方法 避免@Data 注解 默认toString() 和 equals()方法 重写时使用显式代码。
    65.检查当前微服务是否已经配置 /actuator/shutdown 功能，没有配置不允许启动。
    66.只要重写equals，就必须重写hashCode。
    67.因为Set存储的是不重复的对象，依据hashCode和equals进行判断，所以Set存储的对象必须重写这两个方法。
    68.如果自定义对象做为Map的键，那么必须重写hashCode和equals。 说明：String重写了hashCode和equals方法，所以我们可以非常愉快地使用String对象作为key来使用。
    69.使用集合转数组的方法，必须使用集合的toArray(T[] array)，传入的是类型完全一样的数组，大小就是list.size()。
    70.不要在foreach循环里进行元素的remove/add操作。remove元素请使用Iterator方式，如果并发操作，需要对Iterator对象加锁。

    代码走查流程

    1. 1)       Business Logic Error
    2. 业务逻辑错误
    3. 2)       Code Logic Error
    4. 代码逻辑错误
    5. 3)       Unit Testing
    6. 单元测试是否完备就绪
    7. 4)       Coding Standard
    8. 没遵守代码规范
    9. 5)       Comment
    10. 注释没写，太少，或者格式不对，或者毫无意义
    11. 6)       Existing Wheel
    12. 重复造轮子，或者是开源项目，或者是公司已有代码
    13. 7)       Performance bottle and Improvement
    14. 性能瓶颈和提高
    15. 8)       Better practice
    16. 存在最佳实践Java或者开源项目，有更好的实现

    任务发布流程

    1. 正确理解项目需求。
    2. 拆分任务、及下达任务
    3. 开发人员阅读项目需求文档。
    4. 输出概要设计。
    5. 概要设计讲解会议。
    6. 开发人员任务工时评估。
    7. 复合开发工时。
    8. 开发任务排期。
    9. 通知测试部门提交测试时间 。
    10. MOCK数据编写。
    11. 执行开发任务。
    12. 通知项目管理人员验收任务。
    13. 通知产品人员进行功能验收。
    14. 产品员进行功能验收，确认签字。
    15. 项目整体冒烟测试
    16. 提交测试。