作者 | Matt Lacey
譯者 | 彎月，責編 | 屠敏
頭圖 | CSDN 下載自東方 IC
出品 | CSDN（ID：CSDNnews）
以下為譯文：
「只加兩行代碼，為什麼用了整整兩天時間？！」
這個問題看似合理，但其背後隱藏著一些可怕的假設：
-
代碼行數=工作量
-
代碼行數=價值
-
所有代碼行都一樣
但這些統統不屬實。
有人花了整整兩天的時間改好了代碼，但為什麼我們回頭去看的時候會覺得這些改動如此簡單？
-
因為問題報告對如何再現的描述非常模糊。
我花了好幾個小時才成功地重現了問題。有些開發人員會立即去找報告問題的人，在獲得更多信息之後再展開調查。而我會盡力使用已提供的信息。我知道有些開發人員不喜歡改bug，因此他們會想法設法逃避這種工作。聲稱信息量不足是及時甩鍋的一個好辦法，看起來你像是在努力幫忙，但又無需做任何工作。我知道報告錯誤非常困難，我非常感謝那些報告錯誤的人。我會儘可能利用已有信息，實在沒辦法再去請求報告錯誤的人提供更多信息，目的是為了表達對他們的感謝。
-
因為報告的問題與某個功能有關，但我不熟悉這個功能。
我很少使用與這個問題相關的功能，而且我並沒有接觸過與該功能相關的具體細節。因此，我花費了很長時間來理解如何使用這個功能，以及這個bug與軟體交互的具體過程。
-
因為我花了很長時間調查引發問題的真正原因，而不僅僅是流於表面。
如果某些代碼拋出了錯誤，則你只需把它包裝在try..catch語句中即可抑制錯誤。沒有錯誤，就沒有問題。對嗎？不好意思，在我看來，把問題藏起來並不等同於解決問題。掩蓋錯誤很容易引發其他意料之外的副作用。我不想留到將來，再與它們打交道。
-
因為我調查了除了問題報告的步驟之外，是否還有其他方法可以再現這個問題。
通過一組再現步驟可以很容易地讓錯誤浮現，但實際上它可能涉及更深層的問題。找到問題的確切原因，並研究解決問題的所有方法，才能提供有價值的見解。比如代碼的實際使用方式，可能其他地方存在有待解決的問題，或者存在代碼不一致，導致某個代碼路徑中引發了錯誤，而其他路徑則不會。
-
因為我花時間驗證了代碼的其他部分是否會受到類似問題的影響。
如果某個錯誤引發了這個bug，那麼代碼庫的其他地方可能也存在相同的錯誤。我可以借這個機會仔細檢查一下。
-
因為如果我找出了問題的根源，那麼就可以尋求最簡單的解決方法，同時引入副作用的風險也很小。
我不希望用最快捷的方法修復問題。我希望修復這個問題之後將來不會引起混亂或引發其他問題。
-
因為我對此次代碼變更進行了徹底的測試，並驗證了它能夠解決所有受影響代碼路徑下的問題。
我不想依靠他人來測試我做的更改是否正確。我不希望以後等到我完全忘記此次更改之後再發現某個bug，迫使我不得不再次回頭看這些代碼。來回切換思維費時費力，又令人沮喪。我不希望讓專職的測試人員再來檢驗同一個更改。
我不喜歡改bug的工作，部分原因是因為這種工作讓人感覺是我之前的失誤造成的。而我不喜歡改bug的另一個原因是，我更喜歡從事新的工作。
問：有什麼是比改bug更糟糕的工作呢？
答：反覆修復同一個bug。
我願意花時間確保每次遇到的bug都會被完全修復，這樣我就無需再面對這個bug，也無需再花時間調查、修復並測試這個bug。
原文：https://www.mrlacey.com/2020/07/youve-only-added-two-lines-why-did-that.html
本文為 CSDN 翻譯，轉載請註明來源出處。