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公司德國分公司)嚴謹的工作態度都給我留下了深刻印象。  

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

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

  一年半后,我離開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》等書籍。對軟件開發與維護有了進一步了解,但同時也更認識到軟件開發之難。  

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

 


軟件工程專家網 beiyan 2011-02-22 18:35:38

[新一篇] IT時代周刊編輯手記:和郭為共進晚餐

[舊一篇] IT管理經典文章重讀:任正非的《北國之春》
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表