第一篇：《人月神話》讀書心得

《軟件工程導論讀書心得》

隨著IT行業的迅速發展，計算機使用越來越普及，越來越多的領域使用了計算機，特別是一些重要領域如國防、銀行、金融、通訊、航天等，他們對軟件質量要求很高。同時一些重大事故的發生，也引發了人們對軟件質量的關注。如2002年歐洲載重10噸的阿麗亞娜5型火箭發射失敗，最后證實是軟件質量問題；還有國內的一些銀行金融系統，因軟件質量問題不得不暫停營業。毋庸置疑，在經歷了長期的不為人知和可有可無后，軟件測試目前已變的炙手可熱。隨著中國軟件市場的發展，越來越多的國外資金投向中國軟件行業。據報道，中國軟件外包市場的潛力和機會已遠遠超過軟件王國印度，不過由于軟件人才的嚴重不足致使我國軟件發展遭遇“瓶頸”。國家為了大力培養軟件人才，不斷采取積極有效的措施。

在這里，我我總結了一學期來的上課聽課心得，在我腦海里反響最為頻繁的同時讓我比較趕興趣的內容就是老師在第七章章節講到的《實現》，在這章節里，講述了軟件的實現需要的是以測試為基礎，從而確保在交付之前保證軟件的可靠性。關于軟件測試，軟件測試是軟件開發過程中必不可少的一個步驟，是用來確認一個軟件的品質和性能的好與環。所謂軟件測試就是利用測試工具按照測試方案和流程對產品進行功能和性能測試，甚至根據需要編寫不同的測試工具，設計和維護測試系統，對測試方案可能出現的問題進行分析和評估。執行測試用例后，需要跟蹤故障，以確保開發的產品適合需求。

軟件測試是個需求高，就職機會大的職業。目前，我國具備軟件測試能力的人員數量和市場需求相差巨大，巨大的市場空缺，使軟件測試工程師從初級到高級，只需要 1 年甚至更短的時間來完成。所以軟件測試行業，未來的發展空間是非常廣闊的。

隨著軟件測試技術的發展，測試方法更加多樣化，針對性更強；選擇合適的軟件測試方法可以讓我們事半功倍。從測試是否針對系統的內部結構和具體實現算法的角度來看，可分為：白盒測試和黑盒測試。從是否需要執行被測軟件的角度，可分為： 靜態測試和動態測試。

在測試的過程中，我們一定要碰到的就是BUG！有人說，軟件測試就是在尋

找軟件中的BUG，那么我么有必要搞清楚什么是BUG。BUG，在英語中是指“小蟲子”的意思，現在泛指計算機中硬件和軟件的錯誤。硬件錯誤有兩個原因：一是設計錯誤，而是硬件老化失效。軟件的錯誤全是廠家的錯誤

雖然知道軟件測試這個名詞，但知其然不知其所以然，通過課后的自我復習，讓我明白了什么是軟件測試，作為一個合格的軟件測試人員應當具備的軟件測試知識有哪些，比如說一個完整的測試流程應該是：單元測試—>集成測試—>聯調—>系統預測試—>系統測試，當然作為軟件測試人員還應知道常用的軟件測試的工具，軟件測試工具的作用是用來發現BUG并處理，一個好的軟件測試工具和測試管理工具結合起來使用將會使軟件測試效率大大的提高，對些軟件測試工具的了解讓我明白一個好的軟件真的是來之不易。通過寫這門課程的心得，讓我明白任何知識只要你肯去了解，肯去鉆研，你肯定會得到你想要的結果，所以我感謝老師給了我們這么好的一個機會再一次的去深層次接觸軟件知識，讓我受益匪淺！

軟工專升本一班：黃偉強

0967020330

第二篇：人月神話讀后感

人月神話讀后感

二十九年前(1975)﹐IBM大型電腦之父──Fred Brooks 出版一本書﹕“The Mythical Man-Month”。收集了他在1960年代領導1000多人共同發展OS/360大型軟件系統的心得和經驗。該書是論文集﹐其中有一篇文章叫“The Mythical Man-Month”﹐他就以此作為書名。在1956~1965 之間﹐Brooks實際領導IBM 360 大型電腦的開發計劃﹐包括硬體結構及龐大的OS/360作業系統在內﹐因之他具有IBM 大型電腦之父的尊稱。由于OS/360是多達1000位程式師共同合作的大型軟件開發工作﹐讓他深刻了解到大型軟件開發的技術和管理上所面臨的種種困難和挑戰。于是﹐他就將其領導開發OS/360軟件系統的經驗心得收集在這本書里。人們常拿Man-Month（多少人﹐做多少個月）來計算軟件的工作量﹐但是Brooks發現軟件的開發工作是需要人與人之間密切溝通的﹐使得設計工作不易分割﹐所以Man-Month 為單位的計算方法是有問題的(mythical)。也就得出著名的Brooks法則── 「對于進度已落后的軟件開發計劃而言﹐若再增加人力﹐只會讓其更加落后。」(Adding manpower to a late software project makes it later)這是該書名稱的涵義。

