这么简单的bug,你改了2天?

这里是Z哥的个人公众号

每周五11:45 按时送达

当然了,也会时不时加个餐~

我的第「196」篇原创敬上

 

 

大家好,我是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 之间的精彩故事给我~

 



原创文章,转载请注明本文链接: https://zacharyfan.com/archives/1466.html

关于作者:张帆(Zachary,个人微信号:Zachary-ZF)。坚持用心打磨每一篇高质量原创。欢迎扫描二维码~

微信公众号

定期发表原创内容:架构设计丨分布式系统丨产品丨运营丨一些思考。

如果你是初级程序员,想提升但不知道如何下手。又或者做程序员多年,陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」,回复「技术」,送你一份我长期收集和整理的思维导图。

如果你是运营,面对不断变化的市场束手无策。又或者想了解主流的运营策略,以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」,回复「运营」,送你一份我长期收集和整理的思维导图。

Leave a Reply

发表评论

电子邮件地址不会被公开。 必填项已用*标注

ZacharyFan.com © 2019 | WordPress Theme: BlogGem by TwoPoints.