測試、Debug、軟件改進（與獵手的談話錄）

今天晚上獵手在MSN上問我知不知道AQTime，我說我不知道。后來才知道這是一個測試工具。

獵手跟我說，準備學一學軟件測試，因為我們公司的軟件真是ＢＵＧ一大把，隨便怎么玩都能玩出錯誤來～～～。

我對他說，你搞錯了，你這種情況，需要的不是測試，而是Debug。測試部門的職責，是經過系統的科學的嚴格的測試之后，告訴你軟件中有哪些問題，這些問題產生的條件、環境甚至可能的原因是什么。但測試部門沒有責任告訴你這個問題應該如何修改，組建一個測試部門并不能減少現有系統中的bug（相反可能因為測試更嚴格，有更多的bug會出現）?，F在獵手的情況是，不需要測試部門，這些問題已經暴露出來了，那么還要等測試部門干什么呢？趕緊debug才是正事。當然，如果有測試部門的話，也許測試部門能更準確的告訴你問題出現的時機、條件、環境以及（如果測試部門足夠好的話），還能告訴你可能的原因，可以減輕你debug的難度。

于是獵手就問我，那你有啥好建議么，偶們的代碼ＢＵＧ太多。而且更麻煩的是程序還不是自己寫的，修改難度很大，有牽一發而動全身的郁悶～～。
其實，獵手的問題是現有軟件開發中的典型場景。當然我也碰到過類似的情況：軟件bug一堆，代碼一塌糊涂，日程排得很緊，自己對這個還不熟。一般來說，看到這種代碼首先想到的就是“還不如重寫一套呢”。但是這個想法是不對的。因為一個軟件產品，只要它是一個產品，哪怕它的核心功能再簡單，整個軟件產品也是復雜的，因為除了核心功能之外，一個產品往往附帶了大量周邊需求，而就是這些周邊需求，導致了一個看似簡單的軟件系統復雜化。我們大多數程序員都有一種本領：透過現象看本質。這個本領其實是很不錯的，在很多時候都能抓住要領，但是，在實際軟件開發時，這種本領有時會帶來不小的誤導：只看到軟件的核心功能而忽視了其復雜的周邊功能，導致對結果的盲目樂觀。其實，很多軟件的核心功能實現可能只需要很短的時間（甚至一兩天就可以了），但周邊功能需要占用大量的時間。而且很多周邊功能的需求會反過來破壞原本和諧的核心設計，使得原先漂亮的設計迅速變壞，代碼迅速變亂，結果實際完成的時間將是你預計時間的好幾倍甚至更多，而實際完成的效果并不一定比原先那個“bug多多”的版本要好，因為原先的代碼是經過很多需求、例外、錯誤之后慢慢修補和積累起來的，有些情況你未必了解，在你的代碼中也就未必能考慮進去，從而導致原先好不容易被修補好的問題在你的“新版本”中再次重現。

以我個人的經驗來說，碰到這類情況，首先就是對已有的代碼給予足夠的尊重，無論它多么亂多么難看多么不順眼，只要它能工作，就讓它在那里工作。如果出現bug，需要修改了，再來修改。修改的時候，要注意控制范圍：找到bug發生的一個足夠小的范圍，然后盡可能的把這個部分獨立出來——所謂獨立的意思，就是找到不影響其他部分的相對單獨的一個部分，例如一個函數、一個類、一個線程，或者是其他的相對獨立的單元?！缓蟊３诌@個單元的接口不變（無論這個接口在你看來有多不合理，不要動它），將其內部整理到你滿意的程度，注意小步進行，經常運行或調試，保證除了這個bug之外的其他部分不變。這個過程是迭代的，下一次再碰到問題的時候，你就可以把你已經修改過的部分考慮在內進一步改進——因為你改過它，已經對它的代碼熟悉了。這時，如果碰到你修改過的這個單元接口不合理，那么就改掉它，但同時要保證外在的部分盡可能的不受影響。這種小步驟的、逐步的、迭代改動，一方面將你確實需要修改的部分做了充分的改進，到達你所滿意的程度；另一方面最大限度的保證了程序的原樣性。對于獵手問的另外一種情況那要是開發新軟件，你有什么好的建議伐（如何對大限度的減少ＢＵＧ），道理也是類似的，首先保證新加的部分足夠好，然后讓軟件能工作，然后當碰到bug的時候，按上面的方法改進。

當然，這也是一種半理想化的情況，因為先前的代碼很有可能沒有那么清晰（不過幸運的是我遇到過的大部分情況是比較清晰的——畢竟連面向過程的模塊化都不遵守的程序現在已經不常見了），比如復雜的線程，或碰到某些程序包含關鍵的全局變量，這時沒有那么容易做到在一處改動而不影響全局。這時我們需要做一點技巧性的工作——我比較常用的一種做法是對全局變量進行復制再復制——先將全局變量復制給一個局部變量進行局部處理，處理完成之后再復制回全局變量。這個做法會降低效率，但是在一定程度上它可以減少耦合度，讓局部的改動變成可能。如果涉及線程操作，一般常見的思路是對線程代碼進行串行化處理——也就是減少不必要的并發操作，降低復雜度，然后在串行的內部進行改進——最后再優化，那是很后面的事情了。

其實代碼改進的方法有很多，但是我相信：做盡量小的改動，盡可能維持現有的代碼正常運作，這是一個比較有幫助的總體思路。當然，在隔離范圍之內，改動還是徹底一點比較好，運用重構和必要的測試保證（如果能寫單元測試最好，如果不能寫，普通測試也行），將代碼修改到最合自己的口味——希望我自己的口味比較正常:) ，這樣對下一步的動作是很有好處的。

原文轉自：http://www.anti-gravitydesign.com