作为一名一线开发工程师，确保开发的代码不引发线上问题是最重要也是最基本的要求。尤其在业务需求多时间要求紧，开发的功能需要频繁发布时，开发人员就是守护版本质量最重要的一道防线。
流程和效率很难兼得
通过严格的流程控制可以保证版本质量，对每次修改进行严格的功能测试，性能测试，系统测试确保不遗漏任何细节，但是繁重的流程就会影响开发的效率，尤其不适合敏捷开发的流程。在敏捷开发小步快跑的版本迭代中，流程就不能太重，但是流程较轻，又难以把控版本的质量，设计合适的质量验证流程是非常困难的一件事情。
开发人员的技术能力不同，对业务的理解也有偏差，流程设计其实很难让每个人都满意。对于技术能力不足，业务理解也不够深入的同学，严格的流程把控可以规避掉很多风险，对于他们来说流程严格一点会比较好，因为他们可能自己也发现不了自身的问题；但是对于技术和业务理解都很深入的同学，严格的流程会浪费他们很多时间，因为大部分场景和风险他们自己都已经识别，再用同一套标准来审核他们，除了把流程重复走一遍，起到的其它效果就未见得。
开发人员对代码完全掌控，对技术和业务深入理解，是提高效率和减轻流程最有力的保障。
如何规避线上问题
在研发人员众多的公司，员工能力本来就是参差不齐，要保证大家上线的功能都达到一定的水平，必要的流程控制是免不了的，这也是为何大厂经常要加班加点干活，因为很多时间都浪费在各种流程上面。
要保证上线版本的质量，要么设置较严格的审批流程，要么提高研发人员的能力。下面聊聊对规避线上问题自己归纳总结的一些方法
开发前
开发前业务需求对齐，设计方案对齐。整理相关的材料，拉通业务和团队核心骨干进行评审，确保整体的方案没有偏差，业务和团队整体的方向达成一致。
评审需要准备的材料：
- 需求背景和目标
- 整体设计方案的介绍
- 当前流程和变更流程进行梳理
- 数据的ER图和关键接口设计
开发后
代码开发完成后，写单元测试用例进行验证，确保功能无误后找相关人员进行代码Review. Review代码除了帮助你提高代码的可靠性之外，还能提升你思考问题的深度。
帮你Review代码的人，一定是在业务和技术能力都相对较强，能够帮助你发现测试可能难以验证的问题，也是帮你在上线前把好最后一道关。
上线前
上线前是在测试验证功能已经ok，并且经过了性能测试之后，对整个发布的服务再进行一次评审。此时评审的就不验证功能或者代码相关的问题了，而是对整个发布流程或者兜底方案的评审。
注意事项：
- 上线发布服务的先后关系
- 对中间件或者其它服务依赖的性能压力，与线上环境进行对比
- 容错方案，发布的功能出了问题，有没有紧急兜底措施
上线后
版本能够上线发版也不是说就万事大吉了，很多问题前期不一定完全关注到了，毕竟线上才是最真实的验证环境。发布的时候一定要非常小心，出现任何的异常都要有相应的处理机制。
上线发布时一般进行注意观察如下异常：
- 发布服务本身有没有异常日志
- 整体的业务指标有没有波动
- 发布功能的关键日志是否有打印
- 发布机器的CPU和内存是否有异常 观察如上信息都是正常的情况下，还需要观察30分钟到1个小时，确保整体平稳后才能说明此次发布正常。
研发人员对自己的代码要保持敬畏之心，对每个步骤和流程要做到心中有数，才能尽量少的避免线上问题。以上只是自己踩过坑留下的思考，大家有什么避免线上问题的思路，欢迎留言讨论