看完此書后，我發現人月神話無處不在，其實在我們做

軟件工程來說，此書已經滲透進去了。本書作者為人們管理復雜項目提供了頗具洞察力的見解，既有很多發人深省的觀點，也有大量的軟件工程實踐。本書對我觸動最大的，一是保持設計的概念完整。無論對小軟件還是大軟件，都必須由一個設計師主導，最多兩個人討論來共同完成軟件的整體設計。作為一個軟件，一個系統，必須有一個清晰明確的概念模型，大家都在這個框架下工作，所有的創新發展都必須與基本的概念相吻合。具體的實現人員可以細化概念，但只有總設計者才有否定與發展基本概念的權力。需要注意的一點是，即使是總設計師一直是同一個人，他腦海中所認為理所當然的規則或者概念，很可能由于沒有明確的文檔化，而沒有成為所有開發者共同的概念。概念的完整性，對于很多小規模軟件，由于開發人員不多，開發經理一般都能控制住所有的代碼，概念完整性在組織層面就維持住了。但要注意以后的Bug修改，功能擴展的時候，也要時刻留意與最初的設計是否概念上相容。對于大規模的軟件系統，則必須通過樹狀組織結構，層層控制，總設計師還是一到兩人，每一層都有對下層的絕對把握能力。

二是“一個拿2倍工資的人，生產率可能是其他人的10倍。”不知道其他公司的程序員們如何看。我覺得，作為公司，應該給最好的人最好的待遇，或者說給比目前更高的待遇。組建一個團隊，最好的就是那種精英團隊。微軟就是這

種思路吧，把最聰明的人集中在一起，想不成功都難。

三是進度落后與增加人力。記得當年看《C＋＋編程思想》，Bruce說“十個婦女不能在一個月內生下小孩”（大意），于我心有戚戚焉。而本書作者Brooks得出的結論是對我是震撼性的：“向進度落后的項目中增加人手，只會使進度更加落后”。以前，增加人手基本是挽救進度落后項目的主要辦法。這個辦法行不通的話，難道只有“加班”一條路了？如果不想加班，不想削減功能，不想推遲發布日期，那么。。。唯一的方法還是只有….加人。加足夠的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能對原來的組織造成沖擊，或者對原來的設計有不同意見（特別是加入的人中有比較強大的設計者）。那么，就當作，新組建了一個團隊吧。交流，培訓新人，就設計達成一致，繼續向者目標前進。

不同的社會經驗，不同的思想狀態，對讀本書的心得也不一樣。在此我說說書中許多非常好的觀點。

1.外科手術隊伍The Surgical Team

項目經理在項目的初期必須清楚的估計項目的人月運作模式（時間、人力在項目各階段的分配），例如什么時候需要出什么樣成果，決定了什么時候需要什么樣的人加入項目，這是項目經理的責任。

2.貴族專制，民主政治Aristocracy,Democracy,System

要獲得概念的完整性，設計必須由一個人或具有共識的小組來完成。

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

唯一不變的是變化本身。在大型項目中，項目經理需要有兩個和三個頂級程序員作為技術輕騎兵，當工作繁忙最密集的時候，他們能急馳飛奔，解決各種問題。

10.干將莫邪Sharp Tools

主要講述項目中管理好各種工具的重要性，項目經理首先要制定一種策略，讓各種工具成為公用的工具，這樣才能使開發、維護和使用這種工具的開發人員的效率更高，這種工具可能是開發人員開發出來的，也可能是使用現有的，可能是通用的，也可能是專用的或個人偏好的。比如：文檔編寫工具、開發工具（包括各種不同開發平臺）、調試工具、測試工具、數據庫工具、版本管理、項目管理工具等。

11.整體部分The Whole and the Parts

特別是這句話"BELL實驗室監控系統項目的V.A.Vyssotsky提出,“關鍵的工作是產品定義。許許多多的失敗完全源于那些產品未精確定義的地方”,細致的功能定義，詳細的規格說明，規范話的功能描述說明以及這些方法的實施，大大減少了系統中必須查找的BUG數量。雖然這句話的意思只是說明精確定義產品將減少BUG的數量，但我看到了系統分析的最重要的工作——產品定義。

