1. 程式人生 > >讀書筆記 --《人月神話》

讀書筆記 --《人月神話》

函數 獨行俠 以及 inside 大型 體系結構 strong 帶來 問題

(1975版) The Mythical Man-Month

岸上的船兒,如同海上的燈塔,無法移動。

A ship on the beach is a lighthouse to the sea...

史前史中,沒有別的場景比巨獸在焦油坑中垂死掙紮的場面更令人震撼。上帝見證著恐龍,猛獁象,劍齒虎在焦油坑中掙紮。它們掙紮得越是猛烈,焦油糾纏得越緊,沒有任何猛獸足夠強壯或具有強壯或具有足夠的技巧,能夠掙脫束縛,它們都沈到了坑底。

過去幾十年的大型系統開發就猶如這樣一個焦油坑,表面上看起來好像沒有任何一個單獨的問題。會導致困難,每個都能被解決,但是當它們相互糾纏和累積在一起的時候,團隊的行動就會變得越來越慢

。不過,如果我們想解決問題,就必須試圖先去理解它。

編程產品(Programming Product)

這是可以被任何人運行,測試,修復和擴展的程序。它可以運行在多種操作系統平臺上,供多套數據使用。要成為通用的編程產品,程序必須按照普遍認可的風格來編寫,特別是輸入的範圍和形式必須擴展,以適用於所有可以合理使用的基本算法。接著,對程序進行徹底的測試,確保它的穩定性和可靠性,使其值得信賴。這就意味著必須準備,運行和記錄詳盡的測試用例庫,用來檢查輸入的邊界和範圍。此外,要將程序提升為程序產品,還需要有完備的文檔,每個人都可以加以使用,修復和擴展。經驗數據表明,相同功能的編程產品的成本,至少是已經經過測試的程序的3倍。

編程系統(Programming System)

這是在功能上能相互協作的程序集合,具有規範的格式,可以進行交互,並可以用來組裝和搭建整個系統。要成為系統構件,程序必須按照一定的要求編制,使輸入和輸出在語法和語義上與精確定義的接口一致。同時程序還要符合預先定義的資源限制——內存空間,輸入輸出設備,計算機時間。最後,程序必須同其它系統構件單元一道,以任何能想象到的組合進行測試。由於測試用例會隨著組合不斷增加,所以測試的範圍非常廣。因為一些意想不到的交互會產生許多不易察覺的bug,測試工作將會非常耗時,因此相同功能的編程系統構件的成本至少是獨立程序的三倍。

編程系統產品(Programming Systems Product)

其成本高達9倍,然而,只有它才是真正有用的產品,是大多數系統開發的目標。


編程系統產品:

技術分享圖片

職業的樂趣:

  首先是一種創建事物的純粹快樂。如同小孩在玩泥巴時感到愉快一樣,成年人喜歡創建事物,特別是自己進行設計。我想這種快樂是上帝創造世界的折射,一種呈現在每片獨特,嶄新的樹葉和雪花上的喜悅。樂趣還來自於工作在如此易於駕馭的介質上。程序員,就像詩人一樣,幾乎僅僅工作在單純的思考中。程序員憑空地運用自己的想象,來捏造自己的城堡。很少有這樣的介質——創造的方式如此靈活,如此得易於精煉和重建,如此得容易實現概念上的設想。(不過我們將會看到,容易駕馭的特性也有它自己的問題)

編程非常有趣,在於它不僅滿足了我們內心深處進行創造的渴望,而且還愉悅了每個人內在的情感

職業的苦惱:

然而這個過程並不全都是喜悅。我們只有事先了解一些編程固有的煩惱,這樣,當它們真正出現時,才能更加坦然地面對。

  1. 必須追求完美
  2. 由他人來設定目標,供給資源,提供信息
  3. 依賴其他程序員,共同合作
  4. 概念設計是有趣的,但尋找瑣碎的bug卻是一項重復性活動
  5. 無奈——投入了大量勞動後,卻已顯得陳舊過時

美酒的釀造需要年頭,美食的烹調需要時間;片刻等待,更多美味,更多享受。

