核心：概念的完整性

1、缺乏合理的時間進度是造成項目滯後的最主要原因，他比其他的所有因素的綜總和影響都大

2、關於進度安排，作者的建議：1/3計劃、1/6 編碼、1/4構件測試以及1/4系統測試

3、小型、精幹的隊伍是最好的--思緒盡可能的少

4、對於真正意義上的大型系統，小型精幹的隊伍太慢了

5、概念的完整性是系統設計中最重要的考慮因素

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

7、對於非常大型的項目，將體系結構方面的工作和具體實現相分離是獲得概念完整性的強有力方法

8、紀律、規則對行業是有益的

9、盡早的交流和持續的溝通能使設計人員有較好的成本意識，是開發人員獲得對系統的信心，並且不會混淆各自的責任分工

10、即使是大型的設計團隊，設計結果也必須由一個或者兩個人來完成，以確保這些決定是一致的（作者默認設計人員的優異性是不可或缺的）

11、需要盡可能的將設計思想，用形式化的方式表現（文檔的不可或缺性）

12、項目的失敗很有可能是缺少交流或者是交流的結果------組織

13、團隊應該以盡可能的多的方式進行相互之間的交流，非正式地進行簡要的技術稱述的常規項目會議，共享正式的項目工作手冊

14、實時更新手冊是必要的

15、每一個人員都應該能看到應有的手冊內容

16、

17、項目經理的職責是使每一個人往一個方向前進

18、增量式開發-，快速原型--漸進的精化（這個就和敏捷開發的思想有點像了）

19、開發人員交付的是用戶滿意程度，而不僅僅是實際的產品

20、程序員不願意為設計書寫文檔，不僅僅是因為惰性，更多的是源於設計人員的躊躇------要為自己嘗試性的設計決策進行辯解。

21、學會使用更好的語言和設計理念

22、自上而下的設計能更好的保證設計的完整性

禍起蕭墻

1、一個嚴格的進度表來控制大型項目的第一步驟是制定一個進度表，包括日期和具體的，特定的，可以量化的事件

2、如果裏程碑定義的非常明確，以至於無法自欺欺人是，程序員很少會就裏程碑的進展弄虛作假

文檔

1、對於軟件編程產品來說，程序向用戶所呈現的面貌---文檔，與提供給幾區識別的內容同樣重要

2、文檔的形式不是一定要求正式的，為了文檔的易於維護，將他們合並到源程序是至關重要的，而不是作為獨立文檔而存在

　　很難相信作者能再1957就找到後世繼續享用的精華，作者的長遠實在令人敬佩

　　出入Java江湖的小白，這本書的大部分內容都還不太懂，不過也發現許多很受益的建議，有很多看似很小，確能帶來良好的收益。

　　相信以後再來看此書，又是另一個莎士比亞

人月神話--摘點