軟體開發高手：十年磨一劍 (轉)

軟體開發高手：十年磨一劍 (轉)[@more@]

要成為武林高手，需要長時間的勤學苦練。要成為開發高手，又需要多長時間呢？《Modern C++ Design》的作者Andrei Alexandrescu認為：一個人有可能在２０幾歲就成為高手，但要成為設計高手卻需要熬到３５歲左右。以２３歲大學畢業計算，要經過漫長的１２年時間。

 :namespace prefix = o ns = "urn:schemas--com::office" />

以我個人為例（我尚不敢自認是設計高手），２２歲大學畢業後，在某研究所用８０８６語言寫一些小規模的，頗覺得心應手。凡是能用流傳圖表示的問題，都似乎不在話下。工作中，與同事共同切磋結構化，並能有意識地用於實踐中。

 

三年後，承接一個縱向課題：在上開發一個互動式排版。用Windows SDK開發。興奮之餘，自然想起用結構化方法進行設計：把整個系統當成一個黑盒子（black box），輸出當然是排版結果，不管是什麼格式，輸入是···。我卡住了。難道操作是輸入嗎？但使用者操作有那麼多，怎麼表示呢？系統的資料流圖該怎麼畫？資料字典該怎麼寫？和同事討論n次後，仍不得其解。懊喪之餘，先模仿Quark Express搭個介面吧。然後研究排版演算法。程式結構經過至少三次大規模修改，終於能排出一些版式，並在兩年後透過了鑑定（鑑定後當然是將其束之高閣）。我從中體會到結構化開發方法不適合開發互動式系統。在開發初期，你不太可能正確地畫出資料流圖，而結構化設計方法完全依賴資料流圖。資料流圖發生改變，整個程式結構就要隨之改變。

 

後來，加入一家合資公司，擔任開發組長，有五、六個組員。這時我已讀過了邵維忠等譯的《面向的分析》、楊芙清等編譯的《物件導向的設計》和《Code Complete》中譯本。對物件導向的程式設計雖有所瞭解但仍是一知半解。

 

首先，我們用MS1.5開發一個圖形編輯軟體。我用紙畫了20幾張物件圖，與同事討論透過後，開始程式設計。有人負責資料模型，有人負責使用者介面，有人負責圖形顯示。幾個月後，老闆已可向潛在使用者進行展示，反應良好。老闆和開發人員都被一種興奮的心情籠罩著。我們不斷地加新功能，老闆不時地到展覽會上做演示。功能加齊了，開始讓潛在使用者試用。老闆和我們都鬆了一口氣：就剩下改錯了，我們們是兵來將擋、水來土屯，沒什麼可怕的。錯誤報告來了。我們信心滿滿地開始查錯改錯。有些錯誤很快地被改掉了。但最後我們發現錯誤源源不斷。改了一個錯誤有可能引起別的錯誤。軟體永遠達不到能用的地步。最後，時機被錯過。該軟體不得不被砍掉。懊喪之餘，我們做了反省。大家都認為應儘早改錯。同時模模糊糊地覺得資料模型和使用者介面的程式一定要嚴格分開，否則程式極難修改。

 

後來，我們又開發一個類似Adobe Acrobat 的PDF兼編輯器（當時Acrobat Exchange還不能顯示中、日、韓文）。這時，老闆帶來一些過期的《C/C++ Users’ Journal》《Dr. Dobbs’ Journal》雜誌。從書評中，我被幾本書吸引住了。一本是James Rumbough等著的《-Oriented Modeling and Design》，一本是現在大名鼎鼎的《Design Patterns》，還有就是tt Meyers著的《Effective C++》和《More Effective C++》。我勸說老闆買了這幾本書，並攛掇他買了一個CASE（輔助軟體工程）工具： OMT。

 

仔細研讀這幾本書後，頗有頓開茅塞之感。最大的收穫在於瞭解到降低類之間耦合度的重要性。一個類的實現細節發生變化，不應該影響使用該類的其它類的內部實現。更妙的是有不少Design Pattern能馬上用到我們的軟體中。

 

我用Select OMT軟體畫了一些高層的類圖、狀態圖和資料流圖等，並讓同事們審查。同事們都覺得透過這些圖對軟體的總體設計有了更好的把握。在寫程式的過程中，我們不斷調整程式結構以儘可能減小類之間的耦合度。老闆很早就安排了專職測試人員。發現問題，馬上修改。一年後，我們的軟體終於透過了使用者的試用，賣出去了。當時，我可說是信心滿滿。

 

