推薦一本書，叫《人月神話》。
全書分為20章，作者是布魯克斯，這本書講述了作者在ibm公司做大型軟體系統os專案經理時的實踐經驗。
布魯克斯這哥們是美國人，是博士，也是教授，在ibm做過事，還得過圖靈獎，是個牛人。
此書讀來令人拍案叫絕，驚嘆不已，五體投地，感覺不讀此書真是人生虛度。（**開頭法，逼格滿滿，代入感賊強）
一句話概括全書內容：人是程式設計師，月是時間，，如果10人幹1個月如果等同1人幹10個月那就成神話，即10人幹1個月的軟體工程進度是恆小於1個人幹10個月的。
解釋：假設每個人一天的工作量恆定，那麼10個人幹1個月的工作量是等於1個人幹10個月的。但是這十個人之間需要交流，進度會下降不少。
其實一切的根源就是我們軟體造的越來越大，大到像王者榮耀那樣（幾百萬行源**，還只是源**），我們人類乙個人的資訊流根本無法掌控。這種趨勢是無法避免的，所以軟體危機也是無法避免的。畢竟你企業想要掙到錢，就得弄出拿得出手的軟體，要是靠著乙個不到一萬行的軟體，是沒前途的。
不喜歡廢話，自己寫的部落格是為了自己看的，寫那麼多廢話有個p用。
第1章 焦油坑
1.1 程式設計系統產品
做大型軟體開發就好比乙個焦油坑。
表面上看起來好像沒有任何乙個單獨的問題會導致困難，每個都能被解決，但是當它們相互糾纏和累積在一起的時候，團隊的行動就會變得越來越慢且很難看清問題的本質。
沒試過團隊合作，不過自己寫軟體的時候，如果不是按照一定的章法來寫，確實會越來越迷糊。
1.3 職業的苦惱
第2章 人月神話
2.1 樂觀主義
2.2 人月
①.brook法則：向進度落後的專案中增加人手，只會使進度更加落後。所以在現實情況中，一旦開發團隊觀察到進度的偏差，總是傾向於對任務進行削減。
②.不為系統測試安排足夠的時間簡直就是一場catastrophe。
2.4 空泛的估算
2.5 重複產生的進度災難
第3章 外科手術隊伍
3.1 問題
3.2 mills的建議
外科手術型隊伍：小型，精英組成的團隊。
專案程序中，個人溝通的花銷是巨大的。
為了減少溝通，mills建議，大型專案的每乙個部分由乙個團隊解決，該隊伍以類似外科手術的方式組建。
這樣，每個團隊的代表和首席架構師交流，每個團隊內部交流，有效地減少了溝通。
3.4 團隊的擴建
第4章 貴族**、民主政治和系統設計
4.1 概念的完整性
4.2 獲得概念的完整性
這章整到政治上了，拿政治的不同進行對比，看的雲裡霧裡的。4.4 在等待時，實現人員應該做什麼
第5章 畫蛇添足
5.1 結構師的互動準則和機制
這章是對架構師的忠告。
不要向系統新增很多無謂的功能
把成本高的功能削減設計或者換成成本更低的實現方法，如果有時間限制的話。
第6章 貫徹執行
6.1 文件化的規格說明-手冊
6.2 形式化定義
6.3 直接整合
6.4 會議和大會
對於開發團隊來說，實現人員有疑問時應詢問相應的架構師，而不是一邊自行猜測一邊工作。
即使是大型的設計團隊，設計結果也必須由乙個或兩個人來完成，以確保這些決定是一致的。
6.6 **日誌
6.7 產品測試
第7章 為什麼巴別塔會失敗
巴比倫塔專案的失敗是因為缺乏交流和組織。
每個人或多或少地更改一下規章輸入輸出，就會給其他人的整合帶來要命的麻煩。
7.2 大型程式設計專案中的交流
7.3 專案工作手冊
7.4 大型程式設計專案的組織架構
第8章 胸有成竹
如何做到胸有成竹，要知道以下資訊？
做出整體所需要的時間是要遠遠大於分別作出部分需要的時間之和的，越大的工程整合時間越長。
在公司中，要完成乙個專案，你只有一半的時間來編寫和除錯**。
8.2 aron的資料
8.3 harr的資料
8.4 os/360的資料
8.5 corbato的資料
第9章 削足適履
這章說了乙個現象，團隊中，各個小組傾向於不斷地區域性優化，以滿足自己的目標，而較少考慮隊使用者的整體影響。
我們要從系統整體出發來程式設計。
9.2 規模控制
9.3 空間技能
9.4 資料的表現形式是程式設計的根本
第10章 提綱挈領
10.1 計算機產品的文件
10.2 大學科系的文件
10.3 軟體專案的文件
這章講了文件在開發中的重要性，有著指引團隊方向，規範時間的作用。第11章 未雨綢繆
11.1 試驗性工廠和增大規模
11.2 惟一不變的就是變化本身
11.3 為變更計畫系統
11.4 為變更計畫組織架構
廢話。。。
目標上的一些正常變化無可避免，事先為它們做準備總比假設它們不會出現要好得多。
11.6 前進一步，後退一步
第12章 干將莫邪
12.1 目標機器
12.2 輔助機器和資料服務
12.3 高階語言和互動式程式設計
第13章 整體部分
13.1剔除bug的設計
13.2 構件單元除錯
13.3 系統整合除錯
第14章 禍起蕭牆
14.1 里程碑還是沉重的負擔
可以在專案開發過程中弄乙個里程碑，也就是deadline,這樣會更有幹勁14.3 地毯的下面
第15章 另外一面
15.1 需要什麼樣的文件
15.2 流程圖
15.3 自文件化的程式
第16章 沒有銀彈-軟體工程中的根本和次要問題
16.1 摘要
16.2 介紹
16.3 是否一定那麼困難呢？-根本困難
16.4 以往解決次要困難的一些突破
16.5 銀彈的希望
16.6 針對概念上根本問題的頗具前途的方法
第17章 再論「沒有銀彈」
17.1 人狼和其他恐怖傳說
17.2 存在著銀彈-就在這裡！
17.3 含糊的表達將會導致誤解
17.4 harel的分析
17.5 jones的觀點-質量帶來生產率 //沒感想，無聊~~
17.6 那麼，生產率的情形如何
17.7 物件導向程式設計-這顆銅質子彈可以嗎
17.8 重用的情況怎樣
17.9 學習大量的詞彙-對軟體重用的乙個可預見，但還沒有被預言的問題
17.10 子彈的本質-形勢沒有發生改變
推薦一本書 《如何閱讀一本書》
讀書是一門藝術 多馬 正是秉持著這一 自由教育 的理念，阿德勒在他最著名的作品 如何閱讀一本書 獲得自由教育的技藝 how to read a book the art of getting a liberal education 進行了最充分的闡釋。我手上的這本商務印書館出版的中譯本 郝明義 朱衣...
推薦一本書《西方的沒落》
這真是一本好書。文中提到 文化誕生之後，其發展工作大體相同。都是由春而至夏秋，最後到冬季。沒有一種文化能避免其衰老的命運。對此，我想 那麼，一種文化是否有強大的生命力，不僅在於春天的綻放，夏天的繁茂，也在於秋天的收斂，冬天的閉藏。在寒冬裡能否將生機完全斂藏以待春天來臨，是至關緊要的問題。若不能，則生...
如何閱讀一本書 pdf 如何快速閱讀一本書？
在 脫口秀大會 上圈粉無數的北大 最土 女生李雪琴，最近又火了，才華橫溢，說出來的梗有邏輯又搞笑，不得不讓人佩服，不難想象，出口成章的實力一定源於大量的輸入，會讀書的人真的很可怕。之前總是看到一些自律達人，一年讀1000本書，引經據典，信手拈來，這樣的人好像自帶光芒，作為普通人的我們心想自己為啥立下...