高级工程师的开发经验总结：减少代码Bug的技巧分享

有人调侃到，程序员不在写Bug的路上，就在改Bug的路上。没有完美的程序，固然会产生Bug，既然没办法彻底解决，那我们可以借鉴参考一些方法论、一些经验技巧来规避减少。
以下内容来自团队内一位高级工程师的分享，他在工作中极其负责、交付质量高、做事总是能给出惊喜的存在。

遇到bug各种程序员是怎么反应的？

• 理性型
  这个bug能复现吗？
• 自负型
  这不可能，在我这是好好的。
• 经验型
  不应该，以前怎么没问题？
• 幻想型
  可能是数据有问题。
• 无辜型
  不应该，以前怎么没问题？
• 乐观型
  只需要改一行代码，不会影响其它程序的。
• 实践型
  你重启一下服务试试。

如何去改善bug呢，接下来从三个阶段来描述，分别是：需求阶段、开发阶段、提测阶段。

一、需求阶段

1. 需求评审前提前熟悉需求

理想情况下，评审需求过程中遇到问题，都在会议中讨论解决；但这会导致需求会议拉的过长，参会人员注意力减弱，间接影响需求质量的判断，其他需求项目进度等 。

提前介入熟悉需求后可以协助产品优化质量，可以勾画出一些大致的技术方案，提高会议评审效率，最终可以减少由于需求质量导致的bug数量。

2. 需求评审中需要勇于提出问题

1、需求评审过程中发现问题需要及时反馈，小问题可以理解给出对应的解决方案，大问题记录会后再给出解决方案。

2、提出问题后能加强自己在项目的参与度，也能提高在会议中的注意力，对需求理解也能更深刻。

3. 中大型需求输出功能流程图

1、输出流程图的过程就是你对这个需求的熟悉后的产物，后续的开发、自测、迭代都可以结合流程图再执行操作。

2、输出图的过程也间接培训了你的功能使用，如何更加简单明了的表达你的想法和方案。

4. 需求问题跟进

任何事情不可能保证100%不存在问题，发现问题后需要记录，及时和产品沟通，需要评估是否影响整体排期，人员配置等。

三、开发阶段

1. 代码逻辑结构设计

1、开发阶段先画流程图，再开始写代码。
2、根据业务场景设计可以用什么设计模式、是否需要模块化、是否需要幂等等，可以先打个初稿（伪代码）。
3、重要的场景需要重点标注，花更多的精力去攻克它。

2. 工具化代码

1、封装一些常用的工具类，避免重复造轮子，例如：金钱工具类、日期工具类、数据转化工具类等。
2、接口调用封装，多一层Component或者采用DDD的架构，其他项目调用汇集一个类，后续的切换，迭代快速查找更新。
3、中台化、微服务

三、提测阶段

1. 代码开发完需要进入自测流程

1、可以利用postman/dubbo/test类等工具执行测试用例。
2、自测可以结合技术方案流程图和测试提供的测试用例设计场景和数据。
3、push代码前使用git代码对比，再次确认提交的代码没问题。
4、提测后一定要在测试环境再跑一轮，不然很可能被测试打回冒烟。

2. Code Review

代码评审是代码规范性的保障、带来知识传播、团队建设。有的人可能觉得代码评审就是找出错误的，觉得代码评审没有必要，实际上并不是这样。

从编码者的角度来说，每天都忙于紧张的coding，交付时间马上到了，为了快速交付于是降低了要求，不写单元测试用例，coding的时候也没有从性能、安全角度去考虑更好的实现，虽然按期提交了代码，然而却不是一份高质量的代码，在运行中可能出问题、后来人接手也不好接。

代码评审可结合项目情况、时间紧急度、是否核心功能进行按需评审，尽可能在发版前多暴露问题。

—the end.