人月神話讀書筆記

人數和時間的互換僅僅適用於以下情況：某個任務可以分解給參與人員，並且他們之間不需要相互的交流。

當任務由於次序上的限制不能分解時，人手的新增對進度沒有幫助。

溝通所增加的負擔由兩個部分組成，培訓和相互的交流。

相互之間交流的情況更糟一些。如果任務的每個部分必須分別和其他部分單獨協作，則工作量按照n(n - 1) / 2遞增。

因為軟體開發本質上是一項系統工作----錯綜複雜關係下的一種實踐----溝通、交流的工作量非常大，它很快會消耗任務分解所節省下來的個人時間。從而，新增更多的人手，實際上是延長了，而不是縮短了時間進度。

對於軟體任務的進度安排，以下是我使用了很多年的經驗法則：

1/3 計畫；

1/6 編碼；

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

1/4 系統測試

向進度落後的專案中增加人手，只會使進度更加落後。

體系結構陳述的是發生了什麼，而實現描述的是如何實現。

實際上，產品的成本效能比很大程式上依靠實現人員，就如同易用性很大程式上依賴結構師一樣。

規格說明的風格必須清晰、完整和準確。使用者常常會單獨提到某個定義，所以每條說明都必須重複所有的基本要素，所以所有的文字都要相互一致。這往往使手冊讀起來枯燥乏味，但是精確比生動更加重要。

決不要攜帶兩個時鐘出海，帶乙個或三個。

團隊組織的目的是減少不必要交流和合作的資料。

減少交流的方法是人力劃分和限定職責範圍。當使用人力劃分和職責限定時，樹狀管理結構所映出對詳細交流的需要會相應減少。

技術主管角色是什麼：他對設計進行構思，識別系統的子部分，指明從外部看上去的樣子，勾畫它的內部結構。他提供整個設計的一致性和概念完整性；他控制系統的複雜程式。當某個技術問題出現時，他提供問題的解決方案，或者根據需要調整系統設計。

產品負責人作為總指揮，技術主管充當其左右手。這種方法有一些困難。很難在技術主管不參與任何管理工作的同時，建立在技術決策上的權威。

交流和交流的結果---組織，是成功的關鍵。交流和組織的技能需要管理者仔細考慮，相關經驗的積累和能力的提高同軟體技術本身一樣重要。

非常少的互動：乙個一年大約能寫10，000行**。少量互動：5000行；較多互動：1500。

資料的表現形式是程式設計的根本。

創造出自精湛的技藝，精煉、充分和快速的程式也是如此。技藝改進的結果往往是戰略上的突破，而不僅僅是技巧上的提高。

任何管理任務的關注焦點都是：時間、地點、人物、做什麼、資金。

程式維護中的乙個基本問題是---缺陷修改總會以（20-50）%的機率引入新的bug。所以整個過程是前進兩步，後退一步。

系統軟體開發是減少混亂度的過程，所以它本身處於亞穩態的。軟體維護是提高混亂度的過程，即使是最熟練的軟體維護工作，也只是放緩了系統退化到非穩態的過程。

a good workman is known by his tools.

現實在，流程圖被鼓吹的程式遠大於它們的實際作用。我從來沒有看到過乙個有經驗的程式設計人員，在開始編寫程式之前，會例行公事地繪製詳盡的流程圖。

良好的烹飪需要時間，某些任務無法在不損害結果的情況下加快速度。

所有的程式設計人員都是樂觀主義：一切都將動作良好。

同樣有兩年經驗而且在受到同樣的培訓的情況下，優秀的專業程式設計師的工作效率是較差程式設計師的十倍。

兩個人的團隊，其中乙個專案經理，常常是最佳的人員使用方法。

為了獲得概念完整性，設計必須由乙個人或者具有共識的小型團隊來完成。

團隊組織的目標是為了減少必要的交流和協作量。

精煉、充分和快速的程式。往往是戰略性突破的結果，而不僅僅技巧上提高。這種突破常常是一種新型演算法。更普遍的是，戰略上突破常來自於資料或表的重新表達。資料的表現形式是程式設計的根本。

程式設計師不願意為設計書寫文件的原因，不僅僅是由於惰性。更多的是源於設計人員的躊躇----要為自己嘗試性設計決策時行辯解。