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

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

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

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

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

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

　　1）要熟練掌握至少一種編程語言。我覺得最好是C++。掌握了C++，學習其它語言如Java或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年，還不是一門系統化的學科。有些人甚至認為軟件設計與編程是一門藝術。但軟件藝術大師還太少，而且我們很難直接欣賞到他們的杰作，除非所有的設計文檔和代碼都公開。軟件更容易藏污納垢。一個用戶界面很漂亮的軟件，內部設計和代碼卻很可能臭不可聞。一個地板傾斜、墻壁裂縫、屋頂漏水的房子沒有人會買。一個設計很爛的軟件卻可能賣得不錯。但這樣的軟件能撐多久呢？ 

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

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

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

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

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

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

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

　　一年半后，我離開Quark，加盟Sybase，參與Power Builder的維護和新版本的開發。這是我第一次參與軟件維護，令我認識到軟件維護的重要性，認識到編寫可維護的代碼是軟件開發的一個重要課題。  

　　Sybase系統化的質量跟蹤系統和用戶支援系統讓我獲益匪淺。在此期間，我閱讀了《Large-scale Software Development in C++》、Martin Fowler著的《Refactoring》、Andrei Alexandrescu著的《Modern C++ Design》，Herb Sutter著的《Exceptional C++》和《More exceptional C++》，以及Kent Beck著的《Extreme Programming Explained》等書籍。對軟件開發與維護有了進一步了解，但同時也更認識到軟件開發之難。  

　　最后，還要唐僧一下：要成為一個武林高手，雖然需要長期的鍛練，但其更重要的是其的領悟能力。同樣要成為編程高手，最重要的是領悟能力的訓練。有志不在年高，無志空活百歲。要有明確的目標，有針對的對象才能有的放矢。計算機知識更新換代很快，這要求我們要放出眼光，知道哪些該學，哪些學了也是浪費時間。