當你的系統依賴於某個bug...

標題粗略看是有點違反常識的，bug一般是指某些代碼存在問題致使系統沒有按照指望方式工做，應該是須要儘量被修復的，這樣系統纔會正常工做。可是，開發實踐中會發如今某些狀況下，原本功能沒有問題，在你信心滿滿的修復了某個bug以後，某項功能反倒變成有問題了。這是怎麼回事呢？在bug fix自己沒有問題的狀況，最可能的緣由是你的某些上層模塊依賴於這個被修復bug的行爲，當bug修復以後，這個被依賴的bug行爲不存在了，因此致使這些上層模塊不工做。下面舉一個來自實踐中的真實的案例。

有一個函數isdigitstring，它負責檢查輸入字符串是不是數字字符串。咱們在對這個函數作單元測試的時候，發現它存在一個明顯的bug。若是輸入字符串爲空，這個函數會判斷這個空字符串爲數字字符串，很明顯這個判斷是不正確的。在單元測試中發現這種bug是很是鼓舞人心的，並且解決這個bug是很是容易的，只須要在函數裏面增長一個空字符串的判斷處理便可。像預料的那樣，咱們接下來應該是當即修復這個bug, 而後自豪的宣稱代碼質量又獲得了極大的改善。

意外的是某個資深的軟件工程師對此提出一個奇怪而強烈的意見，這個bug如今不能被修復！什麼？這是一個毫無疑問的低級錯誤，修復它看起來徹底不存在side effect, 由於它看起來是如此的簡單和直接。做爲合格的軟件工程師來講，咱們的職責難道不是儘量的發現bug和修復bug? 這位提出意見的工程師隨即解釋了他的理由，原來這個bug在不久前已經被發現，可是同時也發現存在這個bug的函數在代碼中被大量使用，代碼裏全部的現有調用者都已經假定空字符串就是一個數字字符串！因此，若是咱們修復了這個bug, 全部調用這個函數的地方都會有問題（由於它們都依賴於這個錯誤的假定）。這個項目已經臨近結束，咱們能夠修復isdigitstring的bug, 可是咱們基本上已經不能負擔修改此函數的caller代碼的時間成本。也就是說，咱們暫時最好的決定竟然是不修復這個bug。很明顯在新的項目代碼裏，咱們必然會修復這個bug和修復全部的caller代碼（再也不依賴於錯誤的假定）。可是對一個低級錯誤bug的解決方案是"won't fix", 的確會令一個熱情的軟件工程師心裏感受到挫敗。

那麼經驗教訓是什麼呢？在項目早期就必須開始單元測試，不然在後期修復一個簡單bug的成本可能都會變得很是巨大；低層&公用的代碼的修復成本一般會比較高；總體系統工做正常並不必定表示局部模塊不存在bug。