人月神話讀書筆記

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

人月神話這本書幾年前就聽別人説是本很經典的軟件開發方面的書，這本書的成功之處在於他思想的前衞性，以至於不只是軟件行業的人在讀。現在終於找到讀他的理由了，可以感受一下大師的傑作。在讀之前我已經讀過了軟件工藝和極限編程，為什麼留到最後讀人月神話呢？主要是因為我覺得一本能夠流傳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多年了，縱觀現在的軟件開發領域，雖然新技術層出不窮，但是還是沒有一種銀彈能夠讓軟件開發產生一次革命。

焦油坑依然存在

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

第二篇：《人月神話》讀書筆記

第1章 焦油坑

這一章分成兩個部分：

? 程序（program）、程序產品（programming product）、編程系統（programming system）、編程系統產品（programming product system）的概念

? 程序員的工作性質

比較有意思的是第一部分的四個概念。

在作者的眼中，程序就是一堆代碼，任何人可以宣稱自己會編程，但是編程得到的只是程序，而不是產品。程序要成為程序產品，需要有明確的輸入、功能和輸出，經過完備的測試，具備合格的文檔，使之功能可靠，維護易行。

編程系統是從系統的角度來看待功能完整的程序模塊，要求程序要具備語法和語義精確的接口，能夠與其他的程序進行流暢的交互。相比程序產品來説，不僅僅要嚴格測試程序自身的輸入、處理、輸出，還要測試與不同程序之間的交互，因為很多bug其實是隱含在不同功能模塊的交互過程中。另外編程系統還要考慮程序之外的軟硬件運行環境。呵呵，只有經過了集成測試之後才能稱之為編程系統。

最高級的形式是編程系統產品，從書中的表述來看，就是編程系統+各類文檔，文檔是為了後續維護和升級方便而準備的。智力產品如果沒有説明書真是一場噩夢啊，之前我們經歷過的不少系統到了後續維護的時候發現文檔補齊，維護人員真是傷透腦筋，最後問題太多了索性就提議推倒重做。可以説如果是文檔齊備一點，我們公司很多系統的壽命是可以更長的。

第2章 人月神話

第三篇：人月神話筆記

人月神話讀書筆記(一)

第一章 焦油坑

表面上看起來好像沒有任何一個單獨的問題會導致困難，每個都能被

解決，但是當它們相互糾纏和積累在一起的時候，團隊的行動就會變

得越來越慢。對問題的麻煩程度，每個人似乎都會感到驚訝，並且很

難看清問題的本質。不過，如果我們想解決問題，就必須試圖先去理

解它。--清楚地解釋系統開發的困難所在。

這，就是編程。一個許多人痛苦掙扎的焦油坑以及一種樂趣和苦惱共

存的創造性活動。對於許多人而言，其中的樂趣遠大於苦惱。而本書

的剩餘部分將試圖搭建一些橋樑，為通過這樣的焦油坑提供一些指導。

--本書的目的

第二章 人月神話

1.在眾多軟件項目中，缺乏合理的時間進度是造成項目滯後的最主要原因，它比其他所有因素加起來的影響還大。導致災難的原因是：

首先，我們對估算技術缺乏有效的研究。

第二，我們採用的估算技術隱含地假設人和月可以互換，錯誤地將進度與工作量相互混淆

第三，由於對自己的估算缺乏信心，軟件經理通常不會有耐心持續地進行估算這項工作。 第四，對進度缺少跟蹤和監督。

第五，當意識到進度的偏移時，下意識（以及傳統）的反應是增加人力。

2.系統開發過程中，樂觀主義並不應該是理所應當的。

在單個任務中，“一切都將運轉正常”的假設在時間進度上具有可實現性。因為所遇的延遲是一個概率分佈曲線，“不會延遲”僅具有有限的概率，所以現實情況可能會像計劃安排的那樣順利。然而大型的編程工作，或多或少包含了很多任務，某些任務間還具有前後的次序，從而一切正常的概率變得非常小，甚至接近於無。

