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

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

這些預設都不對。

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

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

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

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

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

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