公司网站维护好做吗,wordpress哪个版本,重庆网站开发解决方案,做个企业网站大概多少费用大家好#xff0c;我是Z哥。“这个 bug 的问题不是很明显吗#xff1f;怎么这么久才搞定#xff1f;”“就改一行代码#xff0c;你怎么弄了这么久#xff1f;”我想上面的言语几乎每个程序员都听到过。特别是面对那些“稍懂技术”的同事的时候。我觉得这篇文章特别适合你… 大家好我是Z哥。“这个 bug 的问题不是很明显吗怎么这么久才搞定”“就改一行代码你怎么弄了这么久”我想上面的言语几乎每个程序员都听到过。特别是面对那些“稍懂技术”的同事的时候。我觉得这篇文章特别适合你收藏一下为什么呢。首先当你再次遇到这种情况的时候翻开这篇文章可以帮助你降降火让你冷静下来。其次还能时不时地在朋友圈转发给你的“稍懂技术”的同事看看给他一些暗示哈哈。很多人之所以会产生前面提到的这种误区是因为他们潜意识里将工作量与代码量挂钩了。他们脑海里的程序员像电视电影的中的那些黑客那样palapala 地敲击键盘疯狂地 coding看上去都不带思考的然后软件就写成了。我们程序员当然清楚事情并不是这样。不管是实现一个新功能还是修复一个线上 bug 我们都不可能直接上手 coding因为我们不知道代码应该写在哪怎么写。/01  实际修 bug 的过程是怎样的/就以修复 bug 为例常规的处理流程是这样的。确定 bug 相关的环境信息。梳理 bug 所在的整条业务链路。分析 bug 在链路中的哪个环节产生。调整代码修复问题。其中的每一个环节都存在着增加时间的因素我们来一个个展开。/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 个环节都存在着额外花费时间的事情。确定 bug 相关的环境信息。梳理 bug 所在的整条业务链路。分析 bug 在链路中的哪个环节产生。调整代码修复问题。所以如果以后谁还说你为什么修 bug 那么慢把这篇文章发给他。你说不出口的话我替你说了。不过后果自负哦其实大家都不喜欢修 bug 特别是在低质量的代码中反复修复同一类型的 bug 。但是现实中好像也有不少的人嘴上说着这样但自己却总是在写这些低质量的代码欢迎分享你与 bug 之间的精彩故事给我推荐阅读我是如何保持长期写作的被同事嘲笑说技术方案没深度原创不易如果你觉得这篇文章还不错就「点赞」或者「在看」一下吧鼓励我的创作 也可以分享我的公众号名片给有需要的朋友们。如果你有关于软件架构、分布式系统、产品、运营的困惑可以试试点击「阅读原文」