[[334710]]

“你只修改了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

 本文轉載自微信公眾號「 高可用架構」，可以通過以下二維碼關注。轉載本文請聯系 高可用架構公眾號。