12.禍起蕭墻Hatching a Catastrophe

這章節說明使項目進度拖后的最大原因不是重要的事件，如新技術、重組等，而是一些瑣碎的小事，每件小事只耽誤半天或一天時間，但這種小事多以后，將使項目的進度嚴重拖后。項目對于公司就如程序對測試工程師一樣，如果不了解它，它就是一個黑盒子，如果不打開這個黑盒子，你可能永遠不知道盒子里面有什么。

13.另外一面The other face

本章說明程序的另一面——文檔。

不了解，就無法真正擁有——歌德，作者引用的歌德的話來描述文檔對客戶的重要性，提出客戶需要什么樣的文檔以及文檔的格式和包含的內容，指出當時存在的大多數文檔只描述了樹木，形容了樹葉，但沒有整個森林的圖案。想想，這種情況在現在仍然沒有改變。于是作者提出了兩個觀點：

1.流程圖：流程圖是被吹捧得最過分的一種程序文檔。許多程序甚至不需要流程圖，很少程序需要一頁以上的流程圖

2.自動文檔化（self-documenting）的程序：提出文檔與程序合為一體，能很好的解決文檔與程序分開造成的文檔過時的問題，并說明了在程序中加入文檔的一些方法和技巧。

14.沒有銀彈-軟件工程中的根本和次要問題(No Silver Bullet-Essence and Accident in software Engineering)

人狼是傳說中的妖怪，只有銀彈才能殺死他。作者認為軟件項目具有人狼的特性，因為軟件項目也可能變成一個怪物，一個落后進度、超出預算、存在大量缺陷的怪物。作者通過軟件系統的內在特性復雜性、一致性、可變性和不可見性來分析說明了軟件天生就沒有銀彈。作者試圖通過分析軟件問題的本質和很多侯選銀彈的特征來探究其中的原因。他行動的第一步是將大塊的“巨無霸理論”替換成“微生物理論”。這個變化的過程告訴你，進步是逐步取得的，伴隨著辛勤的勞動，對規范化過程應進行持續不懈的努力，而這個努力的過程相應的就誕生了軟件工程。

15.再論《沒有銀彈》No Silver Bullet Refired

看完再論《沒有銀彈》后，雖然作者說有不少人對他的觀點持反對或不同意見，但我始終覺得他的觀點是對的——根本和次要問題的劃分以及定義。作者認為軟件開發困難的部分是概念的結構，如規格化、設計和測試等概念的結構，而不是概念的表述和實現概念，雖然實現概念可能占用了小于90%的時間，就如現今的軟件開發一樣，系統分析通常占用的整個項目開發時間不超過20%，而80%的時間花在編程上一樣。

第三篇：《人月神話》讀后感

學號：0967020449姓名：張小波班級：軟件工程專升本3班

《人月神話》讀后感

在軟件領域中,很少能有像《人月神話》一樣具有深遠影響力和暢銷不衰的著作。Brooks 博士為人們管理復雜項目提供了最具洞察力的見解,既有很多發人深省的觀點,又有大量軟件工程的實踐,影響著一代又一代….通過閱讀《人月神話》，我從中學到了一些東西：

首先，開發一個項目，我們錯誤的認為用人月這個工作量單位來估計和進行進度安排。成本的確隨開發產品的人數和時間的不同，有著很大的變化，進度卻不是如此。因此我認為用人月作為衡量一項工作的規模是一個危險和帶有欺騙性的神話。它暗示著人員數量和時間是可以相互替換的。人數和時間的互換僅僅適用于以下情況：某個任務可以分解給參與人員，并且他們之間不需要相互的交流，而在系統編程中近乎不可能。當任務由于次序上的限制不能分解時，人手的添加對進度沒有幫助。調試、測試的次序特性，許多軟件都具有這種特征。因為軟件開發本質上是一項系統工作——錯綜復雜關系下的一種實踐——溝通、交流的工作量非常大，它很快會消耗任務分解所節省下來的個人時間。從而，添加更多的人手，實際上是延長了，而不是縮短了時間進度。

