1.关联的记录删除时互相考虑。删除班级要考虑班级里还有没有学生

2.增删改查时，需要判断记录是否存在

3.抓手，证明。做的需求需要找到证明需求是否有用的口径数据，并用其证明需求是否有效

4.发现很多事故都是因为想要重构优化代码 = = ，根源是重构代码之后回归测试不严谨，或者甚至根本不进行回归测试

5.看代码逻辑的优越方法：直接debug进去

6.更改数据时，在同一个版本基础上更改。会有ABA 问题问题：并发1在修改数据时，虽然还是A，但已经不是初始条件的A了，中间发生了A变B，B又变A的变化，此A已经非彼A，数据却成功修改，可能导致错误。使用乐观锁的概念，每次提交时使用查询出的版本，提交时check版本号，提交版本与存储版本不一的时候。不允许提交。

9.在用户使用的功能上打点，通过打点分析出用户习惯，挖掘出用户需求。

10.收发消息，比如tiger。如果消息体发生了变化。应该保证消费消息的逻辑是兼容新旧消息体的。上线时应该收消息的逻辑线上线，发消息的逻辑后上线。

11.不同步别人的表结构，否则要跟着同步该逻辑 （其实是不冗余）。在设计系统的存储时，原则上不应该存储冗余数据，一是浪费存储空间，二是让这些冗余数据保持一致是一件非常麻烦的事儿

12.实现功能的时候，调用的下游的rpc接口，如果下游不稳定，加开关防止调用的其他流程影响主流程时延。

13.使主体流程与旁线流程解耦，1）tiger消息