明明只是增加了兩行代碼，為什么卻花了整整兩天的時間？
這個問題看似合理，但其背后隱藏著一些可怕的假設(shè)：
- 代碼行數(shù)=工作量
- 代碼行數(shù)=價值
- 所有代碼行都一樣
但這些統(tǒng)統(tǒng)不屬實。
有人花了整整兩天的時間改好了代碼，但為什么我們回頭去看的時候會覺得這些改動如此簡單？
（推薦教程：python教程）
因為問題報告對如何再現(xiàn)的描述非常模糊。
我花了好幾個小時才成功地重現(xiàn)了問題。有些開發(fā)人員會立即去找報告問題的人，在獲得更多信息之后再展開調(diào)查。而我會盡力使用已提供的信息。我知道有些開發(fā)人員不喜歡改bug，因此他們會想法設(shè)法逃避這種工作。聲稱信息量不足是及時甩鍋的一個好辦法，看起來你像是在努力幫忙，但又無需做任何工作。我知道報告錯誤非常困難，我非常感謝那些報告錯誤的人。我會盡可能利用已有信息，實在沒辦法再去請求報告錯誤的人提供更多信息，目的是為了表達(dá)對他們的感謝。
因為報告的問題與某個功能有關(guān)，但我不熟悉這個功能。
我很少使用與這個問題相關(guān)的功能，而且我并沒有接觸過與該功能相關(guān)的具體細(xì)節(jié)。因此，我花費了很長時間來理解如何使用這個功能，以及這個bug與軟件交互的具體過程。
因為我花了很長時間調(diào)查引發(fā)問題的真正原因，而不僅僅是流于表面。
如果某些代碼拋出了錯誤，則你只需把它包裝在try..catch語句中即可抑制錯誤。沒有錯誤，就沒有問題。對嗎？不好意思，在我看來，把問題藏起來并不等同于解決問題。掩蓋錯誤很容易引發(fā)其他意料之外的副作用。我不想留到將來，再與它們打交道。
因為我調(diào)查了除了問題報告的步驟之外，是否還有其他方法可以再現(xiàn)這個問題。
通過一組再現(xiàn)步驟可以很容易地讓錯誤浮現(xiàn)，但實際上它可能涉及更深層的問題。找到問題的確切原因，并研究解決問題的所有方法，才能提供有價值的見解。比如代碼的實際使用方式，可能其他地方存在有待解決的問題，或者存在代碼不一致，導(dǎo)致某個代碼路徑中引發(fā)了錯誤，而其他路徑則不會。
因為我花時間驗證了代碼的其他部分是否會受到類似問題的影響。
如果某個錯誤引發(fā)了這個bug，那么代碼庫的其他地方可能也存在相同的錯誤。我可以借這個機會仔細(xì)檢查一下。
（推薦課程：JavaScript教程）
因為如果我找出了問題的根源，那么就可以尋求最簡單的解決方法，同時引入副作用的風(fēng)險也很小。
我不希望用最快捷的方法修復(fù)問題。我希望修復(fù)這個問題之后將來不會引起混亂或引發(fā)其他問題。
因為我對此次代碼變更進(jìn)行了徹底的測試，并驗證了它能夠解決所有受影響代碼路徑下的問題。
我不想依靠他人來測試我做的更改是否正確。我不希望以后等到我完全忘記此次更改之后再發(fā)現(xiàn)某個bug，迫使我不得不再次回頭看這些代碼。來回切換思維費時費力，又令人沮喪。我不希望讓專職的測試人員再來檢驗同一個更改。
我不喜歡改bug的工作，部分原因是因為這種工作讓人感覺是我之前的失誤造成的。而我不喜歡改bug的另一個原因是，我更喜歡從事新的工作。
問：有什么是比改bug更糟糕的工作呢？ 答：反復(fù)修復(fù)同一個bug。
我愿意花時間確保每次遇到的bug都會被完全修復(fù)，這樣我就無需再面對這個bug，也無需再花時間調(diào)查、修復(fù)并測試這個bug。
以上就是關(guān)于為什么有時候明明只增加了一點點代碼，卻花費了好幾天時間的相關(guān)介紹了，希望對大家有所幫助。
原文：www.mrlacey.com/2020/07/youve-only-added-two-lines-why-did-that.html
參考來源：blog.csdn.net/csdnnews/article/details/107903206