3.成本的確隨開發產品的人數和時間的不同，有着很大的變化，進度卻不是如此。因此我認為用人月作為衡量一項工作的規模是一個危險和帶有欺騙性的神話。它暗示着人員數量和時間是可以相互替換的。

因為軟件開發本質上是一項系統的工作--錯綜複雜關係下的一種實踐--溝通、交流的工作量非常大，它很快會消耗任務分解所節省下來的個人時間。從而，添加更多的人手，實際上是延長了，而不是縮短了時間進度。

4.在時間進度中，順序限制所造成的影響，沒有哪個部分比單元測試和系統測試所受到的牽涉更徹底。

對於任務的進度安排，以下是作者使用了很多年的經驗法則：

1/3 計劃

1/6 編碼

1/4 構件測試和早期系統測試（單元測試）

1/4 系統測試

5.如果發現項目的實際進度滯後於預計的進度，項目經理最好的辦法是重新安排進度，而不是增加項目人手。

6.項目的時間依賴於順序上的限制，人員的數量依賴於單個子任務的數量。從這兩個數值可以推算出進度時間表，該表安排的人員較少，花費的時間較長（唯一的風險是產品可能過時）。相反，分派較多的人手，計劃較短的時間，將無法得到可行的進度表。總之，在眾多軟件項目中，缺乏合理的時間進度是造成項目滯後的最主要原因，它比其他所有因素加

起來的影響還要大。

第三章 外科手術隊伍

1.對於效率和概念的完整性來説，最好由少數幹練的人員來設計和開發，而對於大型 系統，則需要大量的人手，以使產品能在時間上滿足要求。如何調和這兩方面的矛盾呢？--本章要解決的問題

s的建議：

外科醫生（首席程序員）：定義功能和性能技術説明書，設計程序，編制源代碼，測試 以及書寫技術文檔。

副手：主要作用是作為設計的思考者、討論者和評估人員。

管理員：控制財務、人員、工作地點安排和機器，充當組織中其他管理機構的接口。 編輯：根據外科醫生的草稿或者口述的手稿，進行分析和重新組織，提供各種參考信息 和書目，對多個版本進行維護以及監督文檔生成的機制。

兩個祕書

程序職員：維護編程產品庫中所有團隊的技術記錄。

工具維護人員：保證所有基本服務的可靠性，以及承擔團隊成員所需要的特殊工具（特 別是交互式計算機服務）的構建、維護和升級責任。

測試人員：各個功能設計系統測試用例的對頭，同時也是日常調試設計測試數據的助手。 負責計劃測試的步驟和為測試搭建測試平台。

語言專家：尋找一種簡潔、有效的使用語言的方法來解決複雜、晦澀或者棘手的問題。

3.當進行大系統開發時：

要有一個系統結構師從上至下地進行所有的設計。要使工作易於管理，必須清晰地劃分體

繫結構設計和實現之間的界線，系統結構師必須一絲不苟地專注於體系結構。

第四章 貴族專制、民主政治和系統設計

1.概念一致性

在系統設計中，概念完整性應該是最重要的考慮因素。也就是説為了反映一系列 連貫的設計思路，寧可省略一些不規則的特性和改進，也不提倡獨立和無法整合 的系統，哪怕它們其實包含着許多很好的設計。

2.功能與理解上覆雜程度的比值才是系統設計的最終測試標準。但是功能本身 或者易於使用都無法成為一個好的設計評判標準。

3.簡潔和直白來自概念的完整性。每個部分必須反映相同的原理、原則和一致 的折衷機制。在語法上，每個部分應使用相同的技巧；在語義上，應具有同樣的 相似性。因此，易用性實際上需要設計的一致性和概念上的完整性。

4.概念的完整性要求設計必須由一個人，或者非常少數互有默契的人員來實現。

5.系統的體系結構(architecture)指的是完整和詳細的用户接口説明。體系結 構必須同實現仔細地區分開來。

6.作者不認為只有結構師才有好的創意。新的概念經常來自實現者或者用户。 然而系統的概念完整性決定了使用的容易程度。不能與系統基本概念進行整合的 良好想法和特色，最好放到一邊，不予考慮。如果出現了很多非常重要但不兼容 的構想，就應該拋棄原來的設計，對不同基本概念進行合併，在合併後的系統上 重新開始。

