大道至簡——軟件工程實踐者的思想 第2章 是懶人造就了方法

>>>  讀書—連接古今充實信仰  >>> 簡體     傳統

  第2章 是懶人造就了方法
 
    “僰 道有蜀王兵蘭 ,亦有神作大灘江中。其崖嶄峻不可破,(冰)乃積薪燒之。”
 
                                  ——《華陽國志》
 
1. 是懶人造就了方法
 
    戰國時期的李冰鑿了一座山。
 
    史記中說是“蜀守冰鑿離堆”,是說李冰在成都的時候鑿出了離堆。一說是李冰將都江堰附近的玉壘山鑿了一個大口子,叫寶瓶口,而鑿的石頭就堆成了離堆。另一說,則是李的確是鑿了一座“(溷)崖”,但是是在沫水,亦即是今天的大渡河。
 
    在哪里鑿的山,是史學家都說不清楚的事。但的確鑿了一座山,而且方法是“(因)其崖嶄峻不可破,(冰)乃積薪燒之”。
    我們已經看到事物的進化了。同是戰國時代,《列子·湯問篇》里的愚公就要“碎石擊壤”,而李冰就已經懂得“積薪燒之”了。
 
    會有人說愚公是“碎石”,并沒有說他“碎石”的方法究竟是“斧鉞以鑿之”,還是“積薪以燒之”。但想想那個時代,如果有人懂得了燒石頭這個方法,哪能不立即載文志之,永世傳承。
 
    再說了,愚公嘛。愚者怎么會呢?這還需要分析嗎?需要嗎?
 
    所以愚公會鑿,而李冰會燒。那李冰又是為什么會用“燒”這種方法來碎石的呢?如果李冰也象愚公那樣日復一日地督促著他的團隊鑿石開山,那他一定沒有時間來學習、尋找或者觀察,當然也不會發現“燒”這種方法可以加快工程進度,使得一大座山短時間就被嘩啦嘩啦地給“碎”掉了。
 
    要知道李冰的團隊可是成百上千人,要修堰筑壩,還要“鑿離堆”,當然還要吃喝啦撒睡。所以李冰如果忙起來的話,他必然是“受命以來,夙夜憂嘆”,必然食難下咽,睡無安枕。反之,李冰一定是個閑人,可以閑到沒事去看火能不能把石頭燒爆。
 
    這么大個工程里,如果有一個人會閑到看火燒石頭,那他一定很懶。那么多事堆著不去做,去看燒石頭,你說他不是懶是什么。
 
    正是一個懶人造就了“燒石頭”這個“碎石”的方法。愚公太勤快了,勤快得今天可以比昨天多鑿一倍的石頭。或者在愚公的項目計劃案的首頁里就寫著朱筆大字:“吾今勝昨倍許,明勝今倍許,而山不加增,何苦而不快。”
 
但是越發的勤快,愚公將越發沒有機會找到更快的方法, 人的精力終歸是有極限的。提出新的“方法”,解決的將是影響做事成效的根本問題。而愚公可以多吃點飯,多加點班,但突破不了人的精力的極限。
 
     記住,在兩千年前的某一天,閑極無聊的李冰下廚給夫人炒了一個小菜,他突然發現壘灶的鵝卵石被燒得爆裂開來,遇水尤甚。從此《史記》上記下了“蜀守冰鑿離堆”,而《華陽國志》上記下了他做這件事的方法“積薪燒之”。
 
     在差不多同一時間,愚公在山北之塞“碎石擊壤”。
 
