1、不管是做需求还是测试，都应该考虑整个链路，确保兼容性或者其他模块不受影响。比如内容创作改动，应该考虑到审核侧、内容分发侧是否正常。
2、需求一定要经过测试。不要站在自己的角度，以为测试人员无法测试某种场景。因为方法总比困难多，比如可以把链路当中修改的点单独拎出来进行对比测试。还要多提一点的是，尽量在代码修改处添加日记，确保测试能覆盖到。
3、输出日记时也要避免空指针异常。如果在业务逻辑中不会出现空指针异常，却在输出日记时抛异常，那真的是冤大头了。
4、批量回刷或者删数据有风险，特别是无法恢复的物理硬删除。所以此类场景应该由用户主动触发，而不是借助定时任务批量执行。
5、数据和操作行为应该足够方便溯源。比如图片上传、批量删除数据。
6、代码上线时间也应该当成需求时间。当团队严格控制代码上线流程，比如技术方案评审、代码评审、提测、灰度发布、线上监控，你就会发现上线成本还是很高的。所以，管理好开发队列变得很重要。而秘决在于，质量优先，效率第二。
7、上游依赖接口检查。不只是要检查可用，还要检查准确度和质量。比如每页返回的数据量是否正常、返回的数据是否满足合规性和可用性。
8、避免过度设计。某些历史的实体POJO类的字段类型千奇百怪，可能是包装类Integer，也可能是基本类型Int，那么在MyBatis框架中使用xml定义一个大而全的SQL，比如使用来拼接Update方法，很容易将不需要处理的数据清空。当然手机号转让根本原因是POJO定义的问题，不过这是历史原因了，此时再修改它里面的字段类型，成本很高。所以，此时最好的方式是，新增的方法只更新它需要的，不要过度设计，不要急着考虑通用性。
9、开闭原则。它的意思是对扩展开放，对修改关闭。这个设计原则其实我们每天都在接触，比如方法入参定义为实体对象，当需要新增一个参数时无需修改参数列表，只需要在实体类中新增一个字体即可。这个原则的作用是应对变化的时候，还能够保证系统的稳定性。
10、依赖倒置原则。上游依赖属于原子类，具体细节不应该混杂在业务代码中。那样代码复用性差，而且当该业务方法出问题时，不能直接判断是否是业务代码的缺陷还是某个上游依赖的缺陷。甚至上游接口需要升级切换时，使用到它的都需要进行翻新，得不偿失。所以上游接口尽量抽象出来并且添加相应监控。
11、增强系统健壮性。主动检测不支持的情况并抛出异常，避免系统产生不可预期的结果，比如首先进行参数校验再处理业务。很简单的操作，但是可以有效增强系统的健壮性。