對于編程，有其樂趣和苦惱。創建事物的快樂，開發對其他人有用的東西的樂趣，將可以活動、相互嚙合的零部件組裝成類似迷宮的東西，這個過程所體現出令人神魂顛倒的魅力，面對不重復的任務，不間斷學習的樂趣，工作在如此易于駕馭的介質上的樂趣——純粹的思維活動，其存在、移動和運轉方式完全不同于實際物體。將做事方式調整到追求完美，是學習編程的最困難部分；由其他人來設定目標，并且必須依靠自己無法控制的事物（特別是程序）；權威不等同于責任實際情況看起來要比這一點好一些；真正的權威來自于每次任務的完成任何創造性活動都伴隨著枯燥艱苦的勞動，編程也不例外 人們通常期望項目在接近結束時，（bug、工作時間）能收斂得快一些，然而軟件項目的情況卻是越接近完成，收斂得越慢產品在即將完成時總面臨著陳舊過時的威脅。

開發一個軟件，我們要有合理的時間進度，開發人員要少而精，概念完整性必須考慮在內，要盡量做到盡早交流和持續溝通。

同時，文檔形成了關鍵的樞紐，每個項目管理的工作都圍繞著它們運轉，它們是經理們的主要個人工具。對于計算機硬件開發項目，關鍵文檔是目標、手冊、進度、預算、組織機構圖、空間分配、以及機器本身的報價、預測和價格；對于大學科系，關鍵文檔類似：目標、課程描述、學位要求、研究報告、課程表和課程的安排、預算、教室分配、教師和研究生助手的分配；對于軟件項目，要求是相同的：目標、用戶手冊、內部文檔、進度、預算、組織機構圖和工作空間分配。即使是一個小型項目，我們都會要求書寫相關文檔，對每個關鍵文檔的維護提供了狀態監督和預警機制并且本身就可以作為檢查列表或者數據庫。

良好的工作手冊和組織架構可以開發出更加符合用戶的需求。手冊、或者書面規格說明，是一個非常必要的工具，盡管光有文檔是不夠的。手冊是產品的外部規格說明，它描述和規

定了用戶所見的每一個細節；同樣的，它也是結構師主要的工作產物。

形式化定義是精確的，它們傾向于更加完整；差異得更加明顯，可以更快地完成。但是形式化定義的缺點是不易理解。記敘性文字則可以顯示結構性的原則，描述階段上或層次上的結構，以及提供例子。它可以很容易地表達異常和強調對比的關系，最重要的是，它可以解釋原因。在表達的精確和簡明性上，目前所提出的形式化定義，具有了令人驚異的效果，增強了我們進行準確表達的信心。

通常，開發一個軟件我們還會設立規模目標，控制規模，發明一些減少規模的方法——就如同硬件開發人員為減少元器件所做的一樣。規模預算必須與分配的功能相關聯； 在指明模塊大小的同時，確切定義模塊的功能。培養開發人員從系統整體出發、面向用戶的態度是軟件編程管理人員最重要的職能。

調試，是一種檢驗程序中的方法。然而調試是系統編程中很慢和較困難的部分，而漫長的調試周轉時間是調試的禍根。它可以持續一個很長的時間，從而可能影響項目的交付日期。

為了更好的控制進度，我們需要制定一個嚴格的進度表來控制項目的進度表，進度表由里程碑和日期組成。里程碑必須是具體的、特定的、可度量的事件，能進行清晰能定義。進度表有時可以根據進展情況進行適度的修改。

產品測試時每個產品在提交給用戶的一道程序。而這項工作主要由產品測試機構/小組根據規格說明檢查機器和程序，充當麻煩的代言人，查明每一個可能的缺陷和相互矛盾的地方。每個開發機構都需要這樣一個獨立的技術監督部門，來保證其公正性。產品－測試小組則是顧客的代理人，專門尋找缺陷。不時地，細心的產品測試人員總會發現一些沒有貫徹執行、設計決策沒有正確理解或準確實現的地方。出于這方面的原因，設立測試小組是使設計決策得以貫徹執行的必要手段，同樣也是需要盡早著手，與設計同時實施的重要環節。

一個已開發的項目，我們需要對它進行后期維護。其維護基本上不同于硬件的維護，它主要由各種變更組成，如修復設計缺陷、新增功能、或者是使用環境或者配置變換引起的調整而且維護總成本通常是開發成本的40％或更多。維護成本受用戶數目的嚴重影響，用戶越多，所發現的錯誤也越多。在每次修復之后，必須重新運行先前所有的測試用例，從而確保系統不會以更隱蔽的方式被破壞。其實，對于一個項目，我們要盡量做到完美，減少以后的維護困難和成本。

