IT高手的修煉秘笈

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

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

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

　　后來，加入一家合資公司，擔(dān)任開發(fā)組長，有五、六個組員。這時我已讀過了邵維忠等譯的《面向?qū)ο蟮姆治觥�、楊芙清等編譯的《面向?qū)ο蟮脑O(shè)計》和《Code Complete》中譯本。對面向?qū)ο蟮某绦蛟O(shè)計雖有所了解但仍是一知半解。

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

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

　　1）要熟練掌握至少一種編程語言。我覺得最好是C++。掌握了C++，學(xué)習(xí)其它語言如Java或C#等并非難事，因為各種面向?qū)ο蟮某绦蛘Z言盡管在語法上可能有很大區(qū)別，在語義上卻大同小異。

　　2）不要寄希望于一次就把軟件設(shè)計好。在開發(fā)初期，要盡量用最簡單的設(shè)計實現(xiàn)最基本的功能，以使你的軟件盡早地能實際運行，不要過于拘泥于細節(jié)。這樣你才能盡早得到反饋，才能更直觀更全面地理解你所面對的問題。你所關(guān)注的重點應(yīng)依次是Make it work, make it right, make it fast。

　　3）軟件結(jié)構(gòu)要分塊分層。低層模塊不要依賴于上層模塊。一個類、一個接口或一個函數(shù)都應(yīng)只做一件事。沒有本質(zhì)聯(lián)系的類或接口就不應(yīng)有耦合關(guān)系。舉例而言，要用MVC（Model View Controller）Design Pattern切斷用戶界面與數(shù)據(jù)模型之間的直接關(guān)聯(lián)。

    4）軟件設(shè)計的主要工作是給類分配責(zé)任（responsibilities）。盡量不要把類設(shè)計成控制者（controller），而要設(shè)計成協(xié)調(diào)者（coordinator）�？刂普叻彩伦约鹤�，協(xié)調(diào)者讓別人做。控制者的邏輯往往很復(fù)雜，難于維護；協(xié)調(diào)者邏輯簡單，易于維護。要站在類的使用者角度設(shè)計類的外部行為。要講究一點軟件美學(xué)，即簡單、清晰、一致、平衡等。

　　5）了解并運用UML、Design Patterns、Unit Test、Design by Contract等。

　　6）使用代碼管理系統(tǒng)和質(zhì)量跟蹤系統(tǒng)。

　　7）了解各種軟件開發(fā)過程控制方法，并找出適合你的方法。

　　8）閱讀經(jīng)典書籍，研讀經(jīng)典代碼，訂閱雜志，與同行切磋。

　　在這行越久越覺得軟件開發(fā)難。軟件開發(fā)歷史還很短，才50年，還不是一門系統(tǒng)化的學(xué)科。有些人甚至認為軟件設(shè)計與編程是一門藝術(shù)。但軟件藝術(shù)大師還太少，而且我們很難直接欣賞到他們的杰作，除非所有的設(shè)計文檔和代碼都公開。軟件更容易藏污納垢。一個用戶界面很漂亮的軟件，內(nèi)部設(shè)計和代碼卻很可能臭不可聞。一個地板傾斜、墻壁裂縫、屋頂漏水的房子沒有人會買。一個設(shè)計很爛的軟件卻可能賣得不錯。但這樣的軟件能撐多久呢？

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

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

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

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

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

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

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

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

　　Sybase系統(tǒng)化的質(zhì)量跟蹤系統(tǒng)和用戶支援系統(tǒng)讓我獲益匪淺。在此期間，我閱讀了《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》等書籍。對軟件開發(fā)與維護有了進一步了解，但同時也更認識到軟件開發(fā)之難。

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

轉(zhuǎn)帖于：軟件水平考試_考試吧