第一章：焦油坑
程式設計行業「滿足我們內心深處的創造渴望和愉悅所有人的共有情感」，提供了五種
樂趣：建立事物的快樂
本書第一章就明確的講述了程式設計職業的樂趣，無論是建立事物的樂趣，還是簡單學習的樂趣，還是駕馭介質之上的樂趣，還是開發了對人類有用的產品的樂趣等等。這些是每乙個程式設計人或多或少都會體會到的樂趣。書中的一句話，我就體會尤為深刻：對於程式設計人員而言，對其他的依賴是一件非常痛苦的事情。這使我想起之前自己入門的時候，不會自己動手，也不會嘗試的去解決自己的問題，只會依靠大佬，尋求他的幫助，只要有bug,就會第一時間想到尋求他人。只有自己真正地走出那一步，真正地自我完成或者解決乙個問題之後，這樣才會有很大的收穫。現在的我感覺就在不斷地成長一樣，即便有點緩慢，但是我深知那才是真正屬於我自己的東西。之後我會盡量的學會自己去解決問題，然後有目的性的去尋求幫助，有目的性的去學習。
面對不重複的任務，不間斷學習的樂趣//學習總是充滿了樂趣 說明你還是熱愛這個領域的
工作在如此易於駕馭的介質上的樂趣——純粹的思維活動，其存在、移動和運轉方式完全不同於實際物體。
同樣，這個行業具有一些內在固有的苦惱：
將做事方式調整到追求完美，是學習程式設計的最困難部分
由其他人來設定目標，並且必須依靠自己無法控制的事物（特別是程式）；權威不等同於責任
實際情況看起來要比這一點好一些：真正的權威來自於每次任務的完成
任何創造性活動都伴隨著枯燥艱苦的勞動，程式設計也不例外
人們通常期望專案在接近結束時，（bug、工作時間）能收斂得快一些，然而軟體專案的情況卻是越接近完成，收斂得越慢（感同身受，對於想要盡快完成的任務往往越想越慢，還是要靜下心來慢慢思考，保持之前的速度，心靜下來，我就是比較毛躁的乙個人，遇到事情容易慌張，我希望我自己可以改掉這個毛病，於是冷靜，遇到最後的關頭越要冷靜）
產品在即將完成時總面臨著陳舊過時的威脅
第二章人月神話
1. 缺乏合理的時間進度是造成專案滯後的最主要原因，它比其他所有因素加起來影響還大。
2.書中說所有的程式設計人員都是樂觀主義
3. 我們的構思是有缺陷的，因此總會有bug。（對於bug來說我遇到問題會想到自己解決，但是自己抵禦軟體跟程式設計的知識有限**中的bug會越來越亂，自己的信心會越來越少）
4. 我們圍繞成本核算的估計技術，混淆了工作量和專案進展。人月是危險和帶有欺騙性的神話，因為它暗示人員數量和時間是可以相互替換的。
5. 在若干人員中分解任務會引發額外的溝通工作量——培訓和相互溝通。
6. 關於進度安排，作者的經驗是為1/3計畫、1/6編碼、1/4構件測試以及1/4系統測試。
7. 因為我們對自己的估計技術不確定，所以在管理和客戶的壓力下，我們常常缺乏堅持的勇氣。（對於老師的壓迫，我們往往是抱著反抗，並沒有積極的去面對我們應該積極的面對而不是去埋怨去抱怨，這是提公升自己的乙個很好的機會）
8. brook法則：向進度落後的專案中增加人手，只會使進度更加落後。brooks法則，人月神話一文的核心觀點
9. 如何使得專案進度不落後；要想使得專案進度不落後，就要制定出合理的專案進度。
第3章外科手術隊伍同樣有兩年經驗而且在受到同樣的培訓的情況下，優秀的專業程式設計師的工作效率是較差程式設計師的十倍。小型、精幹隊伍是最好的——盡可能的少。自己就是寫**的效率很低，可能感覺自己不是不會寫，只是自己的馬虎使一很小的問題導致程式的不執行，我找錯誤的時候心急，可能忽略的東西變很多，我還是需要增加我的耐心跟堅持能力，相信會變得很強大；對於真正意義上的大型系統，小型精幹的隊伍太慢了。 兩個人的團隊，其中乙個專案經理，常常是最佳的人員使用方法實際上，絕大多數大型程式設計系統的經驗顯示出，一擁而上的開發方法是高成本、速度緩慢、不充分的，開發出的產品無法進行概念上的整合。兩個人的團隊往往會進行互補，相互修補；才會互贏；
一位首席程式設計師、類似於外科手術隊伍的團隊架構提供了一種方法——既能獲得由少數頭腦產生的產品完整性，又能得到多位協助人員的總體生產率，還徹底地減少了溝通的工作量。
概念完整性是系統設計中最重要的考慮因素。 為了獲得概念完整性，設計必須由乙個人或者具有共識的小型團隊來完成。對於非常大型的專案，將設計方法、體系結構方面的工作與具體實現相分離是獲得概念完整性的強有力方法。紀律、規則對行業是有益的。外部的體系結構規定實際上是增強，而不是限制實現小組的創造性。 體系結構、設計實現、物理實現的許多任務作可以併發進行。
盡早交流和持續溝通能使結構師有較好的成本意識，以及使開發人員獲得對設計的信心，並且不會混淆各自的責任分工。 結構師如何成功地影響實現： 牢記是開發人員承擔創造性的實現責任；結構師只能提出建議。聽取開發人員在體系結構上改進的建議。第二個系統是人們所設計的最危險的系統，通常的傾向是過分地進行設計。關於這一點也許是正確的，但是這是乙個迴避不了的問題，如果沒有開發第二個系統經驗的人，就不可能有開發第三個系統經驗的人了。對於自己所分配到任務需要及時跟自己組內的人進行溝通，可能兩個或多個人的溝通可以有效的解決你們之間所遺留依舊的問題，是我們的任務可以更加的完善！
人月神話閱讀筆記01
本週讀了 人月神話 中的 焦油坑 和 人月神話 兩個章節，現來看看我的認識與理解。我們做專案應該滿足目標 時間進度 和預算的要求，這樣才能夠最大程度上避免陷入焦油坑中。新聞中有多兩個人在車庫中完成了大量的重要程式，其實我們應全面的看待這樣的神話。編寫陳偉乙個變成產品和程式設計系統需要編寫乙個程式的三...
人月神話閱讀筆記01
本篇閱讀筆記是我對於 人月神話 一書中中關於團隊擴建的感悟。開發團隊在很多方面滿足了迫切性的需要。十個人，其中七個專業人士在解決問題，而系統是一乙個人或者最多兩個人思考的產物，因此客觀上達到了概念的一致性。要特別注意傳統的兩人隊伍與外科醫生副手隊伍架構之間的區別。首先，傳統的團隊將工作進行劃分，每人...
人月神話閱讀筆記01
在眾多軟體專案中，缺乏合理的時間進度是造成專案滯後的最主要原因，它比其他所有因素加起來的影響還大。原因 我們對估算技術缺乏有效的研究，更加嚴肅地說，它反映了一種悄無聲息，但並不真實的假設 一切都將運作良好。第二，我們採用的估算技術隱含地假設人和月可以互換，錯誤地將進度與工作量相互混淆 第三，由於對自...