【最後的總結】人月神話讀後感

人月神話讀後感

 　　這本300多頁（中文新版）的神書，在通過了20多年的歷史以後，仍然暢銷不衰，到底是什麼讓它有如此的魅力？過去的一個月，一點一滴的閱讀之中算是初步的瞭解到了它的一部分吧。

人月神話的核心觀點：概念完整性和架構師

　　Brooks認爲，一個整潔、優雅的變成產品必須向它的每位用戶提供一個條理分明的概念模型，這個模型描述了應用，實現應用的方法以及用來指明操做和各類參數的用戶界面使用策略。概念的完整性是易用性中最重要的因素。而架構師，則是負責保證產品全部方面的概念完整性的，架構師設計的是可以讓用戶理解產品概念的模型，這包括全部的功能的詳細說明以及調用和控制的方法。它就像電影的導演同樣。

　　個人理解：這裏的概念完整性其實應該說的是這個軟件理念上的業務流程的先後連貫，也就是用戶在使用產品的過程當中，可以按照惟一的一個的最高抽象的思路來使用這整個系統。

開發第二個系統的後果——盲目的功能和頻率猜想

　　所謂第二個系統，指的是產品的第二個實際發佈。開發第一個發佈的時候會由於各類緣由去消減沒必要須的功能，因此會簡化問題，而在第二個版本的時候則經常想其中添加各類各樣的功能（也許源於用戶的功能建議）可是，卻致使了災難性的後果。

　　因此，在這種狀況下，用戶羣越大，越不穩定，咱們就更加應該明確的定義用戶羣，以得到概念的完整性。咱們必須爲整個設計團隊定義一個共同的用戶圖像，記錄下用戶羣的屬性：

1. 他們是誰 
2. 他們need什麼 
3. 他們認爲本身need什麼 
4. 他們want什麼

而另外一方面，對於任何產品，任何用戶羣屬性都是一種機率上的分佈的，也就是每一個屬性都有各類可能的值，因此咱們能作的是，架構師去猜想（guess）或者假設（postulate）一系列完整的屬性和頻率值。這裏，清晰和錯誤都將比模糊不清好得多。

不一樣的社會經驗，不一樣的思想狀態，對讀後的心得也會不同.好比：

1. 外科手術隊伍The Surgical Team 項目經理在項目的初期必須清楚的估計項目的人月運做模式（時間、人力在項目各階段的分配），例如何時須要出什麼樣成果，決定了何時須要什麼樣的人加入項目，這是項目經理的責任。
2. 如何才能與實現人員就技術說明的瑣碎細節充分溝通，以確保設計被正確地理解，並精確地整合到產品中。
3. 貫徹執行Passing the word 印象比較深入的是」體系結構設計人員必須爲本身描述的任何特性準備一種實現方法，但他不該該支配具體的實現過程。」 
4. 成竹在胸Calling the Shot 主要講述如何計算編程時間，以及提出幾我的的經驗算法。 講述的各類算法可能都不太適合與如今的高級語言，但Portman的觀點仍然適合如今，即編程人員實際的編程時間只有50％，其餘的時間都花在了無關的瑣碎事情上。
5. 總體部分The Whole and the Parts 一讀這一章，就讓我感觸頗深，特別是這句話」BELL實驗室監控系統項目的V.A.Vyssotsky提出，’關鍵的工做是產品定義。許許多多的失敗徹底源於那些產品未精肯定義的地方’，細緻的功能定義，詳細的規格說明，規範話的功能描述說明以及這些方法的實施，大大減小了系統中必須查找的BUG數量」。雖然這句話的意思只是說明精肯定義產品將減小BUG的數量，但我看到了系統分析的最重要的工做——產品定義。如今，許多 開發人員嘴裏口口聲聲說也作過需求調研、系統分析、系統設計，但大多數沒有涉及到產品定義的深度，嚴格意義上不能叫作系統分析。這句話對個人之後想從事系統分析工做有很大的幫助。 這一章餘下的內容，也值得一看，雖然有些地方有些過期，但剔除BUG的設計以及部分測試/調試方法仍值得一看。