7.概念的完整性的確要求系統只反映唯一的設計理念，用户所見的技術説明來 自少數人的思想。實際工作被劃分成體系結構、設計實現和物理實現，但這並不 意味着該開發模式下的系統需要更長的時間來創建。經驗顯示恰恰相反，整個系

統將會開發得更快，所需要的測試時間將更少。同工作的水平分割相比，垂直劃 分從根本上大大減少了勞動量，結果是使交流徹底地簡化，概念完整性得到大幅 提高。

第五章 畫蛇添足

1. 本章的目標：結構設計師要避免向系統中添加很多不實際的功能（避免

畫蛇添足）。

2. 儘早交流和持續溝通能使結構師有較好的成本意識，以及使開發人員獲

得對設計的信心，並且不會混淆各自的責任分工。

3. 面對估算過高的難題，結構師有兩個選擇：削減設計或者建議成本更低

的實現方法--挑戰估算的結果。後者是固有的主觀感性反應。此時，結構師 是在向開發人員的做事方式提出挑戰。想要成功，結構師必須

牢記是開發人員承擔創造性和發明性的實現責任，所以結構師只能建議，而 不能支配；

時刻準備着為所指定的説明建議一種實現的方法，同樣準備接受其他任何能 達到目標的方法；

對上述的建議保持低調和平靜；

準備放棄堅持所作的改進建議。

4. 一個可以開闊結構師眼界的準則是為每個小功能分配一個值：每次改進， 功能 x 不超過 m 字節的內存和 n 微秒。這些值會在一開始作為決策的嚮導 ，在物理實現期間指南和對所有人的警示。

5. 項目經理必須堅持至少擁有兩個系統以上開發經驗的結構師的決定。同時 ，保持對特殊誘惑的警覺，他可以不斷提出正確的問題，確保原則上的概念和 目標在詳細設計中得到完整的體現。

第六章 貫徹執行

1. 問題：項目經理如何確保每個人聽從、理解並實現結構師的決策？對於有多個結構師

的小組如何保持系統概念上的完整性。

2. 手冊、或者書面規格説明，是一個非常必要的工具。手冊是產品的外部規格説明，它

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

手冊不但要描述包括所有界面在內的用户可見的一切，它同時還要描述用户看不見的事物。

後者是編程實現人員的工作範疇，而實現人員的設計和創造是不應該被限制的。體系結構

設計人員必須為自己描述的任何特性準備一種實現方法，但是他不應該試圖支配具體的實

現過程。

規格説明的風格必須清晰、完整和準確。用户常常會單獨提到某個定義，所以每條説明都

必須重複所有的基本要素，所以所有文字都要相互一致。

3. 規格説明中，形式化定義是精確的，它們傾向於更加完整；差異得更加明顯，可以更

快地完成。但是形式化定義的缺點是不易理解。記敍性文字則可以顯示結構性的原則，描

述階段上或層次上的結構，以及提供例子。應同時包括形式化和記敍性定義兩種方式。

4. 通過會議的方式，開發人員進行溝通和討論問題。

5. 不同實現之間嚴格要求相互兼容。如果起初至少有兩種以上的實現，那麼定義會更加

整潔和規範。

6. 對於存有疑問的實現人員，應鼓勵他們打電話詢問相應的結構師，而不是一邊自行猜

測一邊工作。

一種有用的機制是由結構師保存電話日誌。日誌中，他記錄了每一個問題和相應的回答。 每週，對若干結構師的日誌進行合併，重新整理，併發布給用户和實現人員。這種機制很

不正式，但非常快捷和易於理解。

7. 在最後的分析中，用户是獨立的監督人員。在殘酷的現實使用環境中，每個細微缺陷

都將無從遁形。產品測試小組則是顧客的代理人，專門尋找缺陷。不時地，細心的產品測

試人員總會發現一些沒有貫徹執行、設計決策沒有正確理解或準確實現的地方。出於這方