2. 一百萬行代碼是可以寫在一個文件里的
 
     早期寫程序,都是將代碼打在穿孔紙帶上,讓計算機去讀的。要讓計算機讀的紙帶當然是連續的,這無需多講。其實我也沒有那樣寫過程序,真實的苦楚我也不知道。
 
    后來有了匯編語言,可以寫一些代碼了。這時的代碼是寫在文本文件里,然后交給一個編譯器去編譯,再由一個鏈接器去鏈接,這樣就出來了程序。
 
    第一個寫匯編的人,可能寫的是有名的“Hello World”程序,那個程序寫在一個文件里就行了。所以后來就成了習慣,大家都把代碼寫到一個文件里。早期的匯編語言里,GOTO 語句是用得非常非常頻繁的,將一個語句 GOTO到另一個文本文件里去,既不現實也不方便。所以大家習以為常,便統統地把代碼寫到一個文件里。
 
    再后來出了高級語言,什么 C 呀,Pascal 呀之類的。既然大家已經形成習慣了,所以很自然地會把一個程序寫到一個文件里。無論這個程序有多大,多少行代碼,寫到一個文件里多方便呀。
 
    直到如今語言發展得更高級了。可是程序員的習慣還是難改,一旦得了機會,還是喜歡把代碼寫到一個文件里的。
 
    好了,有人說我是想當然爾。En,這當然是有實據的。記得 Delphi 1.0 版發布的時候,全世界一片叫好聲。連“不支持雙字節”這樣的大問題,都不影響他在華語地區的推廣。然而不久,爆出了一個大 BUG!什么大 BUG 呢?Delphi 1.0 的編譯器居然不支持超過 64K 的源代碼文件!
 
    這被 Fans 們一通好罵。直到我用 Delphi 2.0 時,一個從 VB 陣營轉過來的程序員還跑過來問我這件事。好在Delphi 2.0 改了這個 BUG,這讓當時我的面子上好一陣風光。
 
     64k 的文件是什么概念呢?
 
     1 行代碼大概(平均)是 30 字節,64k 的源代碼是 2184行,如果代碼風格好一點,再多一些空行的話,差不多也就是 3000 行上下。
 
     也就是說,在 Delphi 1 的時代(以及其后的很多很多時代),程序員把 3000 行代碼寫到一個文件里,是司空見慣的事了。如果你不讓他這樣寫,還是會被痛罵的呢。
 
     所以呢,按照這一部分人的邏輯,一百萬行代碼其實是可以寫在一個文件里的。不單可以,而且編譯器、編輯器等等也都必須要支持。這才是正統的軟件開發。
 
     勤快的愚公創造不了方法。這我已經說過了。對于要把“一百萬行代碼寫到一個文件”,查找一個函數要在編輯器里按五千次 PageDown/PageUp 鍵的勤快人來說,是不能指望他們創造出“單元文件(Unit)”這樣的開發方法來的。
 
     然而單元文件畢竟還是出現了。這個世界上,有勤快人就必然有懶人,有懶人也就必然有懶人的懶方法。
 
     有了單元文件,也就很快出現了一個新的概念:模塊。把一個大模塊分成小模塊,再把小模塊分成更細的小小模塊,一個模塊對應于一個單元。于是我們可以開始分工作了,一部分人寫這幾個單元的代碼,另一部分則寫那幾個。
 
     很好,終于可以讓源代碼分散開來。結構化編程的時代終于開始了,新的方法取代了舊的方法,而這一切的功勞,是要歸終于那個在按第 5001 次PageDown鍵時,突然崩潰的程序師。他發自良心地說:不能讓這一切繼續下去了,我一定要把下一行代碼寫到第二個文件里去。我發誓,我要在編譯器里加入一個Unit關鍵字。①
 
3. 你桌上的書是亂的嗎?
 
     幾周之前,在一所電腦培訓學校與學生座談時,一個學員問我:“為什么我學了一年的編程,卻還是不知道怎么寫程序呢”。
 
     我想了想,問了這個學員一個問題:“你桌上的書是亂的嗎?”
 
     他遲疑了一下,不過還是回答我道:“比較整齊。”
 
     我當時便反問他:“你既然知道如何把書分類、歸整得整整齊齊地放在書桌,那怎么沒想過如何把所學的知道分類一下,歸納一下,整整齊齊地放在腦子里呢?”
 
     如果一個人學了一年的編程,他的腦袋里還是昏乎乎的,不知道從哪里開始,也不知道如何做程序。那想來只有一個原因:他學了,也把知識學進去了,就是不知道這些知識是干什么的。或者說,他不知道各種知識都可以用來做什么。
 
