這個問題看似合理，但其實話里預設了：

• 代碼行=工作量
• 代碼行=價值
• 所有的代碼行都是相同的

這些預設都不對。

為什么一個看起來很簡單的修改要花兩天時間才能完成?

• 因為發現這個問題時，對如何重新創建它的描述含糊不清。我花了好幾個小時才弄到一份可靠的復制品。一些開發人員會立即回到報告問題的人那里，要求在調查之前獲得更多信息。我試著用所提供的信息做盡可能多的事情。我知道有些開發人員不喜歡修復 bug，所以他們會盡一切努力擺脫它。聲稱“還不夠”是一個很好的方式，讓人覺得你在盡力幫忙，但卻什么都不用做。我知道報告錯誤可能很難，我對任何這樣做的人表示感謝。我想通過在詢問更多細節之前盡可能多地使用所提供的信息來表示對錯誤報告的贊賞。
• 由于報告的問題與功能有關，我不太熟悉。它所涉及的功能是我很少使用的，也不是我曾經詳細使用過的。這意味著我花了更多的時間去理解如何使用它，以及它如何與有缺陷的軟件相互作用的細微差別。
• 因為我花了時間調查問題的真正原因，而不僅僅是查看問題。如果某些代碼出錯，你可以僅僅嘗試把他掩蓋起來。沒有error，就沒有問題，對吧?不過，對我來說，讓問題看不見和解決問題不一樣。“接受”錯誤很容易導致其他意想不到的副作用。我不想在將來的某個時候不得不面對它們。
• 因為我調查了是否有其他方法來解決相同的問題，而不僅僅是報告的復制步驟。一組復制步驟可以很容易地使錯誤看起來在一個地方，而實際上它可能是更深的。找到問題的確切原因，并查看所有實現原因的方法，可以提供有價值的見解。比如代碼實際是如何使用的，哪些地方可能存在其他可能需要解決的問題，或者它可能顯示代碼中的不一致性，這意味著錯誤是在一個代碼路徑中導致的(或處理的)，而不是在另一個代碼路徑中。
• 因為我花了時間驗證代碼的其他部分是否可能受到類似的影響。如果一個錯誤導致了這個bug，那么同樣的錯誤也可能在代碼庫的其他地方發生。現在是檢查的好時機。
• 因為當我發現了問題的原因后，我就開始尋找最簡單的方法來解決問題，同時將帶來副作用的風險降到最低。我不想要最快的解決辦法。我想要一個不太可能在將來引起混亂或其他問題的修復。
• 由于我對修正進行了徹底的測試，并驗證了它解決了所有受影響的不同代碼路徑的問題。我不想依靠別人來檢驗我所做的是正確的。我不希望在將來發現錯誤，并且當我在心里繼續前進時，不得不回到這段代碼。上下文切換既昂貴又令人沮喪。我希望盡可能避免讓一個專門的測試人員再次查看“相同的”更改。

我不喜歡修bug。一個原因是我感覺他們是以前失敗的結果，另一個原因是我更喜歡做新事情。

還有什么比修bug更難受的呢?

不得不重復修復相同的bug。

花時間確保遇到任何錯誤時都已完全修復，這樣就不需要多次面對、調查、修復和測試。