查看原文
其他

你只修改了2行代码,为什么需要两天时间?

Matt Lacey 高可用架构 2020-11-06

“你只修改了2行代码,为什么需要两天?”


这是程序员最常碰到的质问,表面看这是一个非常合理的问题,但它做了一些不合适的假设:


  • 代码行数 = 努力

  • 代码行数 = 价值

  • 每一行代码价值都相同


所幸上面这些断言都不是真的。


一个简单的修复,为什么需要花两天时间?下面列举了一些常见原因。


  • 因为如何重现问题的描述很模糊。程序员可能需要花几个小时才能重现 bug。有些开发人员会立即联系报告 bug 的用户,要求提供更多的信息再进行分析。有些程序员会试着用提供的信息做尽可能多的事情。我知道有些开发者不喜欢修复 bug,所以会不惜一切代价来摆脱困境,声称问题不能重现是一种非常好的逃避方式,它让你看起来很想解决问题,但又不需要真的动手。我知道用户报告 bug 不容易,我也很感谢这样做的用户。我想通过在打扰用户询问更多细节之前,尽量多地使用所提供的信息来表达对报告 bug 用户的感谢。

  • 因为报告的问题与特定功能有关,但程序员不熟悉这块功能。这块代码不是他开发的,以前也比较少接触。如果去修的话,需要花费更长的时间来先了解这块的流程,以及这个问题怎么出现。

  • 因为花费了时间去分析问题的真正原因,而不仅仅是看表面现象。如果一些代码抛出了错误,你可以直接用 try...catch 语句把它包起来,吞下错误。这样错误就不见了,对吧?抱歉,对我来说,把问题掩盖不等于解决问题。"吞下"一个错误,很容易导致其他意想不到的副作用。我不希望在未来某个时间点上不得不来处理它。

  • 因为我分析了是否有其他方法可以重现这个问题,而不仅仅局限于报告提出的重现步骤。某一套重现步骤,容易让错误出现在某个地方,但实际上可能是更深层次的原因导致。找到问题的确切原因,并查看所有到达那里的方法,可以得到更有价值的意见。诸如代码实际是如何使用的,其他地方可能也有需要解决的问题,或者它可能由于代码中的使用不一致,这意味着错误是只在一个代码路径中引起,但不会在另一个出现。

  • 因为我花了时间来验证代码中是否有其他部分可能受到类似的影响。如果一个错误导致了 bug,那么同样的错误也可能在代码库的其他地方发生,现在是检查这个问题的最好时机。

  • 因为当我找到问题的原因时,我会寻找最简单的方法来修复,并将引入副作用的风险降到最低。我不想要最快速的修复方法,我需要一个不会在未来带来混乱或引入其他问题的修复方法。

  • 因为我彻底地测试了这个变更,并验证了受影响的不同代码路径的各种情况。我不想依靠别人来测试我修改的代码是否正确。我不想将来某一天又出现一个 bug,在我已经淡忘这个的时候,还要回到这段代码中来。上下文切换是昂贵的,而且很糟心。让一个专门的测试人员不得不再次查看同一个问题的变更,是我想尽可能避免的。


我不喜欢 bug,部分原因是会让觉得是我之前的代码质量不好造成的。我不喜欢修 bug,另一个原因是我更愿意去研究新的东西。


有什么比修 bug 更糟心的事情是反复修复同一个 bug。


我花了更长时间,是需要确保任何一次遇到的 bug 都被完全修复,这样就不需要再次去面对这个 bug、再次分析原因、修复和测试。


英文原文:

https://www.mrlacey.com/2020/07/youve-only-added-two-lines-why-did-that.html


活动预告



GIAC 全球互联网架构大会 2020 将于 8 月 14 - 15 日在深圳举行,本届 GIAC 议题共设置有 24 个专题,覆盖各类架构热点领域,每个主题由业内知名架构师、技术负责人等专家担任出品人,负责议题选取和质量把控。本届 GIAC 专场包含 CloudNative云原生(出品人:敖小剑)以及 高可用架构(出品人:一乐) 等专题,对大会感兴趣的同学,点击阅读原文查看 GIAC 详细日程。


参考阅读:


本文由高可用架构翻译,技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。


高可用架构
改变互联网的构建方式

长按二维码 关注「高可用架构」公众号

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存