讀人月神話有感

關於本書，即便不少沒讀過的人也能說出其中知名度最高的關於人月神話的觀點。以前還在知乎上看過有人舉了一個例子：一我的生孩子須要十個月，兩我的去生孩子一樣須要十個月。這一比喻雖不徹底恰當，卻也大體說出點內容。事實上，做者在書中這樣來描述人月神話：軟件開發項目常以人月來衡量工做量，這種度量暗示着人手和時間是能夠互換的。這種「人多力量大」的想法是一種一廂情願的虛妄神話，布魯克斯法則：向滯後的軟件項目追加人手會使得進度更遲緩（Adding manpower to a late software project makes it later）。關於這點，做者解釋的爲：向軟件項目中增派人手從三個方面增長了項目必要的整體工做量：任務從新分配自己和所形成的工做中斷；培訓新人員；額外的相互溝通。一樣，做者也向項目管理人員提供了相應的解決方法：

• 從新安排進度。我喜歡P.Fagg，一個具備豐富經驗的硬件工程師的忠告：「避免小的誤差（Take no small slips）」。也就是說，在新的進度安排中分配充分的時間，以確保工做能仔細、完全地完成，從而無需從新肯定時間進度表。
• 削減任務。在現實狀況中，一旦開發團隊觀察到進度的誤差，老是傾向於對任務進行削減。當項目延期所致使的後續成本很是高時，這經常是惟一可行的方法。項目經理的相應措施是仔細、正式地調整項目，從新安排進度；或者是默默地注視着任務項因爲輕率的設計和不完整的測試而被剪除。

　　在三四十年前，做者便以他豐富的項目經驗和敏銳的觀察力、判斷力提出這樣創造性的論斷，確實使人折服。時至現在，關於人力和時間之間的關係並不是呈現線性關係，也不能採用人月做爲生產率的衡量標準這一結論已獲得廣泛的認同。

　　固然，做者的論斷以及Brooks準則也並不是嚴格成立：在《20年後的人月神話》一文中，做者給出了Boehm的模型和數據以驗證以前的說法太過絕對，可是，「這些細緻的研究使「異常簡化」的Brooks準則更加實用。做爲平衡，我仍是堅持這個簡單的陳述，做爲真理的最佳近似，以及一項經驗法則——警告經理們避免對進度落後的項目採起的盲目、本能的修補措施。」

　　許多人都以爲以上觀點就是《人月神話》的所有了，並不是這樣。《人月神話》只是書中一個章節，Brooks準則也只是書中的觀點之一。本書所述內容遠非於此，它涉及到軟件開發與項目管理過程當中的方方面面，從開發團隊人員配置，到資源的合理配置，到項目文檔的撰寫以及其餘許多內容。實際上，本書取名《人月神話》在某種意義上存在必定的誤導性：在《20年後的人月神話》中，做者提煉出了核心觀點：概念完整性和結構師。

• 概念完整性。一個整潔、優雅的編程產品必須向它的每一個用戶提供一個條理分明的概念模型，這個模型描述了應用、實現應用的方法以及用來指明操做和各類參數的用戶界面使用策略。用戶所感覺到的產品概念完整性是易用性中最重要的因素。
• 結構師。結構師負責產品全部方面的概念完整性，開發用於向用戶解釋使用的產品概念模型，概念模型包括全部功能的詳細說明以及調用和控制的方法。結構師是這些模型的全部者，同時也是用戶的代理。在不可避免地對功能、性能、規模、成本和進度進行平衡時，卓有成效地體現用戶的利益。
• 將體系結構和設計實現、物理實現相分離。爲了使結構師的關鍵任務更加可行，有必要將用戶所感知的產品定義——體系結構，與它的實現相分離。體系結構和實現的劃分在各個設計任務中造成了清晰的邊界，邊界兩邊都有大量的工做。
• 體系結構的遞歸。對於大型系統，即便全部實現方面的內容都被分離出去，一我的也沒法完成全部的體系結構工做。因此，有必要由一位主結構師把系統分解成子系統，系統邊界應該劃分在使子系統間接口最小化和最容易嚴格定義的地方。每一個部分擁有本身的結構師，他必須就體系結構向主結構師彙報。顯然，這個過程能夠根據須要重複遞歸地進行。

　　因此從人我的觀點出發，本書用其中一章的標題命名全書，實則不太穩當，哪怕叫作《項目管理規範》都更能作到統籌兼顧（儘管這個名稱看起來有點官腔，或者說：土）。固然，做者這樣命名，應該有本身的用意（或許用其中一篇做爲總標題是這類技術文章合集書籍命名的一種習慣？前段時間看的《黑客與畫家》也是這樣）。

　　回到書本內容，大部份內容涉及團隊與管理，強調了溝通及人的重要性，技術方面雖未過多涉及，卻從項目管理的角度高屋建瓴地描繪了軟件開發的整個過程，在一些不涉及具體技術的方面（由於年代已經過久遠），頗有先見性和指導性。

　　簡單提下書中對我最有感觸的幾章吧，其餘有些由於經驗不夠的緣由還不能徹底理解。

