修复bug的成本

     最近接到修复一个生产bug的任务。当然不是我引入的，如果是自己搞出来的我都不好意思说了。

     定位问题的同学已经知道问题所在：调用别人提供的方法时错用了另一个相似方法。

     动手改这个bug只需5秒钟——找到那行代码，调用本该调用的那个方法。就ok了。

       但事情远非这么简单。首先得验证到底改对了没有。自己觉得没问题了，提交Merge Request, 找Committer合代码，跑流水线，推sit环境，然后走问题单，告诉测试同学改好了。通常事情就算完了。半天时间也没了。

       但问题还没完。下游系统的同学找上门来了：你们搞了那么多垃圾数据，我们的流程走不下去了，你们要负责清理。好吧，那就清理。当然只有等版本变更的时候才能清理。参考下游系统查数据的sql, 又花了半天时间把清理数据的sql写出来了。但光清理数据还不行，还得把回滚脚本也写出来。万一变更失败，数据要回滚。事情看起来差不多完了。

       问题还是没完。既然给下游系统弄出了一堆垃圾数据，那我们自己的系统就没垃圾数据了吗？有的，这堆垃圾才是给下游带来麻烦的根源。必须得清理。流程中的数据要清理，且要保证不会让用户的流程走不下去。那已经走完流程的历史数据要清理吗？问了BA,也要清理。于是又花了一天的时间。sql搞出来了只是第一步，还要在dev\sit环境测试，还要找人在生产只读库上试一试。

      事情就搞定了么？还没有。你搞了一堆sql出来，又要在生产上执行，得让大佬们看一看。于是要准备评审，然后拉大佬们来评审。要讲清楚来龙去脉，讲清楚你是怎么做的，要让大佬们放心。

      差不多要结束了。但还没完。只有等变更成功了，下游系统没问题了，用户说没有问题了。几乎才可以说“没问题”。

      即使没问题了，可能还有下一步：要回溯、要分析问题根因、要找到责任人、要想办法如何避免再次发生此类问题，还可能需要把经验教训分享给其他小伙伴（当然这不是坏事）。

     如果当初写代码的时候多花几分钟看一下别人提供的方法，多测一下，何至于此？

    这是网上看到的一个统计数据。

 图片来源：各阶段修改BUG所需成本_杰瑞26的博客-CSDN博客_bug修复成本