研发中总结的经验

1.和别人对接时，定义好接口规范，统一的请求和响应规范。后面加接口时，不用重新设计规范。

   做到复用公共报文，做到不支持修改，支持扩展。

   如果是http接口，则定义好报文格式。

   例如，text/plain或application/json等。

   最好文档化，口头的描述，容易出现理解上的误差。例如，定义了json报文，加一个字段时，

  json的字段添加地方不同，容易出现误差。

2.统一的日志格式。错从复杂的业务逻辑最需要日志清晰，结构清晰。

  特殊情况下，找bug时,日志写得更多。日志级别一般，用info级别，找bug，就用debug级别。

  controller层把获取的重要参数和响应的信息打印出来。便于排查异常。异常时，打合适的日志是好习惯。

3.统一的捕获异常机制。定义好异常级别。异常类型选择Exception还是具体的异常。

   想捕获异常，但是具体异常写不全或没有把握的时候，就选择Exception。选择Exception，

   程序逻辑不收异常影响。

4.同一个数据库记录对应不同的业务入口时，一定要求数据字段补全。如果数据字段值不全，

   会影响使用该数据的其他业务。而且是致命。这个和上面的三个建议一样，定义数据字段规范。

   不然因数据不全导致，坑其他业务，团队中其他人员可能仿照你的错误习惯写代码。

5.学习新的框架时，不急于全部掌握，而是学习自己能理解的，不断的啃，能啃下难懂的代码。

    对于数据结构，算法，二进制转换等技术难点，需要多写代码，多使用。

    如果有大量的数据时，考虑不断优化数据表结构，对mysql的底层理解，而进行优化。

6.开发过类似的功能，尽量服用，不要重复造轮子。如果觉得有价值，可以重新实现。

   尽量用基本类型，减少字符串来定义数据结构。字符串和基本类型的性能相差太多。

   例如，金额最好用int类型，不用bigDecimal类型。int类型时，单位选择分。在数据库中的时间字段 

   也选择bigint(20),不选择datetime。消耗性能。

7.需求是由起点和成立的条件，如果发展过程中违背起点，果断放弃。

8.开发的程序试运行测试通过，符合产品需求不要急于升级。加强测试和沟通，多方确认升级。

   虽说程序写出来，但是考虑使用功能人员的感受。多次升级，会让人感到你写的程序不稳定。

9.mysql库表设计时，遵循设计范式。一般开发中到第三范式。

10.java的enum类定义后，默认拥有values()和valueOf(String)方法。研发中，enum类使用场景很多。

enum类，比自己定义Constants类定义常量方便。enum类是特殊的class类。除了不能拥有构造方法外，

扩展普通方法。

11.开发业务逻辑中，事务中尽量减少操作。让事务短小。例如慢查询不应该出现在事务中。而是事务之前，

查询结果。

13.商用环境上，研发有只读权限。没有写权限。这样避免，开发人员误操作，后删除或修改重要的应用文件。同时，也带来了幸福的烦恼。例如,发布新应用，运行一天，想检查内存及垃圾回收状态。使用jstat命令查看内存，结果显示could not attech pid  警告。该用户无法读取java进程内存数据。但是root用户可以的。

14.要求代码结构清晰，层次分明。每一层做什么，参数类型定义好。每个方法中不要写太多行，算法实现等有些情况例外。注释要写，越是负责的业务越要有清晰的注释，因为代码是给人看的，所以注释重点清晰，逻辑强。最讨厌注释中的作者，时间，参数，异常等信息一堆，不写实现功能。