1，保持設計的概念完整。無論對小軟體還是大軟體，都必須由乙個設計師主導，最多兩個人討論來共同完成軟體的整體設計。
2，「乙個拿2倍工資的人，生產率可能是其他人的10倍。」
3，進度落後與增加人力。「向進度落後的專案中增加人手，只會使進度更加落後」。「十個婦女不能在乙個月內生下小孩」
不同的社會經驗，不同的思想狀態，對讀本書的心得也不一樣，我在此說說我的讀後感，書中有許多非常好的觀點，但我只把我感觸最深的寫下來。 這確實是一本很值得多次閱讀的好書，每次閱讀可能都能從中得到一些提示。
1.外科手術隊伍the surgical team
專案經理在專案的初期必須清楚的估計專案的人月運作模式（時間、人力在專案各階段的分配），例如什麼時候需要出什麼樣成果，決定了什麼時候需要什麼樣的人加入專案，這是專案經理的責任。
2.貴族**，民主政治aristocracy,democracy,system
要獲得概念的完整性，設計必須由乙個人或具有共識的小組來完成。
有四個問題：
1。如何得到概念的完整性
2。是否要有一位傑出的精英，或者說是結構設計師的貴族**.....
3.如何避免結構設計師產出無法實現或代價高昂的技術規格說明，使大家陷入困境。
4。如何才能與實現人員就技術說明的瑣碎細節充分溝通，以確保設計被正確地理解，並精確地整合到產品中。
對1。2。4的回答基本上都可以找到，但第3個似乎找不到。
3.畫蛇添足the second-system effect
講述的基本都是基於ibm 360作業系統以及編譯程式等方面的經驗，講述如何避免開發第二個系統的風險，作者認為開發第二個系統的設計師設計出來的系統是最危險的,因此要求他們自律。
4.貫徹執行passing the word
印象比較深刻的是"體系結構設計人員必須為自己描述的任何特性準備一種實現方法，但他不應該支配具體的實現過程。"
5.為什麼巴比倫塔會失敗why did the tower of babel fail?
講述巴比倫塔會失敗的原因是缺乏交流。
6.胸有成竹calling the shot
主要講述如何計算程式設計時間，以及提出幾個人的經驗演算法。
講述的各種演算法可能都不太適合與現在的高階語言，但portman的觀點仍然適合現在，即程式設計人員實際的程式設計時間只有50%，其他的時間都花在了無關的瑣碎事情上。
7.削足適履ten pounds in a five-pound sack
主要講述程式占用的空間等，在70年代比較突出，但現在好多了。
8.提綱擎領the documentary hypothesis
說明文件的作用
9.未雨綢繆plan to throw one away
唯一不變的是變化本身。
在大型專案中，專案經理需要有兩個和三個頂級程式設計師作為技術輕騎兵，當工作繁忙最密集的時候，他們能急馳飛奔，解決各種問題。 講述技術人員與專案人員的互換是，對我有一定的提示，但圖中ibm的兩條職位晉公升線，不太理解。
10.干將莫邪sharp tools
主要講述專案中管理好各種工具的重要性，專案經理首先要制定一種策略，讓各種工具成為公用的工具，這樣才能使開發、維護和使用這種工具的開發人員的效率更高，這種工具可能是開發人員開發出來的，也可能是使用現有的，可能是通用的，也可能是專用的或個人偏好的。比如：文件編寫工具、開發工具（包括各種不同開發平台）、除錯工具、測試工具、資料庫工具、版本管理、專案管理工具等。
11.整體部分the whole and the parts
一讀這一章，就讓我感觸頗深，特別是這句話"bell實驗室監控系統專案的v.a.vyssotsky提出,'關鍵的工作是產品定義。許許多多的失敗完全源於那些產品未精確定義的地方',細緻的功能定義，詳細的規格說明，規範話的功能描述說明以及這些方法的實施，大大減少了系統中必須查詢的bug數量"。雖然這句話的意思只是說明精確定義產品將減少bug的數量，但我看到了系統分析的最重要的工作——產品定義。現在，許多 開發人員嘴裡口口聲聲說也做過需求調研、系統分析、系統設計，但大多數沒有涉及到產品定義的深度，嚴格意義上不能叫做系統分析。這句話對我的以後想從事系統分析工作有很大的幫助。
這一章餘下的內容，也值得一看，雖然有些地方有些過時，但剔除bug的設計以及部分測試/除錯方法仍值得一看。
12.禍起蕭牆hatching a catastrophe
這章節說明使專案進度拖後的最大原因不是重要的事件，如新技術、重組等，而是一些瑣碎的小事，每件小事只耽誤半天或一天時間，但這種小事多以後，將使專案的進度嚴重拖後。
專案對於公司就如程式對測試工程師一樣，如果不了解它，它就是乙個黑盒子，如果不開啟這個黑盒子，你可能永遠不知道盒子裡面有什麼。
這部分描寫專案經理以及小組主管的一些心理，值得一看。
13.另外一面the other face
本章說明程式的另一面——文件。
不了解，就無法真正擁有——歌德，作者引用的歌德的話來描述文件對客戶的重要性，提出客戶需要什麼樣的文件以及文件的格式和包含的內容，指出當時存在的大多數文件只描述了樹木，形容了樹葉，但沒有整個森林的圖案。
想想，這種情況在現在仍然沒有改變。於是作者提出了兩個觀點：
1.流程圖：流程圖是被吹捧得最過分的一種程式文件。許多程式甚至不需要流程圖，很少程式需要一頁以上的流程圖
2.自文件化（self-documenting）的程式：提出文件與程式合為一體，能很好的解決文件與程式分開造成的文件過時的問題，並說明了在程式中加入文件的一些方法和技巧。2023年，我看到一位網友關於文件與程式合一的文章，當時就覺得是個好方法，沒想到70年代，老美已經提出來了。
14.沒有銀彈-軟體工程中的根本和次要問題(no silver bullet-essence and accident in software engineering)
這是一篇**，發表於2023年,我自認為我的理論水平沒有上公升到可以對他的論點和論據做出懷疑或質疑的結論，我只是說說我的感想。
人狼是傳說中的妖怪，只有銀彈才能殺死他。作者認為軟體專案具有人狼的特性，因為軟體專案也可能變成乙個怪物，乙個落後進度、超出預算、存在大量缺陷的怪物。
作者通過軟體系統的內在特性複雜性、一致性、可變性和不可見性來分析說明了軟體天生就沒有銀彈。
作者試圖通過分析軟體問題的本質和很多侯選銀彈的特徵來**其中的原因。他行動的第一步是將大塊的「巨無霸理論」替換成「微生物理論」。這個變化的過程告訴你，進步是逐步取得的，伴隨著辛勤的勞動，對規範化過程應
進行持續不懈的努力，而這個努力的過程相應的就誕生了軟體工程。作者對軟體工程誕生的原因做出這樣的解釋，我覺得符合外國思維的特點，這正是國人所缺乏。記得有一位朋友說過，中國媽媽與德國媽媽的區別，他說，如果手裡拿的針掉到地上了，中國媽媽的第一反應是估計針掉下去的範圍，然後在這個範圍裡面找，可能很快就找到了，也可能一直都找不到；但德國媽媽不同，她會拿一根粉筆來，把整個屋子畫成乙個大圈，接著把大圈分成許許多多的小圈，然後再到每個小圈裡找，雖然比較慢，但最終肯定可以找到。仔細想象，大多數情況下，中國媽媽都會找到得比較快，這確實符合大多數中國媽媽的思維習慣，每個中國媽媽都這樣找，這好象是與生俱來的本事，但為什麼德國媽媽沒有這個本事呢？是德國媽媽笨嗎？為什麼中國媽媽也有找不到的情況？而德國媽媽，雖然速度慢了點，卻始終能夠找得到？如果把這件故事推而廣之，多年以後，德國媽媽建立了找針工程，她通過多次找針的實驗資料，分析出針掉到整個房間中各個小圈的概率，總結出針在哪個小圈的概率最大，很快就可以找到針，找針速度早已高過中國媽媽，而中國媽媽還在依循與生俱來的本事。你能說德國媽媽笨嗎？為什麼中國媽媽和德國媽媽會有這麼大的區別？是德國媽媽把大塊的「巨無霸理論」替換成「微生物理論」嗎？我覺得是是，你說呢？作者在後面的論述中用數學和物理的發展為例子也說明了，這種思想的成立。
餘下的作者把軟體工程按「巨無霸理論」替換成「微生物理論」的過程詳細的說明，值得看，我關注的不是具體的內容，具體內容可能有些不合適宜，我關注的是作者的思考方式以及處理方法，這是非常重要的。
在「以往解決次要困難的一些突破」和「銀彈的希望」章節，從概念上講述了軟體的發展，其中講到「專家系統」時，使我想起一部科幻電影，忘了電影名字了，有個情節大致是這樣的，一位非常有經驗的主管死後，有一名較優 秀的下屬接任，但這時出現了一位非常厲害的敵人，這位新主管無論如何也戰勝不了敵人，這時想起了以前的主管，心想前主管一定有辦法對付這個敵人，而前主管的大腦就存放在系統裡，於是新主管調出前主管的大腦，把敵人的各種特徵都描述給'他'聽，就好象前主管仍然活著一樣，他與前主管的大腦通話後，前主管的大腦告訴了他對付敵人的方法，後來通過這個方法真的把敵人打敗了。這是否專家系統的最佳境界呢？
還有講到「自動」程式設計章節時，使我想起我以前也有過類似的想法，但沒想到這些想法竟然早就有人提出過。還有記得「圖形化程式設計」好象也風行過一段日子。
15.再論《沒有銀彈》no silver bullet refired
看完再論《沒有銀彈》後，雖然作者說有不少人對他的觀點持反對或不同意見，但我始終覺得他的觀點是對的——根本和次要問題的劃分以及定義。作者認為軟體開發困難的部分是概念的結構，如規格化、設計和測試等概念的結構，而不是概念的表述和實現概念，雖然實現概念可能占用了小於90%的時間，就如現今的軟體開發一樣，系統分析通常占用的整個專案開發時間不超過20%，而80%的時間花在程式設計上一樣。
《人月神話》讀後感
不同的社會經驗，不同的思想狀態，對讀本書的心得也不一樣，我在此說說我的讀後感，書中有許多非常好的觀點，但我只把我感觸最深的寫下來。這確實是一本很值得多次閱讀的好書，每次閱讀可能都能從中得到一些提示。1.外科手術隊伍the surgical team 專案經理在專案的初期必須清楚的估計專案的人月運作模...
人月神話讀後感
人月神話 這本書風行已經很久了，寫成於1975年，經歷這麼久的時間，在當前又重新流行，讓我很驚訝,但是一直沒有時間讀。今天突然想起自己的機器上有本拷貝別人的電子書，決定讀讀。我今天只看了兩章，即焦油坑和人月神話。人月神話看上去這麼浪漫的名字，原來並不是真的說神話故事，作者闡述的主要觀點是在軟體開發專...
《人月神話 》讀後感
之前一直聽老師講 人月神話 彷彿這就是乙個傳奇。百聞不如一見，在這本300多頁 中文新版 的神書，在經過了20多年的歷史之後，仍然暢銷不衰，究竟是什麼讓它有如此的魅力？過去的乙個月，一點一滴的閱讀之中算是初步的了解到了它的一部分吧。人月神話的核心觀點 概念完整性和架構師 brooks認為，乙個整潔 ...