"你只修改了2行代码，为什么花了两天时间？"这是程序员遇到的最常见的问题。从表面上看，这是一个非常合理的问题，但它做出了一些不恰当的假设：代码行数=努力代码行数=价值每一行代码都具有相同的价值幸运的是，以上断言都不成立。为什么一个简单的修复需要两天时间？下面列出了一些常见的原因。因为关于如何重现问题的描述是模糊的。程序员可能需要数小时才能重现错误。一些开发人员会立即联系报告错误的用户，并在分析之前询问更多信息。一些程序员尝试尽可能多地使用提供的信息。我知道有些开发人员不喜欢修复错误，会不惜一切代价摆脱困境，声称问题无法重现是一种很好的逃避方式，这让你看起来很想解决问题问题，但你不需要真正去做。我知道用户报告错误并不容易，我感谢这样做的用户。我想对报告错误的用户说声谢谢，在打扰他们询问更多细节之前，他们尝试使用尽可能多的信息。因为报告的问题是针对某个特定的函数，但是程序员对这块函数并不熟悉。这段代码不是他开发的，之前接触的也很少。如果去修的话，要了解这块的过程，这个问题是怎么产生的，就需要更长的时间。因为分析问题的真正原因需要时间，不能只看表面。如果某些代码抛出错误，您可以简单地将其包装在try...catch语句中并吞下错误。这样错误就消失了，对吧？对不起，但对我来说，掩盖问题不等于解决问题。“吞下”一个错误很容易导致其他意想不到的副作用。我不想在将来的某个时候处理它。因为我分析了是否有其他方法可以重现这个问题，而不仅仅局限于报告中提出的重现步骤。某组可复现的步骤，很容易在某个地方出现错误，但实际上可能是更深层次的原因造成的。找到问题的确切原因，并查看解决问题的所有方法，可能是一个更有价值的意见。就像代码的实际使用方式一样，其他地方可能存在问题需要解决，或者可能是由于代码中的使用不一致，这意味着错误仅在一个代码路径中引起，而不是在另一个代码路径中引起。因为我花时间验证代码的其他部分是否可能受到类似的影响。如果错误导致了错误，则代码库中的其他地方可能会出现相同的错误，现在是检查该错误的最佳时机。因为当我找到问题的原因时，我会寻找最简单的方法来修复它并尽量减少引入副作用的风险。我不想要最快的修复，我需要一个不会造成混淆或在未来引入其他问题的修复。因为我彻底测试了此更改并验证了受影响的不同代码路径的各种情况。我不想依赖别人来测试我修改后的代码是否正确。我不想在将来出现另一个错误并在我忘记它时回到这段代码。上下文切换很昂贵，而且很糟糕。让专门的测试人员必须再次审查相同的有问题的更改是我想尽可能避免的事情。我不喜欢修复错误，部分原因是这会让人们认为我以前的代码质量很差。我不喜欢修复错误的另一个原因是我更喜欢研究新事物。什么比修复错误更糟糕？一遍又一遍地修复同一个错误。我花了更长的时间来确保我遇到的任何错误都被完全修复，这样我就不必再次面对错误，分析原因，修复和测试。英文原文：https://www.mrlacey.com/2020/07/youve-only-added-two-lines-why-did-that.html本文转载自微信公众号《高可用架构》，可通过关注下方二维码获取。转载本文请联系高可用架构公众号。