在計算機技術進步的同時，計算機相關學科知識也在飛速發展。興趣太多，令人興奮的學習、研究和思考的機會也太多——多么不可思議的矛盾啊！這個神奇的時代遠遠沒有結束，它依然在飛速發展。更多的樂趣，盡在將來。

第四篇：人月神話讀書筆記

人月神話這本書幾年前就聽別人說是本很經典的軟件開發方面的書，這本書的成功之處在于他思想的前衛性，以至于不只是軟件行業的人在讀。現在終于找到讀他的理由了，可以感受一下大師的杰作。在讀之前我已經讀過了軟件工藝和極限編程，為什么留到最后讀人月神話呢？主要是因為我覺得一本能夠流傳30年還被人們津津樂道的書，肯定是本學要好好細讀的書，所以留到了最后。按照前兩篇讀書筆記的慣例，前面幾段是一些我讀書時的感受和收獲，還有一些對內容的評價。

從這本書的內容來看，對于一個項目經理來說肯定會有更大的收獲，這本書主要是針對軟件開發管理方面的內容，這主要原因可能是因為作者以前就是項目的管理者，他是站在管理者的角度寫的。即便這樣，對于一個從來沒有參與過真實項目開發，更沒有領導過團隊的我還是有一定的吸引力，這本書中我最喜歡的就是前四章（焦油坑、人月神話、外科手術隊伍、貴族專制、民主政治和系統設計）和沒有銀彈這章。這本書里面為了論證某一觀點，會舉出許多實際的項目作為證據，這一點非常好，事實勝于雄辯嘛！這些例子也許對于作者那個年代的人來說很好理解，但是放在30年后來看這些例子又有些陳舊和難懂了。另外，從文中我發現作者非常注重文檔，一個優質的文檔就是項目成功的保證，這一點與傳統的軟件工程很相似，但是卻與極限編程的觀點相悖。下面就是一些讀書的總結了。

焦油坑 1.編程系統產品開發的工作量是供個人使用的、獨立開發的構件程序的九倍。

2.編程行業的一些內在固有苦惱：

l 將做事方式調整到追求完美，是學習編程的最困難部分。

l 由其他人來設定目標，并且必須依靠自己無法控制的事物。

l 真正的權威來自于每次任務的完成。

l 任何創造性活動都伴隨著枯燥艱苦的勞動，編程也不例外

l 人們通常期望項目在接近結束時（bug、工作時間）能收斂得快一些，然而軟件項目的情況卻是越接近完成，收斂得越慢。

l 產品在即將完成時總面臨著陳舊過時的威脅。人月神話 1.缺乏合理的時間進度是造成項目滯后的最主要原因，它比其他所有因素加起來影響還大。

2.良好的烹飪需要時間，某些任務無法在不損害結果的情況下加快速度。

3.我們的構思是有缺陷的，因此總會有bug。

4.我們圍繞成本核算的估計技術，混淆了工作量和項目進展。人月是危險和帶有欺騙性的神話，因為它暗示人員數量和時間是可以相互替換的。

5.在若干人員中分解任務會引發額外的溝通工作量--培訓和相互溝通。

6.關于進度安排，作者的經驗是為1/3計劃、1/6編碼、1/4構件測試以及1/4系統測試。

7.因為我們對自己的估計技術不確定，所以在管理和客戶的壓力下，我們常常缺乏堅持的勇氣。

8.brook法則：向進度落后的項目中增加人手，只會使進度更加落后。

9.向軟件項目中增派人手從三個方面增加了項目必要的總體工作量：任務重新分配本身和所造成的工作中斷；培訓新人員；額外的相互溝通。外科手術隊伍 1.同樣有兩年經驗而且在受到同樣的培訓的情況下，優秀的專業程序員的工作效率是較差程序員的十倍。關于這一條我在極限編程里看到，sackman和humphrey分別做了實驗發現優秀程序員工作效率比較差程序員的工作效率最高要高達28倍。

2.小型、精干隊伍是最好的。這一點在軟件工藝和極限編程里都得到了充分的體現。

3.兩個人的團隊，其中一個項目經理，常常是最佳的人員使用方法。

4.對于真正意義上的大型系統，小型精干的隊伍太慢了。

5.實際上，絕大多數大型編程系統的經驗顯示出，一擁而上的開發方法是高成本、速度緩慢、不充分的，開發出的產品無法進行概念上的集成。

6.一位首席程序員、類似于外科手術隊伍的團隊架構提供了一種方法，既能獲得由少數頭腦產生的產品完整性，又能得到多位協助人員的總體生產率，還徹底地減少了溝通的工作量。圖1是10人的程序開發隊伍溝通模式。圖1 10人程序開發隊伍溝通模式

