本次閱讀了該書最後幾章，我發現《人月神話》只是順便講講軟體而已，大部分內容全是關於團隊，人類歷史是乙個舞台，總是上演著相同的故事。隨著文化的發展，這些故事的劇本變化非常緩慢，而舞台的布局卻在隨時改變。正是如此，我們發現二十世紀本身會反映在莎士比亞、荷馬的作品和聖經中。因此，某種程度上，《人月神話》是關於人與團隊的書，所以它的淘汰過程會是緩慢的。
我想這也是《人月神話》這本書的成功之處吧。我漸漸開始思考乙個問題，到底什麼是人月神話？或許答案是：乙個程式讓vczh一年剛好可以寫出來，但是你如果找到了12個vczh同時寫，乙個月肯定是寫不出來的。人和月是兩個單位，人月自然是它們相乘了，神話的意思就是說，這兩個量是不能乘的。12個他可能會為了選方案吵起來，這樣就需要多於一年的時間才能寫完。也可能誰都不服誰跑去單幹各自用一年做出12個來。這對我有了極大啟發。
最後想談一下本書極為重要的乙個觀點：概念完整性。乙個整潔、優雅的程式設計產品必須向它的每個使用者提供乙個條理分明的概念模型，這個模型描述了應用、實現應用的方法以及用來指明操作和各種引數的使用者介面使用策略，。使用者所感受到的產品概念完整性是易用性中最重要的因素。（當然還有其他因素。macintosh 上所有應用程式介面的統一就是乙個重要的例子。此外，有可能建立統一的介面，儘管它可能很粗糙，就像 ms-dos。）
有很多由乙個或者兩個人設計的優秀軟體產品例子。大多數純智力作品，像書籍、音- 154 - 樂等都是採用這種方式創作出來的。不過，很多產業的產品開發過程無法負擔這種獲取概念完整性的直接方法。競爭帶來了壓力，很多現代工藝的最終產品是非常複雜的，它們的設計需要很多人月的工作量。軟體產品十分複雜，在進度上的競爭也異常激烈。
任何規模很大或者非常緊急，並需要很多人力的專案，都會碰到乙個特別的困難：必須由很多人來設計，但與此同時，還需要在概念上保持與單個使用人員的一致。如何組織設計隊伍來獲得上述的概念一致性？這是《人月神話》關注的主要問題。其中一點：由於參與人數的不同，大型程式設計專案的管理與小型專案在性質上都不同。為了獲得一致性，經過深思熟慮的，有時甚至是英勇的管理活動是完全必要的。
人月神話閱讀筆記03
人月神話拜讀完了，真的感覺學到了很多，受益匪淺，書開始就形象有有趣的把軟體危機比作 焦油坑，交流至關重要，實踐是最好的老師，文件撰寫是軟體人的必修課，這本書讓我們對軟體工程有了更深一步的理解，有了全新的認識，軟體工程焦油坑在相當長時間內仍會存在，我們必須努力學習，不斷創新，獲得更大的進步。一 我過去...
人月神話閱讀筆記03
今天我閱讀的是貫徹執行一節。假設乙個專案經理已經擁有行事規範的結構師和許多程式設計實現人員，那麼他如何確保每個人聽從 理解並實現結構師的決策？對於乙個由 1000 人開發的系統，乙個 10 個結構師 的小組如何保持系統概念上的完整性？首先要有文件化的規格說明，即手冊。手冊或者書面規格說明，是乙個非常...
人月神話閱讀筆記03
人狼這種民間傳說中存在的怪物，會在月圓之夜由我們熟悉的人類面孔變成可怕的狼臉。我們熟悉的軟體專案也有著人狼的特性，看似簡單明瞭的外表，但是卻可能隨時變成乙個進度落後 超出預算 存在大量缺陷的怪物。在民間傳說中對付人狼唯一可靠的 就是銀彈。所以銀彈在軟體專案中就是比喻這種使得軟體成本像計算機硬體成本一...