《人月神話》讀書筆記
焦油坑
1.
“要成為通用的程式設計產品，程式必須按照普遍認可的風格來編寫，特別是輸入的範圍和形式必須廣泛地適用於所有可以合理使用的基本演算法。接著要對程式進行徹底測試，確保它的穩定性和可靠性，使其值得信賴。。。。此外，還需要有完備的文件。”
閱讀了這裡對於程式設計產品的特性的描述，可見一個程式要真正成為一個程式設計產品，還需要一些特別的注意點：第一，程式必須按照普遍認可的風格來編寫；第二，必須對程式進行徹底的測試；第三，還要有完備的文件。這些注意點我在以後去實際編寫真正的程式設計產品時也會注意。
人月神話
2.
“用人月作為衡量一項工作的規模是一個危險和具有欺騙性的神話。”“向進度落後的專案中增加人手，只會使進度更加落後。”
第一句話可以說是這本書的點題之筆，“人月神話”由此而來。確實，很多情況下，特別是對於無法分解的任務，增加人手並不會減少完成任務所需要的時間。這在以後的專案進度安排中要特別注意。
而第二句話則是對Brooks法則的簡化，但也非常明確地說明了在進度落後時盲目增加人手的危害，必須要考慮到因增加人手而引發的培訓、任務劃分、交流的問題。
3.
“理論上，缺陷的數量應該為零。但是，由於我們的樂觀主義，通常實際出現的缺陷數量要比預料的要多得多。”
這一點，作為一名程式設計師可以說是深有體會。很多時候，當我們完成一個專案的編碼過程之後，由於樂觀主義，總是會祈禱不會出現缺陷。然後，大部分甚至說所有的情況下，都會出現多得多的缺陷，甚至很多時候消除缺陷需要花費的時間比之前編寫專案程式碼的還要多。
外科手術隊伍
4.
”外科醫生。Mills稱之為首席程式設計師。他親自定義功能和效能技術說明書，設計程式，編制原始碼，測試以及書寫技術文件。““副手”“管理員”“編輯”“兩個祕書，管理員和編輯每個人需要一個祕書”“程式職員”“工具維護人員”“測試人員”“語言專家”
此處非常詳細地描述了一個完備的程式開發團隊應該包括的人員及各自的角色，給我們以後組建程式開發團隊提供了很好的借鑑。當然，這是非常理想化的情況，如果在成本允許的情況下能做到這樣是最好的，但其中比如管理員和編輯都要配祕書、要有專門的工具維護人員，這些可能在實際情況下要做到還是挺難的。
貴族專制、民主政治和系統設計
5.
“概念完整性要求設計必須由一個人，或者非常少數互有默契的人員來實現。”“體系結構同實現必須仔細地區分開來。”
這解釋了為什麼要讓少數所謂的“貴族”來“專制統治”，讓他們來進行整體的體系結構等的設計，讓他們來指導可憐的實現人員如何工作。並不是說不能“民主”，難道員工中就不會有好的創意嗎？肯定是有的。但是為了保證系統概念上的完整性，就必須控制解決使用者問題，實現使用者利益的這些概念，把這些概念控制在少數精英手中，避免出現很多不錯但是不相容的構想。因此，這是一種無需歉意的貴族專制統治。
畫蛇添足
6.
“結構師必須牢記是開發人員承擔創造性和發明性的實現責任，所以結構師只能建議，而不能支配；時刻準備著為指定的說明建議一種實現的方法，同樣準備接受任何能達到目標的方法；對上述的建議保持低調和平靜；準備放棄堅持所做的改進建議。”
這段話對結構師做出了中肯的提醒，必須要牢記真正承擔實現責任的師開發人員，自己只能建議，而不能支配，畢竟你沒有親手去做。通常情況下開發人員對體系結構上修改建議的反對是對的，當正在實現產品時，某些特性修改會產生意想不到的成本開銷。
貫徹執行
文件化的規格說明——手冊
手冊、或者書面規格說明，是一個非常必要的工具。手冊是產品的外部規格說明，它描述和規定了使用者所見的每一個細節;同樣的，它也是結構師主要的工作產物。
規格說明也不斷地被重複準備和修改。
在進度表上應該有帶日期的版本資訊。
手冊不但要描述包括所有介面在內的使用者可見的一切，它同時還要避免描述使用者看不見的事物。後者是程式設計實現人員的工作範疇，而實現人員的設計和創造是不應該被限制的。體系結構設計人員必須為自己描述的任何特性準備一種實現方法，但是他不應該試圖支配具體的實現過程。
規格說明的風格必須清晰、完整和準確。
為什麼巴比倫塔會失敗?
“團隊組織的目的是減少不必要交流和合作的數量。
減少交流的方法是人力劃分和限定職責範圍。
產品負責人的角色是什麼?他組建團隊，劃分工作及制訂進度表。他要求，並一直要求必要的資源。
產品負責人和技術主管是同一個人。
第二，大型專案中，每個角色都必須全職工作，甚至還要加班。
產品負責人作為總指揮，技術主管充當其左右手。”
巴比倫塔失敗的根本原因就在於缺乏交流和了合理的組織，我們在軟體專案開發過程中要特別注意這兩點。
胸有成竹
編譯器的複雜度是批處理程式的三倍，作業系統複雜度是編譯器的三倍。
削足適履
空間技能
用功能交換尺寸。
設計人員必須決定使用者可選專案的粗細程度。
考慮空間-時間的折衷。
提綱挈領
計算機產品的文件
報價、預測、價格:這三個因素互相牽制，決定了專案的成敗。
為什麼要有正式的文件
首先，書面記錄決策是必要的。
第二，文件能夠作為同其他人的溝通渠道。
最後，專案經理的文件可以作為資料基礎和檢查列表。
未雨綢繆
為變更計劃系統
如何為上述變化設計系統，它們包括細緻的模組化、可擴充套件的函式、精確完整的模組間介面設計、完備的文件。另外，還可能會採用包括呼叫佇列和表驅動的一些技術。
最重要的措施是使用高階語言和自文件技術。
變更的階段化是一種必要的技術。
干將莫邪
“專案經理應該制訂一套策略，併為通用工具的開發分配資源。”
看了這個部分，更加意識到通用工具的重要性。
輔助機器和資料服務
這有兩個重要的理念。首先是受控，即程式的拷貝屬於經理，他可以獨立地授權程式的變更。其次是使釋出的進展變得正式，以及開發庫與整合、釋出的正式分離。
沒有銀彈-軟體工程中的根本和次要問題
沒有任何技術或管理上的進展，能夠獨立地許諾十年內使生產率、可靠性或簡潔性獲得數量級上的進步。
所有軟體活動包括根本任務——打造由抽象軟體實體構成的複雜概念結構，次要任務——使用程式語言表達這些抽象實體，在空間和時間限制內將它們對映成機器語言。
即使全部次要任務的時間縮減到零，也不會給生產率帶來數量級上的提高。
介紹
大家熟悉的軟體專案具有一些人狼的特性(至少在非技術經理看來)，常常看似簡單明瞭的東西，卻有可能變成一個落後進度、超出預算、存在大量缺陷的怪物。
是否一定那麼困難呢?——根本困難
這樣的畸形並不是由於軟體發展得太慢，而是因為計算機硬體發展得太快。
根本的——軟體特性中固有的困難，次要的——出現在目前生產上的。
軟體開發中困難的部分是規格化、設計和測試這些概念上的結構，而不是對概念進行表達和對實現逼真程度進行驗證。
現代軟體系統中這些無法規避的內在特性:複雜度、一致性、可變性和不可見性。
複雜度
沒有任何兩個軟體部分是相同的。
軟體實體的擴充套件也不僅僅是相同元素重複新增，而必須是不同元素實體的新增。
軟體的複雜度是必要屬性，不是次要因素。
上述軟體特有的複雜度問題造成了很多經典的軟體產品開發問題。由於複雜度，團隊成員之間的溝通非常困難，導致了產品瑕疵、成本超支和進度延遲;由於複雜度，列舉和理解所有可能的狀態十分困難，影響了產品的可靠性;由於函式的複雜度，函式呼叫變得困難，導致程式難以使用;由於結構性複雜度，程式難以在不產生副作用的情況下用新函式擴充;由於結構性複雜度，造成很多安全機制狀態上的不可見性。
複雜度不僅僅導致技術上的困難，還引發了很多管理上的問題。它使全面理解問題變得困難，從而妨礙了概念上的完整性;它使所有離散出口難以尋找和控制;它引起了大量學習和理解上的負擔，使開發慢慢演變成了一場災難。
一致性
他必須控制的很多複雜度是隨心所欲、毫無規則可言的，來自若干必須遵循的人為慣例和系統。
可變性
系統中的軟體包含了很多功能，而功能是最容易感受變更壓力的部分。另外的原因是因為軟體可以很容易地進行修改——它是純粹思維活動的產物，可以無限擴充套件。
軟體必須與各種新生事物保持一致。
不可見性
軟體是不可見的和無法視覺化的。
軟體的客觀存在不具有空間的形體特徵。
以往解決次要困難的一些突破
高階語言。
大多數觀察者相信開發生產率至少提高了五倍，同時可靠性、簡潔性和理解程度也大為提高。
分時。
統一程式設計環境。提供整合庫、統一檔案格式、管道和過濾器。
銀彈的希望
Ada和其他高階程式語言。
面向物件程式設計。
抽象資料型別的概念是指物件型別應該通過一個名稱、一系列合適的值和操作來定義，而不是理應被隱藏的儲存結構。
層次化型別，是允許定義可以被後續子型別精化的通用介面。這兩個概念是互不相干的——可以只有層次化，沒有資料隱藏;也可能是隻有資料隱藏，而沒有層次化。
人工智慧。
專家系統。專家系統是包含歸納推論引擎和規則基礎的程式，它接收輸入資料和假設條件，通過從基礎規則推導邏輯結果，提出結論和建議，向用戶展示前因後果，並解釋最終的結果。
如何把它應用在軟體開發工作中?可以通過很多途徑:建議介面規則、制訂測試策略、記錄各種bug產生的頻率、提供優化建議等等。
最優秀和一般的軟體工程實踐之間的差距是非常大的，可能比其他工程領域中的差距都要大。
“自動”程式設計。
圖形化程式設計。
程式驗證。程式驗證不意味著零缺陷的程式。
環境和工具。特定語言的智慧化編輯器在現實中還沒有得到廣泛應用，不過它們最有希望實現的是消除語法錯誤和簡單的語義錯誤。
工作站。
針對概念上根本問題的頗具前途的方法
工作的創造性部分佔據了大部分時間，那麼那些僅僅是表達概念的活動並不能在很大程度上影響生產率。
購買和自行開發。構建軟體最可能的徹底解決方案是不開發任何軟體。
需求精煉和快速原型。開發軟體系統的過程中，最困難的部分是確切地決定搭建什麼樣的系統。
軟體開發人員為客戶所承擔的最重要的職能是不斷重複地抽取和細化產品的需求。事實上，客戶不知道他們自己需要什麼。
計劃任何軟體活動時，要讓客戶和設計人員之間進行多次廣泛的交流溝通，並將其作為系統定義的一部分。這是非常必要的。
原型的目的是明確實際的概念結構，從而客戶可以測試一致性和可用性。
增量開發——增長，而非搭建系統。
卓越的設計人員。
低劣設計和良好設計之間的區別可能在於設計方法中的完善性，而良好設計和卓越設計之間的區別肯定不是如此。卓越設計來自卓越的設計人員。軟體開發是一個創造性的過程。完備的方法學可以培養和釋放創造性的思維，但它無法孕育或激發創造性的過程。
非常卓越的設計者產生的成果更快、更小、更簡單、更優雅，實現的代價更少。卓越和一般之間的差異接近於一個數量級。
可以著手的最重要工作是尋求培養卓越設計人員的途徑。
20年後的人月神話
7.
“軟體專案管理更加類似於其他型別的管理。”
這給我們學習、研究軟體專案管理提供了一個很好的思路，我們可以通過挖掘它與其他型別的管理之間的相似點，通過學習其他型別的管理來對軟體專案的管理提供幫助。
8．
“體系結構的遞迴。”“”有必要由一位主結構師把系統分解成子系統，系統邊界應該劃分在使子系統間介面最小化和最容易嚴格定義的地方。“
這是非常有價值的體系結構的分解思路，把大的系統分解成子系統，並且值得注意的是子系統的邊界如何劃定是一個很關鍵的點。這對我們以後分解系統進行體系結果設計提供了指導性思想，這也是《人月神話》這本書20年後還依然如此毫不過時的重要原因，它其中的思想放到現在仍然適用。