面的原因，設立測試小組是使設計決策得以貫徹執行的必要手段，同樣也是需要儘早着手

，與設計同時實現的重要環節。

第七章 為什麼巴比倫塔會失敗

1. 項目人員之間的交流和溝通是項目能否順利和成功的一個重要因素。

2. 缺乏交流引起進度災難、功能的不合理和系統缺陷紛紛出現。隨着工作的進行，許多小組慢慢地修改自己程序的功能、規模和速度，他們明確或者隱含地更改了一些有效輸入和輸出結果用法上的約定。

團隊如何進行相互之間的交流溝通：

清晰定義小組內部的相互關係和充分利用電話，能鼓勵大量的電話溝通，從而達到對所書寫文檔的共同理解。

常規項目會議。會議中，團隊一個接一個地進行簡要的技術陳述。這種方式非常有用，能澄清成百上千的細小誤解。

在項目的開始階段，應該準備正式的項目工作手冊。

3. 項目工作手冊不是獨立的一篇文檔，它是對項目必須產出的一系列文檔進行組織的一種結構。

項目所有的文檔都必須是該結構的一部分。這包括目的、外部規格説明、接口説明、技術標準、內部説明和管理備忘錄。

4. 使用項目工作手冊的原因：

技術説明幾乎是必不可少的。如果某人就硬件和軟件的某部分，去查看一系列相關的用户手冊。他發現的不僅僅是思路，而且還有能追溯到最早備忘錄的許多文字和章節，這些備忘錄對產品提出建議或者解釋設計。

正確的文檔結構非常重要。事先將項目工作手冊設計好，能保證文檔的結構本身是規範的。另外，有了文檔結構，後來書寫的文字就可以放置在合適的章節中。

控制信息發佈，確保信息能到達所有需要它的人的手中。

5. 團隊組織的目的是減少不必要的交流和合作的數量。減少交流的方法是人力劃分和限定職責範圍。當使用人力劃分和職責限定時，樹狀管理結構所映出對詳細交流的需要會相應減少。

第八章 胸有成竹

1. 問題：系統編程需要花費多長時間？需要多少工作量？如何進行估計？

2. 工作量是規模的冪函數。

portman的數據：工作花費的時間大約是估計的兩倍。

aron、harr、os/360的數據：生產率會根據任務本身的複雜度和困難程度表現出顯著差異。

carbato的數據：對常用的編程語句而言。生產率似乎是固定的。這個固定的生產率包括了編程中需要註釋，並可能存在錯誤的情況。使用適當的高級語言，編程的 生產率可以提高5倍。

第九章 削足適履

1. 系統的空間規模：規模是軟件系統產品用户成本中如此大的一個組成部分，開發 人員必須設置規模的目標，控制規模，考慮減小規模的方法。同任何開銷一樣，規模 本身不是壞事，但不必要的規模是不可取的。

2. 對項目經理而言，規模控制既是技術工作的一部分，也是管理工作的一部分。必 須研究用户和他們的應用，以設置將開發系統的規模。接着，把這些系統劃分成若干 部分，並設定每個部分的規模目標。由於規模--速度權衡方案的結果在很大的範圍內 變化，規模目標的設置是一件頗具技巧的事情，需要對每個可用方案有深刻的瞭解。 聰明的項目經理還會給自己預留一些空間，在工作推行時分配。

僅對核心程序設定規模目標是不夠的，必須把所有的方面都編入預算。

在指明模塊有多大的同時，確切定義模塊的功能。

培養開發人員從系統整體出發，面對用户的態度。

3. 在速度不變的情況下，更多的功能意味着需要更多的空間。其中一個技巧是用功 能交換尺寸。設計人員必須決定用户可選項目的精細程度。

4. 考慮空間--時間的折衷。對於給定的功能，空間越多，速度越快。

項目經理可以做兩件事來幫助他的團隊取得良好的空間--時間折衷。一是確保他們在 編程技能上得到培訓，而不僅僅是依賴他們自己掌握的知識和先前的經驗。特別是使 用新語言或者新機器時，培訓顯得尤其重要。另一種方法是認識到編程需要技術積累， 需要開發很多公共單元構件。

