第一，产品需求变更记录（聊天记录需要保存）以免引起误会。
第二，对外接口异常自己捕获，不要抛到其他系统，尽量将异常控制在本系统内，此外抛出异常要精确，不是所有的异常都是系统异常。
第三，dubbo服务是rpc服务，交互的参数以及返回值，必须序列化。
第四，日志尽可能多的打印输出，在入参和返回值之前必须打印日志，方便定位问题，99%的错误情况都可以通过查看日志来解决。
第五，开发时变量名尽量取准确，做到无二义性。
第六，测试数据尽量接近真实环境，以方便测试。
第七，尽量设计通用的方法或者类，多复用。
第八，研发之间交流要清晰准确避免理解有歧义，修改了那个功能或者那个字段需要准确具体描述说明。
第九，替换包时要随时备份，因为可能会替换包失败从而影响已有业务，并且这样能够快速恢复服务。
第十，上线这段时间都比较暴躁，bug较多，需要及时修改，需要小心，耐心一点避免踩雷。
第十一，尽量多使用开源类库，因为大多封装较好，但使用时需要知道其原理，特点和缺点，要学会规避其缺点。
第十二，善用idea的提示修改功能，idea的提示建议一键修改，善用工具，利用好熟悉的工具将会事半功倍。
第十三，所有添加，查询功能均用id倒序排序输出，这样添加的记录能够在第一条显示，能提升用户体验。
第十四，修改代码时需要考虑波及的范围有多大，要保证修改的代码不能影响已有的功能，因此不能盲目修改代码。
第十五，要学会看日志信息，控制台输出的信息，绝大部分都可以通过控制台或者日志输出的信息来判断问题所在进而解决问题。
第十六，出现了问题首先找自己的原因，自己没问题其次在找相关人看看是不是其他人的原因，以解决问题为导向，不夹带个人偏见。
第十七，注意培养自己的代码素养，养成良好的编程规范，做事保持高效高质量。
第十八，谦虚，谨慎，多思考，多做事。
第十九，当产品上线之后，更改bug或者新增功能时需要在测试环境测试没问题之后才部署到生产环境，否则出现问题时会严重影响用户体验。
第二十，对于任何参数都要进行检查和校验，对于后台来说，前端传递的任何参数都是不可信的，都必须进行校验。
第二十一，在项目中对于标记或者标志类型多采用枚举值。
第二十二，对于项目目录结构一定要区分开来，把相关的模块放在一起，这样便于定位排查问题，把问题限定在最小范围内，不影响其他代码。在小范围内修改代码比在大范围内修改代码容易的多。
第二十三，改一次需求可能涉及到的方面比较多，因此改需求需要慎重考虑，前期改需求比较好修改，越到后面修改需求代价会越大。
第二十四，当一段同样的代码出现来两个及以上地方时，应该考虑将其抽取出来，作为一个统一的服务，供使用方调用。这样做的目的是方便程序代码解耦。
第二十五，代码最重要的是可读性和可维护性，在编写代码的时候尽量用最简单易懂的方式实现功能，写好注释，以增强程序的可维护性，代码具有可读性和可维护性，可用性和性能自然也就满足了，至少大部分场景是能够满足的。