① Turbo Pascal 3.0 中才開始有了Uses和Unit關鍵字。在ANSI Pascal 標準里并沒有它。
 
     其實結構化編程的基本單位是“過程(Procedure)”,而不是上一小節說到的“單元(Unit)”。然而在我看來,過程及其調用是 CPU 指令集所提供的執行邏輯,而不是普通的開發人員在編程實踐中所總結和創生的“方法”。
 
     這里要提及到CPU指令集的產生。產生最初的指令集的方式我已經不可考證,我所知道的是CISC指令集與RISC指令集之爭在 1979 年終于爆發。前者被稱為復雜指令集,然而經過Patterson等科學家的研究,發現 80%的CISC指令只有在 20%的時間內才會用到;更進一步的研究發現,在最常用的 10 條指令中,包含的流程控制只有“條件分支(IF...THEN...)①”、“跳轉(JUMP)” 和“調用返回(CALL/RET)”……
 
     于是 CISC 被 RISC(精簡指令集計算機)替代了。動搖CISC 指令集地位的方法,就是分類統計。
 
     正如 CISC 指令集攪亂了一代程序設計師的思路一樣,大量的知識和資訊攪亂了上面給我提問的那位學員的思想。他應該嘗試一下分類,把既有的知識象桌子上的書一樣整理一下,最常用的放在手邊,而最不常用的放在書柜里。如果這樣的話,我想他已經在九個月前就開始寫第一個軟件產品了。
 
① 在x86 系統中,循環是用條件分支來實現的,而且條件分支指令 并不是IF...THEN...,這里用這兩個關鍵字,僅用于說明問題。
 
    你桌上的書還是亂的嗎?
 
4. 我的第一次思考:程序 = 算法 + 結構 + 方法
 
    我的第一次關于程序的本質的思考其實發生在不久前。那是我在 OICQ 上與 Soul 的一次談話。
 
    Soul(王昊)是DelphiBBS現任的總版主,是我很敬重的一位程序員。那時我們正在做DelphiBBS的一個“B計劃II”,也就是出第二本書。他當時在寫一篇有關“面向對象(OOP)”的文章。而我正在寫《Delphi源代碼分析》,在初期的版本里,有“面向對象”這一部分的內容。我們的對話摘要如下①:
 
Soul:我在寫書討論“面向對象的局限性”
我 :En.這個倒與我的意見一致。哈哈哈。 
我 :“絕對可以用面向過程的方法來實現任意復雜的系統。要知道,航天飛機也是在面向過程的時代上的天。但是,為了使一切變得不是那么復雜,還是出現了‘面向對象程序設計’的方法。” 
我 :——哈,我那本書里,在“面向對象”一部分前的引文中。就是這樣寫的。
 