5. 戰略上的突破常來自數據或表的重新表達--這是程序的核心所在。數據的表現形 式時編程的根本。

第十章 提綱挈領

1. 文檔的跟蹤維護是項目監督和預警的機制。文檔本身可以作為檢查

列表、狀態控制，也可以作為彙報的數據基礎。

2. 軟件項目文檔的內容：

目標。待完成的目標、迫切需要的資源、約束和優先級。 軟件開發網

產品技術説明。

進度表。

資金預算。

工作空間分配。

人員組織。

3. 為什麼要有正式的文檔

首先，書面記錄決策是必要的。人們能從令人迷惑的現象中得到清晰、確

定的決策。

第二，文檔能作為同其他人溝通的渠道。項目經理的基本職責是使每個人

都向着相同的方向前進，所以他的工作主要是溝通，而不是做出決定。文

檔能極大地減輕他的負擔。

最後，文檔可以作為數據基礎和檢查列表。通過週期性的回顧，他能清楚

項目所處的狀態，以及哪些需要重點進行更改和調整。

項目經理的任務是制訂計劃，並根據計劃實現。只有書面計劃是精確和可

以溝通的。通過遵循文檔開展工作，項目經理能更清晰和快速地設定自己

的方向。

第十一章 未雨綢繆

1. 對於大多數項目，第一個開發的系統並不合用。可能太慢、太大，而且難以 使用，或者三者兼而有之。要解決所有的問題，除了重新開始以外，沒有其他的 辦法--即開發一個更靈巧或者更好的系統。系統的丟棄和重新設計可以一步完成 ，也可以一塊塊地實現。所有大型系統的經驗都顯示，這是必須完成的步驟。 -- 構建一個試驗性的系統，然後拋棄它。

2. 一旦認識到實驗性的系統必須被構建和丟棄，具有變更思想的重新設計不可 避免。

3. 為變化設計系統，包括細緻的模塊化、可擴展的函數、精確完整的模塊間接 口設計、完備的文檔。另外，還可能會採用包括調用隊列和表驅動技術。

最重要的措施是使用高級語言和自文檔技術，以減少變更引起的錯誤。採用編譯時的操作來整合標準説明，在很大程度上幫助了變化的調整。

變更的階段化是一種必要的技術。每個產品都應該有數字版本號，每個版本都應 該有自己的日程表和凍結日期。在此之後的變更屬於下一個版本的範疇。

4. 為變更計劃組織架構和團隊。

5. 程序維護中的一個基本問題是 -- 缺陷修復總會以(20%--50%)的機率引入新 的bug。整個過程是前進兩步，後退一步。作為引入新bug的一個後果，程序每條 語句的維護需要的系統測試比其他編程要多，成本非常高。

缺陷不能被徹底修復的原因：

首先，看上去很輕微的錯誤，似乎僅僅是局部操作上的失敗，實際上卻是系統級 別的問題。其次，維護人員通常不是編寫代碼的開發人員。

5. 使用能消除、至少是能指明副作用的程序設計方法，會在維護成本上有很大 的回報。設計實現的人員越少、接口越少，產生的錯誤也就越少。

6. 維護工作破壞系統的架構，增加了系統的混亂程度。隨着時間的推移，系統 變得越來越無序，無法再成為下一步進展的基礎。這時，系統的重新設計完全是 必要的。

系統軟件開發是減少混亂度的過程，軟件維護是提高混亂度的過程，即使是最熟 練的軟件維護工作，也只是放緩了系統退化的進程。

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

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

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

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

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

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

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

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

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

軟工專升本一班：黃偉強

0967020140

第五篇：人月神話讀後感(1)

人月神話讀後感

二十九年前(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實驗室監控系統項目的otsky提出,“關鍵的工作是產品定義。許許多多的失敗完全源於那些產品未精確定義的地方”,細緻的功能定義，詳細的規格説明，規範話的功能描述説明以及這些方法的實施，大大減少了系統中必須查找的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%的時間花在編程上一樣。