貴族專制、民主政治和系統設計 1.概念完整性是系統設計中最重要的考慮因素。

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

3.對于非常大型的項目，將設計方法、體系結構方面的工作與具體實現相分離是獲得概念完整性的強有力方法。

4.紀律、規則對行業是有益的。外部的體系結構規定實際上是增強，而不是限制實現小組的創造性。

5.體系結構、設計實現、物理實現的許多工作可以并發進行。畫蛇添足 1.盡早交流和持續溝通能使結構師有較好的成本意識，以及使開發人員獲得對設計的信心，并且不會混淆各自的責任分工。

2.結構師如何成功地影響實現：

i.牢記是開發人員承擔創造性的實現責任；結構師只能提出建議。

ii.聽取開發人員在體系結構上改進的建議。

3.第二個系統是人們所設計的最危險的系統，通常的傾向是過分地進行設計。關于這一點也許是正確的，但是這是一個回避不了的問題，如果沒有開發第二個系統經驗的人，就不可能有開發第三個系統經驗的人了。貫徹執行 1.即使是大型的設計團隊，設計結果也必須由一個或兩個人來完成，以確保這些決定是一致的。

2.必須明確定義體系結構中與先前定義不同的地方，重新定義的詳細程度應該與原先的說明一致。

3.出于精確性的考慮，我們需要形式化的設計定義，同樣，我們需要記敘性定義來加深理解。

4.允許體系結構師對實現人員的詢問做出電話應答解釋是非常重要的，并且必須進行日志記錄和整理發布。

5.項目經理最好的朋友就是他每天要面對的敵人--獨立的產品測試機構/小組。為什么巴比倫塔會失敗？ 1.巴比倫塔項目的失敗是因為缺乏交流，以及交流的結果的組織。

2.因為左手不知道右手在做什么，從而進度災難、功能的不合理和系統缺陷紛紛出現。由于對其他人的各種假設，團隊成員之間的理解開始出現偏差。

3.團隊應該以盡可能多的方式進行相互之間的交流：非正式、常規項目會議，會上進行簡要的技術陳述、共享的正式項目工作手冊。胸有成竹 1.僅僅通過對編碼部分的估計，然后乘以任務其他部分的相對系數，是無法得出對整項工作的精確估計的。

2.構建獨立小型程序的數據不適用于編程系統項目。

3.程序開發與程序規模成指數增長趨勢。

4.當使用適當的高級語言時，程序編制的生產率可以提高5倍。削足適履

這一章主要是要解決項目投資與磁盤空間和內存之間的矛盾，但是這個矛盾在電腦硬件發展到現在的層次已經可以忽略掉了。

提綱挈領 1.軟件項目的要求：目標、用戶手冊、內部文檔、進度、預算、組織機構圖和工作空間分配。

2.即使是小型項目，項目經理也應該在項目早期規范化上述的一系列文檔。這一章強調文檔重要性，但并沒有將一些教條主義的道理讓你相信文檔的重要性，而是給項目經理給出了實實在在的操作步驟。

未雨綢繆 1.對于大多數項目，第一個開發的系統并不合用。它可能太慢、太大，而且難以使用，或者三者兼而有之。系統的丟棄和重新設計可以一步完成，也可以一塊塊地實現。這是個必須完成的步驟，如果將開發的第一個系統丟棄原型發布給用戶，可以獲得時間，但是它的代價很高。對于用戶，使用極度痛苦；對于重新開發的人員，分散了精力；對于產品，影響了聲譽，即使最好的再設計也難以挽回名聲。

2.用戶的實際需要和用戶感覺會隨著程序的構建、測試和使用而變化。

3.軟件產品易于掌握的特性和不可見性，導致了它的構建人員面臨著永恒的需求變更。

4.目標和開發策略上的一些正常變化無可避免，事先為它們做準備總比假設它們不會出現要好得多。

5.對于一個廣泛使用的程序，其維護總成本通常是開發成本的40％或更多。

6.維護成本受用戶數目的嚴重影響。用戶越多，所發現的錯誤也越多。

7.campbell指出了一個顯示產品生命期中每月bug數的有趣曲線，它先是下降，然后攀升。

8.缺陷修復總會以（20－50）%的機率引入新的bug。

9.在每次修復之后，必須重新運行先前所有的測試用例，從而確保系統不會以更隱蔽的方式被破壞。

