程式碼之道

第3部分 (第1/4頁)

。如果透過這種方式沒有發現Bug，他們就會把視線轉到正在被分診討論的那些Bug上，挑一個有趣一點的，然後開始研究它。在你知道之前，他們可能已經有了一個修復方案，並且正伺機悄悄地把程式碼簽入進去呢……這就是搶修Bug！一個有自尊的開發者不應該做這樣的事情。

作者注：在軟體工程中，Bug通常是指程式碼中的錯誤。然而，微軟內部使用“Bug”這個詞泛指跟產品相關的所有增加、刪除或者修改。但大家對外一般稱這些為“工作條款”，其中有一些也可能是程式碼錯誤。我更喜歡“工作條款”的說法，這樣就能把那些真正的Bug區分出來。

誰知道分診團隊是否會決定修復那個Bug呢？誰知道那個Bug是否被正確地修復了，並且也不會引起相關的另一個更大的或者小一點的Bug呢？對於潛在的重大問題投入一點調研是可以的，但絕對不要搶先去修復！

？ 修復尚未報出來的Bug。現在有一個Bug透過了分診，你正在進行修復。這時你注意到，在你修改的程式碼附近有其他更多的Bug（通常這些Bug是由以前的修復引起的）。但不知怎麼搞的，這些Bug還沒有被人報出來。你看到了這些程式碼，而其中的錯誤也盡收你眼底。為什麼不一起把它們都修復了呢？喂！就此打住！！！

開發團隊透過程式碼複審來避免這種可怕的事情。在“可信計算”時代，團隊應該在整個專案週期內複審每一次程式碼簽入。當團隊處於“禁閉”狀態時，要保證有3雙眼睛（即程式碼改動者本人和另外兩個開發者）同時審查每一次的程式碼改動。至於開發人員在修復一個Bug時發現的其他Bug，則要透過如下方式來跟蹤：先把它報出來、登記到Bug資料庫中，然後再分診……

作者注：《凱文與霍布斯》連環漫畫系列中有這麼一個故事：凱文對一隻蒼蠅慈悲為懷，開啟前門讓它飛出去。結果呢？這隻蒼蠅非但沒有飛出去，反而另外3只蒼蠅飛了進來。這就是為什麼你必須在專案逼近尾聲時，要對每一個Bug進行研究和分診的原因了。我的團隊曾經在我們的產品釋出前一個月的時候改變了一個引數的值，結果一週之後，全公司的測試人員都發現：只要開啟CD托盤，所有的應用程式都會停止響應。最後，我們往回追蹤到那個看起來無關緊要的引數，並把那個改動撤銷了才解決問題。這種事情真實地發生在我們的周圍，只是你未必知道而已。　。。

寶寶做了件極壞的事情（2）

？ 修復標為“延期”的Bug。大家知道，被標為“延期”的Bug在產品釋出給製造商（RTM，Release　To　Manufacturing）之前是不能去修復的。那麼，是不是應該在計劃下一版產品的時候去修復它們呢？不對！當初在專案的進行過程中，產品的相關團隊對“哪些Bug對我們的客戶影響最大，因此必須在釋出之前修復”作了判斷，但這種判斷在產品沒有真正釋出之前是無法驗證的。當產品釋出之後，你就沒必要再去猜了。“產品支援服務”（PSS，Product　Support　Services）、Watson和“微軟諮詢服務”（MCS，Microsoft　Consulting　Services）會告訴你的，而且它們非常坦誠。那些標為“延期”的Bug只具有參考價值，用於理解為什麼這些Bug當初沒有要求去修復。注意，你不要再一次去猜測已經真實存在的客戶。你要做的是，關注使用者反饋，修復真正影響使用者的那些Bug。

？ 重寫“醜陋”的程式碼。開發人員討厭“醜陋”的程式碼。這些程式碼常常麻煩不斷，可讀性差，難以維護。因此，當開發人員手頭有空的時候，他們經常自言自語：“哈，我手頭沒有規範書，因此不能開發新的東西。我為什麼不趁此機會重寫那些討厭的醜陋程式碼呢？”他們知道，如果給第二次機會的話，他們能夠做得更好。他們也的確可以做到。他們可以在第二次的時候，重寫出漂亮得多、清晰得多的程式碼，而且比第一次寫的時候少了很多Bug。

令人遺憾的是，重寫的程式碼實際上將比當前的醜陋程式碼帶來更多的Bug。因為當前的醜陋程式碼是在第一次編寫的基礎上，經過了幾個月甚至是幾年的測試和修復之後才達到的質量水準。

有時候重寫是必要的。重寫可以提高程式碼的效能、擴充套件性、可靠性、安全性、或者對於新技術的適應能力。在這些情況下，應該把重寫當作一個功能來對待；像處理其他功能一樣，寫一份規範書，然後為它制定時間表。否則，不要做