告別理想主義,走向經驗主義 (轉)

告別理想主義,走向經驗主義 (轉)[@more@]一切觀點都是從Structual Programming VS -Oriented Program開始.

結構化和麵向程式設計最大的區別在什麼地方?從歷史看來,他們幾乎都是
同時起步（甚至結構化在應用領域最初還領先於OO),所以可以公允地認為它們
曾經,仍然處於同一層次,知是兩種不同的程式設計方法而已.(在這裡程式設計不是僅指
Coding,而是指工程的life-cycle).最大的區別在什麼地方,我認為是視角
不同.優秀的結構化把程式設計的"物件"看作一個個模組,這些模組中資料和操作是
分開的,但既成了模組,也就完成了一定的封裝和抽象.以前經常說,用C就可以
實現OO的程式設計,現在想想當時錯了,因為物件導向的特點是資料和操作本質上是
一個整體.結構化確實也可以實現把資料和操作封裝在一起,但那成了耦合,不利
於重用.比如我用結構體來代表一個"物件",大家知道介面是純資料(欄位),然後
定義幾個方法對結構進行操作(並把結構體作為方法的引數),當時覺得特別靈活,
因為如果要擴充哪個"物件",只需對結構體稍加修改,可是這樣程式設計的結果恰恰
是那幾個方法處於很尷尬的境地,因為他們被這個結構體緊緊地耦合住了,很難
擴充套件到其它類似的結構體.所以先前定義的結構體不是物件導向中的類,至少很
牽強.總結出以前的錯誤,可以看出,沒有必要用OO的觀點來應用於結構化領域.
他們的封裝各有特點,各有所長.程式設計是用來解決實際問題的,所有的考量都應該
是來自於問題空間的反饋.問題空間又是多樣的,有的時候需要把資料和操作綁
定,有的時候或許並不需要.

上面這段話的意思是,從我們學習程式設計的經歷看,大都是先結構化,再到OO,這
種過渡過程很容易讓人產生一種誤會,即OO是從結構化而來的(所謂青出於
藍勝於藍),OO總是強於結構化的.現在,我想強調它們的平等性,然後來解釋我
所認為的OO最顯著的優越性.

前面說過,問題空間是多樣的,另外,它還是變化的,如何應對變化,或者說,如
何用最小的代價來應對變化.引用一個常用的原則,就是"發現變化,封裝變化",
在結構化中,要封裝新的變化,我們很可能要做的是寫一個新的方法或新的模組,
這樣的變化一多,李鐵都受不了.而在OO中,我們用一個介面來封裝變化的物件,
在這個介面上,實現各種變化(即得到介面的各種含語義的子類),我們對這些變
化的操作應該都是面向這個介面的,於是又隱藏了變化的細節(不用針對各種變
化分別程式設計).類似的例子還有很多,物件導向領域的專家們很擅長撰寫類似的
"神話",但它卻不是神話,就發生在我們的身邊,值得進行深刻的研究.我一直
在想,為什麼物件導向具有這麼多優點,卻直到80年代才成為主流.也許,人類
需要更豐富的抽象才能得到它,也許他的易用行還有待考察.

在不懂OO時,很喜歡標榜自己是一個
OO-Programmer，可當我似乎理解了它,卻只希望作一個自由的Programmer.
軟體業面臨的問題,不是某一個新興技術就可以解決,不是一個物件導向就可以
解決,不是一個獨立的軟體工程就可以解決.不管是做Programmer,還是作Architect，
拘泥於某一方面,就只有死路一條.因此我選擇用靈活的技術,適當的技術來使
自己的軟體生存.將來如果做到軟體工程管理,也儘量用務實,靈活的管理辦法.

當然,在設計方面,物件導向仍然是我的首選,因為我最熟悉它,它確實也可以
解決所遇到的大多數問題.我象很多人一樣,憧憬著自己擁有架構優良的軟體財富,
可是,在我們擁有足夠的設計能力之前,這種憧憬很難實現.很多時候,我們對著復
雜的問題無從下手,勉強設計出的東西,卻有著天生的殘疾.唯一的辦法,只有孜孜
不倦的學習,用和創新來突破這些障礙.在這裡,不得不提到設計.

從教育的角度分析,設計模式就是專家經驗,共你學習和引用.從應用的角度分
析,它是解決方案,對應著情景,可重複性,可傳授性等關鍵要素.後者甚至比方案
本身更重要.設計模式可以幫助我們瞭解一個優良設計完成的全過程,理解面向對
象程式設計的諸多原則,從而加強我們的設計能力.如果上面的闡述還不足以讓您認識
設計模式,可以想想C語言的資料結構.我確實很反對把設計模式也當作一個"神話",
說白了,它是組織資料和操作的方案,GOF的"Design Patterns"中涉及的23種模
式甚至可以淺顯地認為是23種特殊的資料結構.對於模式的理解,應該打破觀念的
束縛,如果一個東西對應了"問題,場景,解決方案,可重複性,可傳授性,名稱"等要
素,他就是一種模式,你把它記在腦中或紙上,充分理解它,便成為了你自己的模式.
所以學習設計模式應該以一種開放,自由的心態,與自然世界展開充分對話.

充分利用設計模式,是一個不錯的想法,但若想要用設計模式來構造自己的軟體
體系,則是不切實際的,甚至容易陷入過度工程的誤區.因為軟體體系是一個複雜
的整體,又可以用模式語言表達的部分,也有無法用模式語言表達的部分.談到構架
,我們需要更多的學習.這些學習逐漸從軟體工程出發,需求分析,UML,RUP等等.
完備的方法學可以培養和釋放創造性的思維,直到一個普通人擁抱逐漸完善的系統.

前段時間困惑地思索"什麼是軟體" 的問題,今天又得到了新的啟示.
啟示一:軟體說到底還是一個工程學,它在冥冥中必定存在著合理的解釋.
啟示二:軟體的複雜性來自於需求的變化,因為有人的參與而無法控制,參透它的
本質也很難奏效.
現在看來,談"軟體是什麼"還為時過早,它還必須經歷漫長的"規範化過程",為解決
她帶來的方方面面的難題製造正式的方案.Brooks在"沒有銀彈"中提出"所有軟體
活動包括根本任務——打造構成抽象軟體實體的複雜概念結構,次要任務——使用
程式語言表達這些抽象實體".軟體活動必須用規範的軟體工程來,卓越的設計,
明確的需求,通暢的交流,透明的管理才是真正的解決之道,也就是所謂的根本任務.
在一日千里的軟體業,新技術,新開發工具,新演算法層出不窮,但他們對軟體產業的
影響都只是有限的.看到這一點,足以改變很多人的觀點.作為學習者,為什麼我們
要花時間去完成那些次要任務,而忽視掉跟產業相關的真正核心的部分呢?

我的觀點,已經很明確了,那就是作一個切實的軟體工程的實踐者.用成熟的
方法論明確需求,用靈活的設計滿足需求,我不追求技術,我只關注重要的部分,
我要用自己的實踐經驗來探清軟體的真諦!