Good cooking takes time, if you are made to wait, it is to serve you better, and to please you...

項目滯後的原因:

  1. 不真實的假設——一切都將運作良好
  2. 估算時隱含地假設人和月可以互換
  3. 沒有耐心持續地進行估算並不斷更新,調整
  4. 對進度缺少跟蹤和監督
  5. 當意識到進度偏離時,下意識的反應是增加人力,但只是火上澆油,讓事情更糟

樂觀主義

  計算機編程基於十分容易掌握的介質,編程人員通過非常純粹的思維活動——概念,以及靈活的表現形式來開發程序。正由於介質的易於駕馭,我們期待在實現過程中不會碰到困難,因此造成了樂觀主義的彌漫。

軟件任務進度

1/3 計劃

1/6 編碼

1/4 構件測試和早期系統測試

1/4 系統測試

外科手術隊伍(The Surgical Team)

這些研究表明,效率高和效率低的實施者之間具體差別非常大。經常達到了數量級水平。

The studies revealed large individual differences between high and low performers, often by an order of magnitude...

  外科醫生,Mills稱之為首席程序員。他親自定義功能和性能技術說明書,設計程序,編制源代碼,測試以及書寫技術文檔。他使用例如PL/I的結構化編程語言,擁有對計算機系統的訪問能力,該計算機系統不僅僅能進行測試,還存儲程序的各種版本,以允許簡單的文件更新,並對他的文檔提供文本編輯能力。首席程序員需要極高的天分,十年的經驗和應用教學,業務數據處理或其他方面的大量系統和應用知識。

貴族專制,民主政治和系統設計(Aristocracy,Democracy,and System Design)

大教堂是藝術史上無與倫比的成就。它的原則既不乏味也不混亂......真正達到了風格上的極致,完成這件作品的藝術家們,完全領會和吸收了以往的成功經驗,也完全掌握了他們那個時代的技術,而且在應用的時候做到了恰如其分,絕不輕率,也絕不花哨。如同旅遊指南所示,風格的一致和完整性來自於系統擁有自我約束和犧牲精神的建築師們,他們每個人犧牲了自己的一些創意,以獲得純粹的設計。同樣,這不僅顯示了上帝的榮耀,同時也體現了他拯救那些沈醉在自我驕傲中人們的力量。

在系統設計中,概念完整性應該是最重要的考慮因素。也就是說為樂反映一系列連貫的設計思路,寧可省略一些不規則的特性和改進,也不提倡獨立和無法整合的系統,哪怕它們其實包含著許多很好的設計。概念的完整性要求設計必須由一個人,或者非常少數互有默契的人員來實現。而進度壓力卻要求很多人員來開發系統。有兩種方法可以解決這種矛盾。第一種是仔細地區分設計方法和具體實現。第二種是前一章節中所討論的,一種嶄新的組建編程開發團隊的方法

對於非常大型的項目,將設計方法,體系結構方面的工作與具體實現相分離是獲得概念完整性的強有力方法。

系統的體系結構(architecture)指的是完整和詳細的用戶接口說明對於計算機,它是編程手冊,對於編譯器,它是語言手冊;對於控制程序,它是語言和函數調用手冊,對於整個系統,它是用戶要完成自己全部工作所需參考的手冊的集合。因此,系統的結構師,如同建築的結構師一樣,是用戶的代理人。結構師的工作,是運用專業技術知識來支持用戶的真正利益,而不是維護銷售人員所鼓吹的利益。體系結構同實現必須仔細區分開來。如同Blaauw所說的,“體系結構陳述的是發生了什麽,而實現描述的是如何實現。”

作者的經驗觀念:

系統的概念完整性決定了使用的容易程度。不能與系統基本概念進行整合的良好想法和特色,最好放到一邊,不予考慮。

如果出現了很多非常重要但不兼容的構想,就應該拋棄原來的設計,對不同基本概念進行合並,在合並之後的系統上重新開始。

沒有規矩,不成方圓。——紀律和規則對行業是有益的。

外部的體系結構規定實際上是增強,而不是限制實現小組的創造性。一旦他們將註意力集中在沒有人解決過的問題上,創意就開始奔湧而出。

