开发注意事项

第一，产品需求变更记录（聊天记录需要保存）以免引起误会。

第二，对外接口异常自己捕获，不要抛到其他系统，尽量将异常控制在本系统内，此外抛出异常要精确，不是所有的异常都是系统异常。

第三，dubbo服务是rpc服务，交互的参数以及返回值，必须序列化。

第四，日志尽可能多的打印输出，在入参和返回值之前必须打印日志，方便定位问题，99%的错误情况都可以通过查看日志来解决。

第五，开发时变量名尽量取准确，做到无二义性。

第六，测试数据尽量接近真实环境，以方便测试。

第七，尽量设计通用的方法或者类，多复用。

第八，研发之间交流要清晰准确避免理解有歧义，修改了那个功能或者那个字段需要准确具体描述说明。

第九，替换包时要随时备份，因为可能会替换包失败从而影响已有业务，并且这样能够快速恢复服务。

第十，上线这段时间都比较暴躁，bug较多，需要及时修改，需要小心，耐心一点避免踩雷。

第十一，尽量多使用开源类库，因为大多封装较好，但使用时需要知道其原理，特点和缺点，要学会规避其缺点。

第十二，善用idea的提示修改功能，idea的提示建议一键修改，善用工具，利用好熟悉的工具将会事半功倍。

第十三，所有添加，查询功能均用id倒序排序输出，这样添加的记录能够在第一条显示，能提升用户体验。

第十四，修改代码时需要考虑波及的范围有多大，要保证修改的代码不能影响已有的功能，因此不能盲目修改代码。

第十五，要学会看日志信息，控制台输出的信息，绝大部分都可以通过控制台或者日志输出的信息来判断问题所在进而解决问题。

第十六，出现了问题首先找自己的原因，自己没问题其次在找相关人看看是不是其他人的原因，以解决问题为导向，不夹带个人偏见。

第十七，注意培养自己的代码素养，养成良好的编程规范，做事保持高效高质量。

第十八，谦虚，谨慎，多思考，多做事。

第十九，当产品上线之后，更改bug或者新增功能时需要在测试环境测试没问题之后才部署到生产环境，否则出现问题时会严重影响生产以及用户体验。

第二十，对于任何参数都要进行检查和校验，对于后台来说，前端传递的任何参数都是不可信的，都必须进行校验。

第二十一，在项目中对于标记或者标志类型多采用枚举值。

第二十二，对于项目目录结构一定要区分开来，把相关的模块放在一起，这样便于定位排查问题，把问题限定在最小范围内，不影响其他代码。在小范围内修改代码比在大范围内修改代码容易的多。

第二十三，改一次需求可能涉及到的方面比较多，因此改需求需要慎重考虑，前期改需求比较好修改，越到后面修改需求代价会越大。

第二十四，当一段同样的代码出现来两个及以上地方时，应该考虑将其抽取出来，作为一个统一的服务，供使用方调用。这样做的目的是方便程序代码解耦、修改和扩展。

第二十五，代码最重要的是可读性和可维护性，在编写代码的时候尽量用最简单易懂的方式实现功能，写好注释，以增强程序的可维护性，代码具有可读性和可维护性，可用性和性能自然也就满足了，至少大部分场景是能够满足的。

第二十六，每次更新了包不要立马部署到生产环境，修改的代码在通过测试之后才部署到生产上。

第二十七，写接口时多想一下，如何更方便的让调用方调用。接口的最终目的是为了提供服务，要做到简洁，方便别人调用。

第二十八，多人协作开发同一个项目，需要注意冲突，提交代码之前先更新代码。

第二十九，作为软件开发人员，需要懂得看错误码，要懂得如何排查错误，出现问题了不要一味的问别人，多思考自己的问题，多锻炼自己独立解决问题的能力，总结经验教训。

第三十，把基础代码写好，其他不要瞎想。

第三十一，站在整体的角度去理解系统，了解系统的各个部分是如何协同工作的，从而能够更加清晰的了解到自己在系统中所扮演的角色。

第三十二，一个接口只能做一件事情，就算有重复的代码在系统内部中进行提炼，对外一个功能只提供一个接口。

第三十三，写接口注意一下，只返回前端需要的数据，不返回多余的数据，以防止数据被利用。

第三十四，建议定期开需求回顾梳理会议，以确定需求是否有改动，做出来的功能是否和原型UI一致，每次都是先出的原型，后出的UI，都是先按照原型来开发的，到后面UI出来功能又不一致了。

第三十五，代码编译打包成功之后在进行提交代码。

第三十六，如果更新的数据和添加的数据差不多一致的情况下，可以把添加接口和更新接口整合成一个接口，根据条件来进行添加或者更新操作。

第三十七，程序在进行交互的时候，不要用中文进行交互，可能会出现乱码等问题，交互时采用英文或者数字较好。

第三十八，写供外部系统调用的接口服务时需在接口方法注释中说明是给那个系统调用的。

第三十九，做了什么比较重要的事情时需要记录时间节点以备忘。

第四十，定期清理回收站，但不要清理的太频繁，每周五下班前清理一次。

第四十一，重心还是应该在业务上面，需要多熟悉了解业务，其次是技术，不过前提是技术基础要有，知道怎么利用技术解决业务问题。

第四十二，写代码时多思考一下，需要思考可扩展性、可修改性和可维护性，例如配置项的灵活配置。

第四十三，发出去的消息还是得自己去跟踪啊，不然真的有可能肉包子打狗一去不回。要让消息形成闭环才行。