10.同樣，設計實現的人員越少、接口越少，產生的錯誤也就越少。

11.所有修改都傾向于破壞系統的架構，增加了系統的混亂程度。即使是最熟練的軟件維護工作，也只是放緩了系統退化到不可修復混亂的進程。干將莫邪

項目經理應該制訂一套策略，以及為通用工具的開發分配資源，與此同時，他還必須意識到專業工具的需求。

禍起蕭墻 1.一天一天的進度落后比起重大災難，更難以識別，更不容易防范和更加難以彌補。

2.根據一個嚴格的進度表來控制項目的第一個步驟是制訂進度表，進度表由里程碑和日期組成。

3.里程碑必須是具體的、特定的、可度量的事件，能進行清晰能定義。

4.如果里程碑定義得非常明確，以致于無法自欺欺人時，程序員很少會就里程碑的進展弄虛作假。另外一面 1.對于軟件編程產品來說，程序向用戶所呈現的面貌與提供給機器識別的內容同樣重要。

2.即使對于完全開發給自己使用的程序，描述性文字也是必須的，因為它們會被用戶和作者所遺忘。

3.文檔能在整個軟件開發的生命周期對程序員克服懶惰和進度的壓力起促進激勵作用，但向編程人員成功地灌輸對待文檔的積極態度是一件困難的事情。

4.為了使文檔易于維護，將它們合并至源程序是至關重要的，而不是作為獨立文檔進行保存。沒有銀彈

人狼的傳說可能有人聽過也可能沒聽過，人狼是一種具有人和狼兩種特征的恐怖生物，而銀彈是消滅它的一種最有效的子彈，如果看過《吸血鬼傳說》也許就能和容易的理解這一點。作者將軟件開發比作人狼，而將提高軟件開發效率的方法比作銀彈。作者預言未來十年，想要試圖通過尋找一種有效地銀彈將軟件開發效率提高一個甚至幾個數量級，這種銀彈不可能出現。

沒有銀彈這篇文章里作者列舉出了當時一些非常先進的技術或思想理念，例如ada和其他高級編程語言、面向對象編程、人工智能、專家系統、“自動”編程、圖形化編程、程序驗證、環境和工具、工作站等。雖然這些先進技術在一定程度上提高了軟件開發的效率，但是始終沒有達到銀彈的效果。距離作者的預言已經過去有20多年了，縱觀現在的軟件開發領域，雖然新技術層出不窮，但是還是沒有一種銀彈能夠讓軟件開發產生一次革命。

焦油坑依然存在軟件工程的焦油坑在將來很長一段時間內會繼續困擾著人們。由于軟件系統多變性和錯綜復雜性，這個行業只能是一步一個臺階的往上爬，而出現銀彈的希望在我們可以想象的時間范圍內是非常渺茫的。我們將長期與焦油作斗爭。

第五篇：人月神話讀后感

人月神話讀后感

、《人月神話》是預言了未來還是扼制了未來?

事實是：我們目前的許多工程知識，——無論是從書上看到的，還是從實踐中經驗到的——大多未曾脫離《人月神話》之所言，人月神話讀后感。

我在開篇中說《人月神話》“是一本可怕的書”。然而我感受懇摯的可怕之處在于：現今凡是論及工程(且不要讓人感受是離經叛道)，那么所解說的定然是Brooks的這么的經驗以及由此推出的見解，可能在不違拗這些經驗和見解上的一些翔實的實作措施!我們全然不顧書中所言是假象，還是性質的推論，可能只是假象歸納的一個(未必準確的)答案。盡管這些答案大多數時候都好像預期地展目前你的切實工程中：

原文中還有眾多相仿的見解、假象和答案，都成為了切實工程中的既存假象。先民們所說的圣人以及通神者，皆因他們多數時候在準確地預言自己的切實。只有當這個“多數時候”變成半點的時候，先民們才會置疑圣人和通神者的力氣。其實我們懂得并未曾預言未來的人，大多數時候是兩種情形導致的假象：

他做出了準確的推斷;

你主觀地跟隨了他對未來的設定。

后者是風險的。大師們預言了未來也就改換了未來，即便未來未必“該當”好像他所預言的那樣。

但萬一這種預言的前提不準確，那么未來定然脫離這種波及而回到它該當的事態上去。好像我們看到的另一些事實一樣，有許多假象闡明，我們正在歸來工程***的道路上摸索前進。我們也覺察，在大多數情形下，先哲們的預言在實踐中被檢討著，只是偶爾“不太靈光”。下表則列出一些不同的例子：

