新项目的检查点，服务中如果存在，一些共享资源耗尽，如 DB 链接，tomcat 线程，会导致整个服务应用的瘫痪。
一些经验:如果一个数据表，查询没有索引，会导致，全表扫描，导致 cpu 使用率高达 100%，导致所有依赖这个 DB 的应用无法响应。
下面是开发时候的一些注意点（常驻心中）：
-
0
墨菲定律凡是可能出错的事必定会出错 -
1 业务的主流程
-
2 如果流程有变化，看新老业务是否符合需求，以及改动点
-
3 BD create_at update_at 排它编码
-
4 文件流关闭
-
5 读取文件比较大的时候，进行分页读取，而不是一次性把数据都读取到内存中
-
6 完善的 junit 测试
-
7 日志打印规则 info error,打印合理的日志
-
8 请求，响应 主键关联
-
9 DB 数据字段，长度不要过长，禁止过短，导致数据丢失，订单号的长度，必须与对方确认，避免过长!!!
-
10 http 链接超时，读超时，的设置
-
11 JMS 消息幂等控制
-
12 mysql 索引无效（1，函数，2 索引字段存在类型转化）
-
13 数据库事务
-
14 尽量避免复杂的 SQL 查询
-
15 第三方外部订单号的处理，第三方的订单号的规则都是不一样的（类型&长度）,需要与第三方协商，确定长度&类型
-
16 工具类的使用，在使用之前都要确认下
为什么这么写??!!避免业务场景的不同，导致隐藏的问题出现 -
17 与第三方有关的状态判断,
必须与第三方核实 杜绝想当然的处理 -
18 数据完整性的检查（业务相关的状态很重要，在代码层面修改之后，测试环节的数据验证也是十分重要的）
-
19
空指针的检查，存在NULL的集合，对象，一定要进行是否为空的判断，（实际情况很复杂，一定存在为空的情况） -
20 当 DB 中的
表结构修改后(如：新增字段)，需要注意与之相关的业务代码都要修改,避免遗漏 -
21 项目构架如果用的了
MQ消息队列，那么一定存在消息队列延迟的问题，此时对于数据的处理一点要小心(异步构架的项目) -
22 在编写
业务接口的时候，要了解业务的上下文（业务场景）避免业务性的逻辑Bug -
23 代码设计时，对于公共的代码，思考后续
可能重复的地方，用法，进行适当的抽象，或者提供工具类 -
24 对于开关配置，需要在服务发布之后再进行
打开,如果服务没有部署，而开关打开，就会发送错误 -
25 枚举类的对比，必须要使用
String类型的 code equals 方法进行对比，二不能使用Enum本身的equals进行对比 -
26 在进行数据配置的修改时候，需要确定
修改前与修改后的差别,避免修改前后，到时逻辑冲突的发生!!! -
27 同步/异步的处理
-
28
边界,新旧兼容（代码与数据库新旧兼容） 问题思考 -
29 异步构架，添加数据监控，发现数据不一致的潜在问题
-
30 完善 junit test,修改业务逻辑后，用单元测试保证逻辑的
完善性，正确性 -
31
接口流程变更之后，需要对旧的流程进行重新的思考，找到潜在的问题 -
32
base64中文乱码问题，签名时谨慎使用 -
33 上线数据确认
-
34 细节 细节 细节
-
35 数据量过大超过千万的表，即使使用了索引，多条件查询依然会很慢，导致慢查询，需要进行优化
-
36
activemq异步消息，如果消息量过大，就需要先进行数据的落地，在进行数据处理,避免数据大量积压在activemq -
37 单表数据过大，如果超过
亿,查询必须注意性能，否则，可能导致数据库 IO，CUP 100%，导致服务不可用 -
38 接口设计的稳定性（稳定性越高，后续修改会越小）
-
39 避免惯性思维
-
40 BigDecimal 除法除不尽的问题
-
41 软件设计，重要的设计思路和要解决的问题，看懂设计思路更重要，代码是最后的“果实”，如果设计思路错误，“果实”的味道就。。。
-
42 设计业务系统的时候，最好在业务单据上面设计一个 初始状态（如订单的下单状态），可以利用这个状态，实现“两阶段提交”等分布式事物的场景
-
43 思考后续业务数据量大的场景的问题，如CPU，内存，网络，磁盘 等资源达到最大值得时候，如果进行扩展和拆分，考虑成本+可维护性
-
44 复杂的业务，比如SAAS业务，冗余数据是一个
错误的选择,这样会导致数据各种回写的操作。导致回写地狱，各个业务之间相互耦合。这个业务是有业务逻辑的，导致逻辑复杂。可以改成查询数据，而不是冗余。