• 第一章 焦油坑 
  　　史前時代的焦油坑吞噬了成千上萬個力大無窮的巨獸，今天的大型軟件項目則令無數龐大的開發團隊陷入無從逃脫的窘境。軟件程序按其規模和目標的不一樣，對開放過程的要求也有極大的不一樣，這給軟件開放這一職業帶來無窮樂趣，同時也是這一行業苦惱的根源。
• 第三章 外科手術隊伍 
  　　雖然優秀的程序員的工做效率每每數倍於平庸的程序員，但如果缺少合理的配置，優秀的成員未必能構成優秀的團隊。大型軟件開發項目的團隊須要和外科手術組同樣妥善分工，各司其職協調配合。 
• 第五章 第二個系統效應 
  　　人們在第一個系統成功完成後，每每會在開發後續的第二個系統時犯冒進的錯誤。第二個系統常常成爲過分設計或多此一舉的犧牲品。要避免這種錯誤，必須在第二個系統開發時審慎地考查技術環境的變化，普遍進行交流和溝通，聆聽各方面的建議，確立嚴謹的估算和規劃。 
• 第六章 溝通順暢 
  　　架構設計一般由核心設計小組完成，將設計概念傳達到整個開發團隊是貫徹概念完整性的必然要求。以System 360的開發經驗爲例，要貫徹概念完整性，須要在團隊中保持良好順暢的溝通和交流，採用形式化定義等技術來確保概念被精確地定義和傳達。獨立的測試小組是系統質量的良好保證。 
• 第七章 巴別塔爲什麼失敗 
  　　若是缺少良好有效的溝通和協做，成員間難以有效的配合，團隊項目的目標就沒法實現。清晰的工做文檔，明確的組織結構，合理的職責分配，都是大型軟件項目最終成功的保證。 
• 第九章 袖裏乾坤 
  　　最大化資源利用率，減小沒必要要的資源佔用，合理規劃，使軟件系統在資源有限的狀況下依然保證了良好的性能，從而實現良好的可伸縮性和健壯性，這能體現軟件開發人員精湛的設計技巧。巧妙的數據結構每每能大幅度地儉省資源耗費，提升系統運行的性能。
• 第十一章 準備拋棄 
  　　變化是永恆的，用戶的需求和指望在變化，開發者對用戶需求的理解在變化，適用的技術也在變化，故而最佳的解決策略也可隨之變化。軟件開發團隊應靈活地配置人力和資源，適應開發過程當中的種種問題。程序的複雜性、用戶需求的不肯定性、軟硬件技術環境的發展等因素致使了軟件維護工做並不是老是可以百分之百地得到回報。 
• 第十六章 沒有銀彈――軟件工程的必然和偶然 
  　　本文最初發表於1985年的IFIP第十屆世界計算機大會上，此時距《人月神話》第一版發行已有十年，其間計算機技術領域的變化使人振奮，但做者在此提出，因爲軟件的複雜性，一致性，變化性和不可見性，解決軟件危機的銀彈並不存在。做者點評了二十世紀80年代前期爲業界寄予厚望的一些新技術，討論了它們在克服軟件危機中所具有的優點和缺憾。做者預言在近十年內，沒有任何單獨的軟件工程進展可使軟件生產率有數量級的提升。 　　

　　以上是我對本書內容的簡單思考與提煉，之後有一些工做經驗後，我仍是要回頭再看一遍《人月神話》的，把其中不理解的部分繼續讀透。

　　推薦本文的讀者朋友們也去讀一讀這本書，絕對不會失望的。關於寫做風格，看看譯者的話：

　　在寫做風格上，《人月神話》也足以垂範後世。圖靈獎評選委員會曾經特地提到，布魯克斯不只爲計算機技術作出了傑出的貢獻，他也是一位修養全面的學者。《人月神話》並不是一份枯燥的技術文獻，而是一系列文采斐然的隨筆――布魯克斯對文學和藝術涉獵頗廣，他敏銳的思惟和淵博的學識，使他在表述軟件工程思想時，能從人文和其餘工程領域信手拈來旁證博引，深得舉一反三之妙。從英語寫做的角度上說，《人月神話》具有隨筆體睿智而典雅的風貌，行雲流水間文思嚴謹。讀者沒必要象閱讀常見的技術手冊同樣正襟危坐在工做臺前研讀，卻是能夠在旅途之中，工做之暇輕鬆地開卷有益，領略精純的文筆、睿智的思索。 

　　到這，本文差很少該結束了，在此，我想引用《人月神話》的部分結束語，與諸君共勉：

　　我實在沒法想像還有哪一種生活會比熱愛計算機更加激動人心，自從從真空管發展到集成電路以來，計算機技術已經飛速發展。我用來工做的第一臺計算機，是從哈佛剛剛出爐的IBM7030 Stretch超級計算機，Stretch在1961到1964年間都是世界上運算速度最快的計算機，一共賣出了9臺。而我如今用的計算機，Macintosh Powerbook，不但快，還有大容量內存和大容量硬盤，並且便宜了1000倍（若是按定值美圓來算，便宜了5000倍）。咱們依次看到了計算機革命，電子計算機革命，小型計算機革命，微型計算機革命，這些技術上的革命每一次都帶來了計算機數量上的劇增。

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