① 這段對話的確很長。如果你不是非常有經驗的程序員,那么不能完整地閱讀和理解這段文字是很正常的。部分讀者甚至可以跳過這段引文,直接閱讀后面的結論。而有興趣的讀者,可以在我的網站上讀到它的全文(http://www.doany.net/)。
 
Soul:現在的程序是按照馮。諾伊曼的第一種方案做的,本來就是順序的,而不是同步的。CPU怎么說都是一條指令一條指令執行的。 
我 :面向過程是對“流程”、“結構”和“編程方法”的高度概括。而面向對象本身只解決了“結構”和“編程方法”的問題,而并沒有對“流程”加以改造。 
Soul:確實如此。確實如此。 
我 :對流程進一步概括的,是“事件驅動”程序模型。而這個模型不是OO提出的,而是Windows的消息系統內置的。所以,現在很多人迷惑于“對象”和“事件”,試圖通過OO來解決一切的想法原本就是很可笑的。
 
Soul:我先停下來,和你討論這個問題,順便補充到書里去。 
我 :如果要了解事件驅動的本質,就應該追溯到Windows內核。這樣就 
       涉及到線程、進程和窗體消息系統這些與OO無關的內容。所以,整 
       個RAD的編程模型是OO與OS一起構建的。現在很多的開發人員只知 
       其OO的外表,而看不到OS的內核,所以也就總是難以提高。 
Soul:OO里面我覺得事件的概念是很牽強的,因為真正的對象之間是相互 
       作用,就好像作用力和反作用力,不會有個“順序”的延時。 
我 :應該留意到,整個的“事件”模型都是以“記錄”和“消息”的方 
       式來傳遞的。也就是說,事件模型停留在“面向過程”編程時代使 
       用的“數據結構”的層面上。因此,也就不難明白,使用/不使用 
       OO都能寫Windows程序。 
我 :因為流程還是在“面向過程”時代。
 
 
Soul:所以所謂的面向對象的事件還是“順序”的。所以我們經常要考慮 
       一個事件發生后對其他過程的影響,所以面向對象現在而言是牽強 
       的。 
我 :如果你深入OS來看SEH,來看Messages,就知道這些東西原本就不 
       是為了“面向對象”而準備的。面向對象封裝了這些,卻無法改造 
       它們的流程和內核。因為OO的抽象層面并不是這個。 
我 :事件的連續性并不是某種編程方法或者程序邏輯結構所決定的。正如你前面所說的,那是CPU決定的事。 
Soul:比如條件選擇,其實也可以用一種對象來實現,而事實沒有。這個是因為cpu的特性和面向對象太麻煩。 
我 :可能,將CPU做成面向對象的可能還是比較難于想象和理解。所以MS才啟動.NET Framework。我不認為.NET在面向對象方法上有什么
 
      超越,也不認為它的FCL庫會有什么奇特的地方。——除了它們足 
      夠龐大。但是我認為,如果有一天OS也是用.NET Framework來編寫 
      的,OS一級的消息系統、異常機制、線程機制等等都是.NET的,都 
      是面向對象的。那么,在這個基礎上,將“事件驅動”并入OO層面 
      的模型,才有可能。
 
 
Soul:所以我發覺面向對象的思維第一不可能徹底,第二只能用在總體分 
      析層上。在很多時候,實質上我們只是把一個順序的流程折疊成對 
      象。 
我 :倒也不是不可能徹底。有絕對OO的模型,這樣的模型我見過。哈 
      哈~~但說實在的,我覺得小應用用“絕對OO”的方式來編寫,有 
      失“應用”的本意。我們做東西只是要“用”,而不是研究它用的 
      是什么模型。所以,“Hello World”也用OO方式實現,原本就只 
      是出現在教科書中的Sample罷了。哈哈。 
Soul:還有不可能用徹底的面向對象方法來表達世界。 因為這個世界不 
      是面向對象的。 是關系網絡圖,面向對象只是樹,只能片面的表 
      達世界。所以很多時候面向對象去解決問題會非常痛苦。所以編程 
      退到數據結構更合理,哈哈。
 
 
我 :如果內存是“層狀存取”的,那么我們的“數據結構”就可以基于 
      多層來形成“多層數據結構”體系。如果內存是“樹狀存取”的, 
      那么我們當然可以用“樹”的方式來存取。——可惜我們只有順序 
      存取的內存。 
我 :程序=數據+算法 
      ——這個是面向過程時代的事。 
      程序=數據+算法+方法 
      ——在OO時代,我們看到了事件驅動和模型驅動,所以出現了“方法”問題。
 
 
Soul:我的經驗是:總體結構->面向對象,關系->數據結構,實現->算法
Soul:看來我們對面向對象的認識還是比較一致的。
 
    我第一次提到我對程序的理解是“程序=數據+算法+方法”,便是在這一次與 Soul 的交談之中。在這次的交談中的思考仍有些不成熟的地方,例如我完全忽略了在面向過程時代的“方法”問題。實際上面向過程開發也是有相關的“方法”的。
 
     所謂“面向過程開發”,其實是對“結構化程序設計”在代碼階段的一個習慣性的說法。而我忽略了這個階段的“方法”的根本原因,是即使沒有任何“方法”的存在,只需要有了“單元(Unit)”和“模塊(Module)”的概念,在面向過程時代,一樣可以做出任意大型的程序。在那個時代,“方法”問題并不會象鼻子一樣凸顯在每一個程序員的面前。
 
 
     面向過程開發中,“過程(procedure)”是 CPU 提供的,“單元(unit)”則是編譯器提供的(機制)。程序員不需要(至少是不必須)再造就什么“方法”,就可以進行愚公式的開發工作了。
 
     如果不出現面向對象的話,這樣偉大的工程可能還要再干一百年……
 
 
     而與“面向對象”是否出現完全無關的一個東西,卻因為“過程”和“單元”的出現而出現了。這就是“工程(engineering)”。

周愛民(Aimingoo) 2013-08-24 22:12:04

[新一篇] 大道至簡——軟件工程實踐者的思想 第1章 編程的精義

[舊一篇] 大道至簡——軟件工程實踐者的思想 第3章 團隊缺乏的不只是管理
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表