随着做的业务越来越多，需要维护的模块也越来越多，我将遇到的bug大致做了一个分类

随着做的业务越来越多，需要维护的模块也越来越多，我将遇到的bug大致做了一个分类：

• 自己的bug
  • 旧业务出现的bug
  • 新业务出现的bug
• 非自己的bug
  • 其它同学在自己之前业务里改动到了代码，导致的bug
  • 因值班等场景，需要定位的bug

可以看出来随着工龄递增，每天要查的bug越来越多，为了避免成为 斐波那契程序员（指：每天都在修前天和昨天写的bug）。

亟需重新审视整个查bug的流程，提升效率。

经过思考有两方面需要优化：

• 减少bug数量
• 查询bug流程标准化

一、减少bug数量

处理新业务时，关于出bug的情况会有如下情况：

• 踩了旧业务的坑
• 自己新业务的bug

（一）旧业务的坑

关于”踩了旧业务的坑”，我经历过N次血泪事件，

在面对旧业务时，本来以为有业务文档就会万事大吉，但现在回想起来，

业务文档最多只能描述清楚「业务框架设计思想」，相当于「目录」，

真正踩到雷的地方都在旧业务代码细节上，比如：

1. 对象判空只用了`extInfo`，但实际上需要`extInfo && extInfo.length > 0`
2. 字符串判等用了"=="

所以「业务文档」并不能有效地减少踩到的旧业务的坑，文档不会详细说到用什么方式判等，

我们能做的就是尽可能和原业务负责人沟通，然后在上线前快速回归雷。

回想一下，自己和旧业务对接时，哪些业务出现的bug少呢？

印象比较深刻的是：「收藏」，在处理视频号「收藏」业务时，

时间紧、工作量大，但将视频号卡片接入「收藏」却异常顺利，为什么？

1. 「收藏」业务代码非常规范，属于框架都搭建好了，新业务接入只需要在 Switch case 里填上数据源和UI即可
2. 「收藏」业务负责人很负责，会把可能踩到的坑都记录下来

所以为了降低”踩了旧业务的坑”的情况，我们要向原业务负责人请教如下流程：

• 文档：架构设计文档和踩坑文档
• 需求评审：把自己的需求和打算的实现和业务负责人讨论，让负责人帮忙评审

另外一方面，我们负责的业务模块也要按如下指标要求自己：

• 文档沉淀：指业务模块设计思想
• bug沉淀：业务踩到的坑
• 框架约束：严格设定业务模块的代码，让新业务接入时，尽可能不要改动到现有业务的逻辑

（二）自己新业务的bug

自己新业务的bug，方案设计时就要考虑好各种路径，将一个需求实现闭环，

即：从需求入口，到需求结束的所有可能情况都罗列出来。

业务紧张时会漏掉「罗列路径」这个环节，但实际上因漏罗列而导致路径覆盖不全修bug的时间，

远超罗列路径的时间，而且路径覆盖不全对整个项目都是非常大的风险点。

二、 查询bug流程标准化

最初查bug时，我是以查到bug为终止点，所以这样会出现两种情况：

• 每次查bug流程不固定，定位bug状态时快时慢
• 查完bug fix之后，查bug的结果就没用了

但查bug多了，我发现查bug其实也可以做成标准化，而且查bug出的结果也是可以复用的。

（一）bug定位标准化

目前我是按照如下的模板进行bug定位，来了一个bug，基本走一遍下面的模板，

bug就可以很清晰的定位到，且可以复现出来。

uin：
时间点：
问题：

猜测可能出现的问题：xxx

用户路径：
>> 01:00 xxxx
>> 01:01 xxxx

必现路径：
>> xxxx
>> xxxx

bug原因：

影响范围：

（二）bug结果复用

定位到bug后，我们将上面”bug模板”按所属业务同步到文档里，这么做会有两个好处：

• 方便后续追溯：后续遇到类似的case时、或者回想起自己曾经解决过某个bug时，可以翻查
• 复盘：每过一段时间可以查看每个不同业务的bug量，如果一个业务出现的bug量多，那么表示这个业务模块可能需要重构了

三、小结

程序员每天的工作正好比在战场前线，不断扮演着「冲锋（写需求）」与「救援（修bug）」的角色。

这篇文章做了如下的回顾总结：

• 自己在旧业务上写需求时：要能够将方案与原业务负责人讨论，深入讨论，阅读文档
• 自己独立写新需求时：提前做好闭环路径图，力求自测覆盖每个路径
• 有新同学在自己旧业务写需求时：同样要有owner意识，一是尽可能不要改动到原有模块，二是帮助新需求尽可能不出bug（踩坑提醒）