大家好，我是Z哥。

“这个 bug 的问题不是很明显吗？怎么这么久才搞定？”

“就改一行代码，你怎么弄了这么久？”

我想上面的言语几乎每个程序员都听到过。特别是面对那些“稍懂技术”的同事的时候。

我觉得这篇文章特别适合你收藏一下，为什么呢。首先，当你再次遇到这种情况的时候，翻开这篇文章，可以帮助你降降火，让你冷静下来。其次，还能时不时地在朋友圈转发给你的“稍懂技术”的同事看看，给他一些暗示，哈哈。

很多人之所以会产生前面提到的这种误区，是因为他们潜意识里将工作量与代码量挂钩了。

他们脑海里的程序员像电视电影的中的那些黑客那样，palapala 地敲击键盘，疯狂地 coding，看上去都不带思考的，然后软件就写成了。

我们程序员当然清楚，事情并不是这样。不管是实现一个新功能还是修复一个线上 bug ，我们都不可能直接上手 coding，因为我们不知道代码应该写在哪，怎么写。

/01  实际修 bug 的过程是怎样的/

就以修复 bug 为例，常规的处理流程是这样的。

1. 确定 bug 相关的环境信息。

2. 梳理 bug 所在的整条业务链路。

3. 分析 bug 在链路中的哪个环节产生。

4. 调整代码，修复问题。

其中的每一个环节都存在着增加时间的因素，我们来一个个展开。

/02  每个环节影响时长的因素/

01  确定 bug 相关的环境信息

在这个环节最常见的情况是，反馈 bug 的人员无法清楚地描述 bug 所处的环境，甚至是描述出现错误（比如参杂了自己的主观猜测，屏蔽了一些重要信息）。

这会导致程序员排查 bug 的时候，方向就错了，被误导了。一旦方向错了，不管花再多时间，都是白白浪费掉的。

虽然说一线的业务人员，不懂技术是常态，但是不可否认的是，这的确会对修复 bug 的时间产生很大影响。

02  梳理 bug 所在的整条业务链路

如果恰好这条业务链路我很熟悉，甚至是实现业务逻辑的代码都是我写的。那么这里花费的时间就少得多。但是如果不是的话，我还需要花时间去梳理业务，然后找到业务对应的代码在哪些地方，它们之间是如何组成、协调的。

这里可能存在的大坑是，这块代码不但我不熟悉，并且前人写的代码过于草率。此时，在几百万、上千万行代码的项目中，找到相关的几千行代码，并且捋清楚它们之间的关系，这可是个大工程，并不比把这个功能重新推翻重做容易。

03  分析 bug 在链路中的哪个环节产生

大多数人应该都听过斯坦门茨在福特生产线上画一条线收了 1 万美元的故事。他给福特开出的收据是：画线 1 美元，知道画在哪 9999 美元。

解决 bug 也是这样过，分析 bug 产生的根本原因才是最困难的过程。

而且很多时候，一个 bug 所表现出来的现象与问题根源并没有直接关系。

比如，提交订单提示库存不足。其实并不是库存不足，而是请求库存 api 出现了异常，甚至是由于下游的库存 api 内部异常导致。这种层层依赖随着业务链路的延伸会变得更加复杂，这自然需要大量的时间去抽丝剥茧。

还有更夸张的情况是，完全没有关系。比如，提示 XXX 失败，实际却是 YYY 的问题，因为这个提示语句是从其他代码里 copy 过来的……（有遇到过这种情况的来评论区确认过眼神一下）

04  调整代码，修复问题

条条大路通罗马，一个问题往往也有很多种解决方案。修复得快不代表修复得好，找到最简单、最优雅的解决方案是需要经过思考的。

哪怕是看似在确定的地方去修改代码，如果你运气不好，碰巧要修改的 function 对外有 100 多个引用，而且你还需要改动传入的参数……

此时，你得祈祷不会遇到那种牵一发而动全身情况，细品一下下面这张图你就懂了。

就算运气不错，修改的地方很容易搞定，但是如果在这个过程中发现了一些写得有问题的代码，比如容错性差、性能差等情况。此时，作为有责任心的程序员，必须得出手去改掉啊。否则根据「墨菲定律」，后面还是得出问题，到时候如果自己还在负责这个项目的话，解决成本就更大了。

而且，有更多责任心的程序员，还会举一反三，去将自己知道存在同类问题隐患的代码都去改掉。这也需要更多的时间。

05  修复完后

作为有责任心的程序员，并且出于对自己的口碑负责，肯定不会将结果的验证完全交由测试人员来做。

所以，自己还得多花一些时间来验证，自认为容易出现问题的场景下是否还会出现问题。这，也需要时间。

/03  提高修复bug效率的方法/

当然，上面这些理由也不是我们懒于提高修复 bug 效率的借口，对于如何更高效地 Debug ，包括应对生产环境的 bug ，可以看看我之前的老文。

《系统坏了，慌不慌》

《如何提高Debug效率》

如果你想未雨绸缪，外加条件允许的话，建议把单元测试也做起来。

《聊聊单元测试》

好了，总结一下。

这篇呢，Z哥和你聊了为什么很多时候修复 bug 没有想象中的那么快。

因为在以下 4 个环节都存在着额外花费时间的事情。

1. 确定 bug 相关的环境信息。

2. 梳理 bug 所在的整条业务链路。

3. 分析 bug 在链路中的哪个环节产生。

4. 调整代码，修复问题。

所以，如果以后谁还说你为什么修 bug 那么慢，把这篇文章发给他。你说不出口的话，我替你说了。不过，后果自负哦～

其实大家都不喜欢修 bug ，特别是在低质量的代码中反复修复同一类型的 bug 。但是现实中，好像也有不少的人嘴上说着这样，但自己却总是在写这些低质量的代码？欢迎分享你与 bug 之间的精彩故事给我～

推荐阅读：

• 我是如何保持长期写作的

• 被同事嘲笑说技术方案没深度？

原创不易，如果你觉得这篇文章还不错，就「点赞」或者「在看」一下吧，鼓励我的创作 ：）

也可以分享我的公众号名片给有需要的朋友们。

如果你有关于软件架构、分布式系统、产品、运营的困惑

可以试试点击「阅读原文」