注1：我例舉了爽利的一些見解，并不闡明我是Ap/Xp的fans。Ap/Xp的問題另論，在這里，我只是解釋存在一種不同的信念。

注2：Brooks爾后確認“定然丟棄原型”是一個不太準確的見解。

注3：Brooks在這里未曾犯訛謬，只是他所談論的是狹義的流程圖，而我們例舉的時序圖則更廣義。

我們追憶上一細節，在《人月神話》中的那“31%的答案”的前提——也即便那7%的性質中，如下兩項是顯明猜忌的(也是重要置疑)：

目標的性質：是大型工程，是系統項目，而不是過程

個體的性質：是私利性的其實早就有人意識到個體的性質“未必全是私利的”，尊重這些個體就會帶來一些收獲。例如Ap正是因為更尊重開發人員的稟性與力氣，以及互相間的配合而獲得了效率的晉級。

再進一步地說，既然Brooks設定了“大型工程或系統項目”這么的目標，并給出了一些答案。那么在“小那么一點點的”工程項目中，是不是這些答案就無須定了呢?例如Brooks的眾多提倡，對于某些目標——例如你要用為期三個月的工夫開發一個的產品——就并不是很管用;可能大約無法厲行——例如你的群體總共只有6個人，連“外科手術式的群體”都組織不起來，讀后感《人月神話讀后感》。

Brooks的答案對于同樣的目標，以及在他所述的“性質”未能發生改換時，還是比擬管用(或有厲行的可能性)。因而上述一些例外，總是在上述的“7%的性質”被抵賴或被改換的情形下獲得的。因而我們提出的問題是“如何抵賴或改換”這些難以撼動的性質。然而在我看來，Brooks早曾經在最佳位置上，給出了撬動它們的一個支點：

Brooks感受發生“自力更生小型過程”與“編程系統產品”是不同的問題。

Brooks談論的編程系統產品的規模究竟有多大呢?我想起碼該當是以IBM 360為參看的。不過書中在引用Joel Aron(IBM在馬里蘭州蓋茲堡的系統技巧主管)的例子時說，“大型意味著過程員的數目超過25人，將近30,000行的號召”。而按照《人月神話》的數據：人均效率800號召/人年，則這個“大型項目”該當必需1.5年能力告終。另外，還必需大約一倍的人工，來負責除開代碼之外的測驗、管教、文檔和溝通等工作。

好的，萬一你有一個“(起碼)50人，開發一年半”的項目，那么你能夠先接受Brooks的答案去實踐一下：起碼你能夠有工夫來談論工程問題，也能夠組建那樣規模的群體。然而，難道只有這么的“大型工程”才算得工程，而“小那么一點點”的就不算嗎?切實是，我們一方面在做著“小那么一點點的”工程項目，另一方面在聽著全副業界嘈雜著“為更大規模的工程”而準備的工程理論。我們總在實踐Brooks的“答案”可能“預言”，而淡忘這些答案的前提：

Brooks的經驗源自對IBM 360等大型項目標實踐與分析;

Brooks所述的工程是要獲得編程系統產品;

Brooks感受編程系統產品的工作量可能是自力更生小型過程的9倍(在告終大約雷同功能的情形下)。

事實上我們目前的軟件工程的進展是被駕駛了，而不是被預言了。從性質上來說，Brooks在《人月神話》中只是談論了大型工程的厲行，以及相應規模下的群體創立。而我們，便按照這么的設定來擺開了全副軟件工作的工程化厲行。

促成這種現狀的，并不但僅是一本書的能力，還在于商業的能力。因為只有在這么擴展開來的工作環境中，才可能有商業時機。——即便那些工程顧問與厲行專家歷來未曾厲行過“50人，開發一年半”這么的項目，凡是他們能報出Brooks的名字，能談及某些工具在應付“大型項目”中的獲勝經驗，他們就曾經獲勝了一半了。

為什么“爽利”之初頗受爭議?為什么爽利對一些中小型的群體顯得管用和可厲行?為什么當這些爭議被擺在現在的獲勝平息爾后，傳統工程的理論家們卻不忘恨恨地評上一句：那是一種不能(或難以)利用于大型工程的措施呢?!

因為萬一大家都很“爽利”，都只做比這些大型工程“小那么一點點”的工程，那么傳統工程的專家們就失業了。反到來，只有把工程做大，大到“爽利”錯過了含義，而“宏偉”變成了性質的時候，傳統工程就可感受任何失利找到借口：看啊，Brooks就說過“未曾銀彈”嘛。