此後，我做了一年半多程式設計。發現還是對系統開發更感興趣。於是加入了Quark軟體公司，開發一個基於的系統。這是我第一次參與異地開發，也是第一次大規模使用STL。我驚歎於STL設計之妙，同時也對自己的信心打了折扣。此後，我閱讀了Martin Fowler著的《UML Distilled》、Bertrand Meyer著的《Object Oriented Software Construction》等書籍。並開始使用Rational Rose。Quark公司的技術文件管理、設計複查、程式碼複查、質量管理以及德國人（Quark公司德國分公司）嚴謹的工作態度都給我留下了深刻印象。

 

專案組下分開發組和測試組。開發組中有一個４到５人組成的設計小組負責軟體總體設計，其中一個人負責技術文件，確保文件反映最新的設計。定期進行設計複查。複查時，專案組成員全部參加，並可提出問題或建議。得出結論後，馬上付諸實施。

 

開發組下又設若干小組。小組內定期進行程式碼複查。由組長選出每個組員的原始檔，交其他組員複查，儘量挑出所有的毛病。如果程式碼太次，要打回從新寫過。程式碼複查既能保證軟體質量，又是大家學習的一個機會。

 

一年半後，我離開Quark，加盟，參與PowerBuilder的維護和新版本的開發。這是我第一次參與軟體維護，令我認識到軟體維護的重要性，認識到編寫可維護的程式碼是軟體開發的一個重要課題。Sybase系統化的質量跟蹤系統和使用者支援系統讓我獲益匪淺。在此期間，我閱讀了《Large-scale Software Development in C++》、Martin Fowler著的《Refectoring》、Andrei Alexandrescu著的《Modern C++ Design》，Herb Sutter著的《Exceptional C++》和《More exceptional C++》，以及Kent Beck著的《Extreme Programming Explained》等書籍。對軟體開發與維護有了進一步瞭解，但同時也更認識到軟體開發之難。

 

回想十幾年蹣跚走過的路，好像也略有所悟。試總結出以供參考：

1）  要熟練掌握至少一種程式語言。我覺得最好是C++。掌握了C++，學習其它語言如或等並非難事，因為各種物件導向的程式語言儘管在語法上可能有很大區別，在語義上卻大同小異。

2）  不要寄希望於一次就把軟體設計好。在開發初期，要儘量用最簡單的設計實現最基本的功能，以使你的軟體儘早地能實際執行，不要過於拘泥於細節。這樣你才能儘早得到反饋，才能更直觀更全面地理解你所面對的問題。你所關注的重點應依次是Make it work, make it right, make it fast。

3）  軟體結構要分塊分層。低層模組不要依賴於上層模組。一個類、一個介面或一個都應只做一件事。沒有本質聯絡的類或介面就不應有耦合關係。舉例而言，要用MVC（Model View Controller）Design Pattern切斷使用者介面與資料模型之間的直接關聯。

4）  軟體設計的主要工作是給類分配責任（responsibilities）。儘量不要把類設計成控制者（controller），而要設計成協調者（coordinator）。控制者凡事自己做，協調者讓別人做。控制者的邏輯往往很複雜，難於維護；協調者邏輯簡單，易於維護。要站在類的使用者角度設計類的外部行為。要講究一點軟體美學，即簡單、清晰、一致、平衡等。

5）  瞭解並運用UML、Design Patterns、Unit Test、Design by Contract等。

6）  使用程式碼管理系統和質量跟蹤系統。

7）  瞭解各種軟體開發過程控制方法，並找出適合你的方法。

8）  閱讀經典書籍，研讀經典程式碼，訂閱雜誌，與同行切磋。

 

在這行越久越覺得軟體開發難。軟體開發歷史還很短，才50年，還不是一門系統化的學科。有些人甚至認為軟體設計與程式設計是一門藝術。但軟體藝術大師還太少，而且我們很難直接欣賞到他們的傑作，除非所有的設計文件和程式碼都公開。軟體更容易藏汙納垢。一個使用者介面很漂亮的軟體，內部設計和程式碼卻很可能臭不可聞。一個地板傾斜、牆壁裂縫、屋頂漏水的房子沒有人會買。一個設計很爛的軟體卻可能賣得不錯。但這樣的軟體能撐多久呢？

 

軟體設計與程式設計已經很難，而這僅僅是軟體開發的一個方面，軟體開發過程控制也很難，也許更難。成為軟體開發高手要走一條漫長的路，何日才能仗劍走天涯？