IT高手

要成為武林高手，需要長時間的勤學苦練。要成為軟體開發高手，又需要多長時間呢？《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》等書籍。對軟體開發與維護有了進一步了解，但同時也更認識到軟體開發之難。

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

要成為武林高手，需要長時間的勤學苦練。要成為軟體開發高手，又需要多長時間呢？《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》等書籍。對軟體開發與維護有了進一步了解，但同時也更認識到軟體開發之難。

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