你只修改了2行代碼，爲何須要兩天時間？

時間 2021-05-19

標籤 java 程序員算法設計模式 ide 測試 .net 設計 blog 遞歸欄目 Java 简体版

原文原文鏈接

「你只修改了2行代碼，爲何須要兩天？」java

這是程序員最常碰到的質問，表面看這是一個很是合理的問題，但它作了一些不合適的假設：程序員

代碼行數 = 努力
代碼行數 = 價值
每一行代碼價值都相同

所幸上面這些斷言都不是真的。算法

一個簡單的修復，爲何須要花兩天時間？下面列舉了一些常見緣由。設計模式

由於如何重現問題的描述很模糊。程序員可能須要花幾個小時才能重現 bug。有些開發人員會當即聯繫報告 bug 的用戶，要求提供更多的信息再進行分析。有些程序員會試着用提供的信息作儘量多的事情。我知道有些開發者不喜歡修復 bug，因此會不惜一切代價來擺脫困境，聲稱問題不能重現是一種很是好的逃避方式，它讓你看起來很想解決問題，但又不須要真的動手。我知道用戶報告 bug 不容易，我也很感謝這樣作的用戶。我想經過在打擾用戶詢問更多細節以前，儘可能多地使用所提供的信息來表達對報告 bug 用戶的感謝。
由於報告的問題與特定功能有關，但程序員不熟悉這塊功能。這塊代碼不是他開發的，之前也比較少接觸。若是去修的話，須要花費更長的時間來先了解這塊的流程，以及這個問題怎麼出現。
由於花費了時間去分析問題的真正緣由，而不只僅是看表面現象。若是一些代碼拋出了錯誤，你能夠直接用 try...catch 語句把它包起來，吞下錯誤。這樣錯誤就不見了，對吧？抱歉，對我來講，把問題掩蓋不等於解決問題。"吞下"一個錯誤，很容易致使其餘意想不到的反作用。我不但願在將來某個時間點上不得不來處理它。
由於我分析了是否有其餘方法能夠重現這個問題，而不只僅侷限於報告提出的重現步驟。某一套重現步驟，容易讓錯誤出如今某個地方，但實際上多是更深層次的緣由致使。找到問題的確切緣由，並查看全部到達那裏的方法，能夠獲得更有價值的意見。諸如代碼實際是如何使用的，其餘地方可能也有須要解決的問題，或者它可能因爲代碼中的使用不一致，這意味着錯誤是隻在一個代碼路徑中引發，但不會在另外一個出現。
由於我花了時間來驗證代碼中是否有其餘部分可能受到相似的影響。若是一個錯誤致使了 bug，那麼一樣的錯誤也可能在代碼庫的其餘地方發生，如今是檢查這個問題的最好時機。
由於當我找到問題的緣由時，我會尋找最簡單的方法來修復，並將引入反作用的風險降到最低。我不想要最快速的修復方法，我須要一個不會在將來帶來混亂或引入其餘問題的修復方法。
由於我完全地測試了這個變動，並驗證了受影響的不一樣代碼路徑的各類狀況。我不想依靠別人來測試我修改的代碼是否正確。我不想未來某一天又出現一個 bug，在我已經淡忘這個的時候，還要回到這段代碼中來。上下文切換是昂貴的，並且很糟心。讓一個專門的測試人員不得再也不次查看同一個問題的變動，是我想盡量避免的。