1、请求外部接口需要注意超时降级，不能因为超时等原因影响本系统响应时间
2、能复用的代码坚决不重写，哪怕只是一个判断，只要判断的入参是一样的，不能在不同类写这样相同的代码，我们需要创建一个helper或是其他什么专门用来做判断的类来进行实现
3、不同类之间的方法调用不要传递对象的引用，而是字段值，防止代码污染
4、方法的命名一定要见名知意，query方法里不能有赋值语句（比如赋值成员变量）
5、如果代码逻辑经过了重构，则在提交代码前需要把每一行都过一遍。codereview坚决不能出现业务逻辑bug
6、请求外部接口如果失败是否会对本系统产生脏数据，比如部分成功。需要做好处理
7、如果需要将数据缓存在内存中，则需编写util类实现这些缓存数据的获取和刷新，这些逻辑不能写在biz业务类中
8、在【所有】方法的入口应该对所有的入参进行判断
9、当一个系统需要与另一个系统进行交互，则必须在交互前将发送的数据转为json打印日志，方便排查问题
10、如果你在程序的主线程添加一段逻辑，该逻辑需要频繁访问外部系统拉取数据或是一些不是那么重要的行为，那么你需要将这段代码放入异步线程做定时任务或其他实现，尽量对主线逻辑做最少的影响
11、敲代码前确保把需求和现状完全搞明白，可以先做一版伪代码评审
12、如果一个方法的if、for层级过于复杂，需要将一部分抽取出新的方法，前提是逻辑无法简化的情况。一般一个方法的缩进层级不要超过4个
13、老生常谈：缓存是放在jvm内存中还是redis，你首先需要考虑的是数据量，如果不大可以放到内存。放到redis中你就需要考虑一致性、防重等逻辑。
14、使用多线程是为了任务的并发处理，如果你只是使用future来实现超时控制，那么还不如优先考虑提升主线程代码的性能，比如哪怕将List.contains替换成Set.contains就会提升一些
15、是否可以对数据进行拦截校验，提前continue，这样可以节省很多cpu
16、调度任务线程池在执行任务的第一件事情就需要try-catch住，因为如果任务出错，线程池资源就会被释放掉，定时任务就会结束
17、代码是分层级的，对于工具或底层的代码方法一定要非常清晰，这里的清晰指的是不要让用户去猜自己拿到的返回值该怎样处理。比如你返回List。因为它不仅仅是给自己使用的。
18、如果你在原有程序进行了修改，改变了原有程序的流转，在关键处打印日志做记录
19、日志会影响性能，在消费消息队列等情形需要减少日志的打印
20、判断字符串、数字、集合或是想使用反射实现什么功能请使用开源工具包，不要自己写
21、如果你的代码使用到的表进行了按照天分表，则你务必需要考虑新旧表的切换是否满足业务，即你是否需要前一天的数据进而去查询前一张表
22、如果你的工作会影响到多个系统，那你需要警觉起来，每行代码都需要仔细斟酌
23、在上线前一定要分别在本地、qa、sandbox分别测试，至少要测试能触及的点，比如是否启动成功、开发的功能。在开发前就应该想好回归测试的点，提前设计每个功能点的测试case，即所谓测试驱动开发。把所有的需求设计和测试点都完成之后再进入开发。当然，所有的事情不会都一下子想清楚，剩下的事情可以边想边做。同时，需求或实现方式的变更是否会导致代码产生问题，需要及时修改测试案例，两者是绑定在一起的。
24、访问外部系统不仅要保护当前系统，做好降级超时处理，同时，你也应该考虑遇到极端情况的时候保护好外部系统，比如访问ES，不能给ES查死了
25、修改代码时，需要考虑当前的方法所在所有的上游分支，是否需要为修改的地方提供安全保证，同时当前修改需要自身做好安全保证
26、每次修复bug或是在原有功能上进行迭代，都需要进行完整的测试，从数据的生产到数据的消费完整的逻辑闭环。原有功能的测试用例加上修改点的新版测试用例都需要严格覆盖到
27、每次做需求一定一定一定要串行化的做需求，同一个项目千万不要同时在做两个需求。如果做不到，请在两个分支中不干扰的进行
28、测试的时候应该分功能模块测试，如果同时有A功能和B功能测试，先单独测A，B，最后测两者的融合，这样测试步骤多了但心里踏实
29、给表加上【唯一】索引可以避免很多意想不到的、隐蔽的逻辑漏洞导致的数据不一致问题
30、一致性校验问题如何解决快照数据和实时数据不一致问题： 校验结果持续的数据才是有问题的
31、代码的逻辑一定要是原子的，即不能上来一大堆代码。一般一个方法30行左右是合理的。如果你的代码出现了4层嵌套，就需要考虑是不是该换一种实现方式了
32、关于缓存：只要加缓存就需要考虑一致性问题，两者是绑定的关系。但是是否有必要一定加缓存呢？如果有细粒度的实时接口其实并不需要非加不可
