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消息