如同Blaaw所指出的,整個創造性活動包括了三個獨立的階段:體系結構(architecture),設計實現(implementation),物理實現(realization)。在實際情況中,它們往往可以同時開始和並發地進行。在開發第一個系統的時候,結構師傾向於精煉和簡潔。他知道自己對正在進行的任務不夠了解,所以他會謹慎仔細地工作。第二個系統是設計師們所設計的最危險的系統。而當他著手第三個或第四個系統時,先前的經驗會相互驗證,得到此類系統通用特性的判斷,而且系統之間的差異會幫助他識別出經驗中不夠通用的部分。

貫徹執行(Passing the word)

文檔手冊讀起來枯燥乏味,但是精確比生動更加重要。

為什麽巴比倫塔會失敗?

既然他們具備了所有的這些條件,為什麽項目還會失敗呢?他們還缺乏些什麽?

——兩個方面:交流以及交流的結果,組織

通過史書的字裏行間,我們推測交流的缺乏導致了爭辯,沮喪和群體猜忌。很快,部落開始分裂:大家選擇了孤立,而不是互相爭吵。

大型編程項目的組織架構:

如果項目有n個工作人員,則有n(n-1)/2個相互交流的接口,有將近能2^n個必須合作的潛在團隊。團隊組織的目的是減少不必要的交流和合作的數量,因此良好的團隊組織是解決上述交流問題的關鍵措施。減少交流的方法是人力劃分(Division of labor)和限定職責範圍(Specialization of function)。當使用人力劃分和職責限定時,樹狀管理結構所映出對詳細交流需要會相應減小。

那麽技術主管的角色是什麽?他對設計進行構思,識別系統的子部分,指明從外部看上去的樣子,勾畫它的內部結構。他提供整個設計的一致性和概念的完整性;他控制系統的復雜程度。當某個技術問題出現時,他提供問題的解決方案,或者根據需要調整系統設計。用Al Capp所喜歡的一句諺語,他是“攻堅小組中的獨行俠”(inside-man at the skunk works)他的溝通交流在團隊中是首要的。他的工作幾乎完全是技術性的。

巴比倫塔可能是第一個工程上的徹底失敗,但它不是最後一個。交流和交流的結果——組織,是成功的關鍵。交流和組織的技能需要管理者仔細考慮,相關經驗的積累和能力的提高,同軟件技術本身一樣重要。

胸有成竹(Calling the Shot)

實踐是最好的老師。但是,如果不能從中學習,再多的實踐也沒有用。

附錄:

從哈佛大學Aiken和Iverson名下畢業終於讓我的職業夢想變成了現實,並且,就這樣沈迷了一輩子。感謝上帝,讓我成為了為數不多的那些開開心心做著自己喜歡工作的人之一。我實在無法想象還有哪種生活會比熱愛計算機更加激動人心,自從從真空管發展到集成電路以來,計算機技術已經飛速發展。我用來工作的第一臺計算機,是從哈佛剛剛出爐的IBM 7030 Stretch超級計算機,Stretch在1961到1964年間都是世界上運算速度最快的計算機,一共賣出了9臺。而我現在用的計算機,Macintosh Powerbook,不但快,還有大容量內存和硬盤,而且便宜了1000倍(如果按定價美元來算,便宜了5000倍)。我們依次看到了計算機革命,電子計算機革命,小型計算機革命,微型計算機革命,這些技術上的革命每一次都帶來了計算機數量上的劇增。

在計算機技術進步的同時,計算機相關學科知識也在飛速發展。當我在五十年代剛從學校畢業的時候,我能看完當時所有的期刊和會議報告,掌握所有的潮流動向。而我現在只能對層出不窮的學科分支遺憾地說再見,對我所關註的東西也越來越難以全部掌握。興趣太多,令人興奮的學習,研究和思考的機會也太多——多麽不可思議的矛盾啊!這個神奇的時代遠遠沒有結束,它依然在飛速發展。

更多的樂趣,盡在將來。

讀書筆記 --《人月神話》