第一篇：人月神話觀后感

《人月神話》觀后感

在軟件領(lǐng)域，很少能有像《人月神話》一樣具有深遠(yuǎn)影響力和暢銷不衰的著作。Brooks博士為人們管理復(fù)雜項目提供了最具洞察力的見解，既有很多發(fā)人深省的觀點(diǎn)，又有大量軟件工程的實踐。讀完本書后，感觸頗深，書中通過介紹在軟件項目開發(fā)過程中遇到的一系列問題，以及解決的方法，向IT從業(yè)者講述軟件開發(fā)過程中需要注意的問題，以下將按照本書的順序一一總結(jié)。

第一章 焦油坑

史前時代的焦油坑吞噬了成千上萬個力大無窮的巨獸，今天的大型軟件項目則令無數(shù)龐大的開發(fā)團(tuán)隊陷入無從逃脫的窘境。軟件程序按其規(guī)模和目標(biāo)的不同，對開放過程的要求也有極大的不同，這給軟件開放這一職業(yè)帶來無窮樂趣，同時也是這一行業(yè)苦惱的根源。

第二章 人月神話

軟件開發(fā)項目常以人月來衡量工作量，這種度量暗示著人手和時間是可以互換的。這種“人多力量大”的想法是一種一廂情愿的虛妄神話，布魯克斯法則：向滯后的軟件項目追加人手會使得進(jìn)度更遲緩。自本書第一版以來，這一法則在軟件業(yè)廣為傳誦。

第三章 外科手術(shù)隊伍

雖然優(yōu)秀的程序員的工作效率往往數(shù)倍于平庸的程序員，但若是缺乏合理的配置，優(yōu)秀的成員未必能構(gòu)成優(yōu)秀的團(tuán)隊。大型軟件開發(fā)項目的團(tuán)隊需要和外科手術(shù)組一樣妥善分工，各司其職協(xié)調(diào)配合。

第四章 貴族專制、民主制和系統(tǒng)設(shè)計

概念完整性是系統(tǒng)設(shè)計中最重要的因素，尤其對于大型軟件系統(tǒng)，概念完整性是項目順利完成的必要保障，為獲得概念完整性，架構(gòu)設(shè)計由精簡的架構(gòu)設(shè)計小組負(fù)責(zé)，具體實現(xiàn)則圍繞核心概念展開，架構(gòu)設(shè)計和具體實現(xiàn)既相分離，又相輔相成。以建筑工程為類比，概念完整性也是軟件項目通往成功的保證。

第五章 畫蛇添足

人們在第一個系統(tǒng)成功完成后，往往會在開發(fā)后續(xù)的第二個系統(tǒng)時犯冒進(jìn)的錯誤。第二個系統(tǒng)經(jīng)常成為過度設(shè)計或畫蛇添足的犧牲品。要避免這種錯誤，必須在第二個系統(tǒng)開發(fā)時審慎地考查技術(shù)環(huán)境的變化，廣泛進(jìn)行交流和溝通，聆聽各方面的建議，確立嚴(yán)謹(jǐn)?shù)墓浪愫鸵?guī)劃。

第六章 貫徹執(zhí)行

架構(gòu)設(shè)計通常由核心設(shè)計小組完成，將設(shè)計概念傳達(dá)到整個開發(fā)團(tuán)隊是貫徹概念完整性的必然要求。以System 360的開發(fā)經(jīng)驗為例，要貫徹概念完整性，需要在團(tuán)隊中保持良好順暢的溝通和交流，采用形式化定義等技術(shù)來確保概念被精確地定義和傳達(dá)。獨(dú)立的測試小組是系統(tǒng)質(zhì)量的良好保證。

第七章 巴比倫塔為何失敗

如果缺乏良好有效的溝通和協(xié)作，成員間難以有效的配合，團(tuán)隊項目的目標(biāo)就無法實現(xiàn)。清晰的工作文檔，明確的組織結(jié)構(gòu)，合理的職責(zé)分配，都是大型軟件項目最終成功的保證。

第八章 胸有成竹

對大型軟件系統(tǒng)產(chǎn)品的開發(fā)所需的時間和資源進(jìn)行準(zhǔn)確的估測，能讓我們在項目進(jìn)度和前景胸有成竹。軟件代碼的開發(fā)效率和代碼模塊之間所需的交互相關(guān)。界面交互復(fù)雜的程序需要更多的測試和調(diào)試時間，單純地增加人手并不能有助于開發(fā)效率的提高。

第九章 削足適履

最大化資源利用率，減少不必要的資源占用，合理規(guī)劃，使軟件系統(tǒng)在資源有限的情況下依然保證了良好的性能，從而實現(xiàn)良好的可伸縮性和健壯性，這能體現(xiàn)軟件開發(fā)人員精湛的設(shè)計技巧。巧妙的數(shù)據(jù)結(jié)構(gòu)往往能大幅度地儉省資源耗費(fèi)，提高系統(tǒng)運(yùn)行的性能。

第十章 提綱挈領(lǐng)

在軟件項目開發(fā)過程中，文檔是不可或缺的，文檔為整個團(tuán)隊規(guī)范了概念，以便團(tuán)隊中的溝通協(xié)作，以及進(jìn)度校驗。本章闡述了軟件系統(tǒng)項目中至關(guān)重要的幾類文檔。這些關(guān)鍵文檔應(yīng)及時地更新，始終作為

項目進(jìn)展的有效指南。

第十一章 未雨綢繆

變化是永恒的，用戶的需求和期望在變化，開發(fā)者對用戶需求的理解在變化，適用的技術(shù)也在變化，故而最佳的解決策略也可隨之變化。軟件開發(fā)團(tuán)隊?wèi)?yīng)靈活地配置人力和資源，適應(yīng)開發(fā)過程中的種種問題。程序的復(fù)雜性、用戶需求的不確定性、軟硬件技術(shù)環(huán)境的發(fā)展等因素導(dǎo)致了軟件維護(hù)工作并非總是能夠百分之百地獲得回報。

第十二章 干將莫邪

軟件開發(fā)項目所選擇的技術(shù)和工具對保障項目能否令人滿意地如期完成至關(guān)重要。合適的開發(fā)工具、評測技術(shù)能有事半功倍之效果，切于項目實用的工具和技術(shù)是項目團(tuán)隊的重要財富。本章提供了當(dāng)年軟件開發(fā)項目選擇技術(shù)和工具的重要原則和建議。

第十三章 整體部分

大而無當(dāng)?shù)幕\統(tǒng)見地并不能表現(xiàn)你真正地理解了一個軟件系統(tǒng)，應(yīng)該具體而系統(tǒng)地深入了解各個局部的技術(shù)。良好的自頂向下的設(shè)計，不僅能保證概念完整性，也能及早消滅許多隱患。及早在軟件項目中引入測試，錯誤發(fā)現(xiàn)得越早，修復(fù)錯誤的代價越小。

第十四章 禍起蕭墻

項目進(jìn)度的滯后經(jīng)常來自不易察覺的點(diǎn)滴延誤的累積。軟件項目的經(jīng)理應(yīng)該盡量建立可以明確量化的階段性目標(biāo)，定期進(jìn)行嚴(yán)謹(jǐn)而規(guī)范的項目階段性驗收，了解項目的進(jìn)展?fàn)顩r，并及時進(jìn)行計劃、資源和人力的調(diào)整。關(guān)鍵路徑圖等技術(shù)有助于觀察項目的進(jìn)度。

第十五章 另外一面

雖然用戶直接使用軟件系統(tǒng)，但在許多應(yīng)用領(lǐng)域中，用戶不可能僅僅憑借與軟件的直接交互就迅速掌握其所有功能。故而提供給用戶的使用說明等文檔是軟件呈現(xiàn)給用戶的另外一面，它也能直接影響用戶對軟件的滿意度和可用性評價。文檔的用途決定它的形式和內(nèi)容。

第十六章 沒有銀彈――軟件工程的根本和次要問題

本文最初發(fā)表于1985年的IFIP第十屆世界計算機(jī)大會上，此時距《人月神話》初版發(fā)行已有十年，其間計算機(jī)技術(shù)領(lǐng)域的變化令人振奮，但作者在此提出，由于軟件的復(fù)雜性，一致性，變化性和不可見性，解決軟件危機(jī)的銀彈并不存在。作者點(diǎn)評了二十世紀(jì)80年代前期為業(yè)界寄予厚望的一些新技術(shù)，討論了它們在克服軟件危機(jī)中所具備的優(yōu)勢和缺憾。

第十七章 再論“沒有銀彈”

相比《人月神話》初版而言，1986年發(fā)表的“沒有銀彈”（第十六章）發(fā)表后引發(fā)了熱烈的爭論，本章結(jié)合20世紀(jì)80年代后期到90年代前期之間軟件復(fù)用、面向?qū)ο蟪绦蜷_發(fā)等等新技術(shù)的發(fā)展?fàn)顩r，回應(yīng)了對《沒有銀彈》一文各種主要異議，認(rèn)為由于《沒有銀彈》一文歸納的軟件的幾大特性，人們期待中的重大突破不可能在近期內(nèi)到來。

第十八章 人月神話的觀點(diǎn)：是或非？

在撰寫《人月神話》的回顧和更新過程中，作者發(fā)現(xiàn)初版中斷言的觀點(diǎn)甚少被軟件工程研究和實踐所抨擊、證實或證偽，因此在本章中作者提煉了初版中十五個章節(jié)中的概要，結(jié)合近年來軟件技術(shù)的發(fā)展?fàn)顩r，對這些觀點(diǎn)進(jìn)行強(qiáng)調(diào)、修正和反思。

第十九章 二十年后的人月神話

在《人月神話》初版發(fā)布二十周年后，計算機(jī)技術(shù)領(lǐng)域已有很大變化，《人月神話》體現(xiàn)出深遠(yuǎn)的影響力，初版中的許多觀點(diǎn)依然經(jīng)常被人們談?wù)摵鸵?，其中有些斷言至今仍被軟件開放人員奉為圭臬。作者結(jié)合當(dāng)前軟件工程領(lǐng)域的發(fā)展現(xiàn)狀重新梳理了初版中的各核心觀點(diǎn)，強(qiáng)調(diào)了概念完整性，重新評議了第二個系統(tǒng)效應(yīng)，反省了瀑布模型的局限性，結(jié)合初版中的觀點(diǎn)，作者評述了圖形桌面系統(tǒng)、信息隱藏、面向?qū)ο蟾呒壵Z言等技術(shù)的發(fā)展，以及近年來軟件工程領(lǐng)域的重要成果。

總而言之，《人月神話》是一部IT界的著作，它就像是一顆“銀彈”，教會我們?nèi)绾稳ハ麥畿浖椖窟@只“人狼”，值得每個IT從業(yè)者認(rèn)真研讀。

第二篇：人月神話讀后感

人月神話讀后感

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

看完此書后，我發(fā)現(xiàn)人月神話無處不在，其實在我們做

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

二是“一個拿2倍工資的人，生產(chǎn)率可能是其他人的10倍?！辈恢榔渌镜某绦騿T們?nèi)绾慰础Ｎ矣X得，作為公司，應(yīng)該給最好的人最好的待遇，或者說給比目前更高的待遇。組建一個團(tuán)隊，最好的就是那種精英團(tuán)隊。微軟就是這

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

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

不同的社會經(jīng)驗，不同的思想狀態(tài)，對讀本書的心得也不一樣。在此我說說書中許多非常好的觀點(diǎn)。

1.外科手術(shù)隊伍The Surgical Team

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

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

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

3.畫蛇添足The Second-System Effect

講述的基本都是基于IBM 360操作系統(tǒng)以及編譯程序等方面的經(jīng)驗，講述如何避免開發(fā)第二個系統(tǒng)的風(fēng)險，作者認(rèn)為開發(fā)第二個系統(tǒng)的設(shè)計師設(shè)計出來的系統(tǒng)是最危險的,因此要求他們自律。

4.貫徹執(zhí)行Passing the word

印象比較深刻的是“體系結(jié)構(gòu)設(shè)計人員必須為自己描述的任何特性準(zhǔn)備一種實現(xiàn)方法，但他不應(yīng)該支配具體的實現(xiàn)過程?！?/p>

5.巴比倫塔會失敗Why did the Tower of Babel Fail?講述巴比倫塔會失敗的原因是缺乏交流。

6.胸有成竹Calling the Shot

主要講述如何計算編程時間，以及提出幾個人的經(jīng)驗算法。講述的各種算法可能都不太適合與現(xiàn)在的高級語言，但Portman的觀點(diǎn)仍然適合現(xiàn)在，即編程人員實際的編程時間只有50%，其他的時間都花在了無關(guān)的瑣碎事情上。

7.削足適履Ten Pounds in a Five-Pound Sack

主要講述程序占用的空間等，在70年代比較突出，但現(xiàn)在好多了。

8.提綱擎領(lǐng)The Documentary Hypothesis

說明文檔的作用

9.未雨綢繆Plan to Throw One Away

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

10.干將莫邪Sharp Tools

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

11.整體部分The Whole and the Parts

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

12.禍起蕭墻Hatching a Catastrophe

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

13.另外一面The other face

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

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

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

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

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

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

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

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

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

～-6-23　字?jǐn)?shù)：1345當(dāng)我捧起《人月神話》，馬上就被深深的吸引了。書中很多細(xì)微之處都對我的思維造成了沖擊。上一本給我類似感覺的書是那本四人幫的《設(shè)計模式》，已經(jīng)很久沒有看到這么好的書了，鄭重推薦。把感觸比較深的幾點(diǎn)記下來，順便整理一下自己的思路，與大家分享。1，保持設(shè)計的概念完整。無論對小軟件還是大軟件，都必須由一個設(shè)計師主導(dǎo)，最多兩個人討論來共同完成軟件的整體設(shè)計。作為一個軟件，一個系統(tǒng)，必須有一個清晰明確的概念模型，大家都在這個框架下工作，所有的創(chuàng)新發(fā)展都必須與基本的概念相吻合。具體的實現(xiàn)人員可以細(xì)化概念，但只有總設(shè)計者才有否定與發(fā)展基本概念的權(quán)力。需要注意的一點(diǎn)是，即使是總設(shè)計師一直是同一個人，他腦海中所認(rèn)為理所當(dāng)然的規(guī)則或者概念，很可能由于沒有明確的文檔化，而沒有成為所有開發(fā)者共同的概念。在其他開發(fā)者編碼的時候，就可能會生成與概念相抵觸的東東（模塊，功能，算法），導(dǎo)致整體結(jié)構(gòu)的惡化。這個時候總設(shè)計師一定要即時發(fā)現(xiàn)，做出更正。概念的完整性，對于很多小規(guī)模軟件，由于開發(fā)人員不多，開發(fā)經(jīng)理一般都能控制住所有的代碼，概念完整性在組織層面就維持住了。但要注意以后的Bug修改，功能擴(kuò)展的時候，也要時刻留意與最初的設(shè)計是否概念上相容。對于大規(guī)模的軟件系統(tǒng)，則必須通過樹狀組織結(jié)構(gòu)，層層控制，總設(shè)計師還是一到兩人，每一層都有對下層的絕對把握能力。我以前參加過一個15人左右的項目組，就是分為兩層。感覺整體概念完整性的控制效果還不錯。我沒有更多人數(shù)項目的具體實踐經(jīng)驗，希望以后能有機(jī)會參與比較大的項目。2，“一個拿2倍工資的人，生產(chǎn)率可能是其他人的10倍。”我和我的同學(xué)，一個小公司的技術(shù)總監(jiān)聊起這個，他也是十分的認(rèn)同。不知道其他公司的程序員們?nèi)绾慰?。我的同事中有一個牛人，做出的貢獻(xiàn)特別大，應(yīng)該相當(dāng)于我們公司普通的十個程序員，不過工資最多也就是普通程序員的二倍。是不是有些不公平呢？我也說不清楚。因為那些普通程序員也十分的努力。不過，我覺得，作為公司，應(yīng)該給最好的人最好的待遇，或者說給比目前更高的待遇。組建一個團(tuán)隊，最好的就是那種精英團(tuán)隊，大家都是牛人，效率會特別高。微軟就是這種思路吧，把最聰明的人集中在一起，想不成功都難亞。3，進(jìn)度落后與增加人力。記得當(dāng)年看《C＋＋編程思想》，Bruce說“十個婦女不能在一個月內(nèi)生下小孩”（大意），于我心有戚戚焉。而本書作者Brooks得出的結(jié)論是對我是震撼性的：“向進(jìn)度落后的項目中增加人手，只會使進(jìn)度更加落后”。以前，增加人手基本是挽救進(jìn)度落后項目的主要辦法。這個辦法行不通的話，難道只有“加班”一條路了？但長期加班是對個人的摧殘，我更愿意利用業(yè)余時間去看書，例如看這本“人月神話”。：）如果不想加班，不想削減功能，不想推遲發(fā)布日期，那么。。。唯一的方法還是只有….加人。加足夠的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能對原來的組織造成沖擊，或者對原來的設(shè)計有不同意見（特別是加入的人中有比較強(qiáng)大的設(shè)計者）。那么，就當(dāng)作，新組建了一個團(tuán)隊吧。交流，培訓(xùn)新人，就設(shè)計達(dá)成一致，繼續(xù)向者目標(biāo)前進(jìn)。感觸還有很多，以后如果有機(jī)會再寫。不過，我決定去買本英文版回來，收藏，以后再多看幾次。

第四篇：人月神話筆記

人月神話讀書筆記(一)

第一章 焦油坑

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

解決，但是當(dāng)它們相互糾纏和積累在一起的時候，團(tuán)隊的行動就會變

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

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

解它。--清楚地解釋系統(tǒng)開發(fā)的困難所在。

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

存的創(chuàng)造性活動。對于許多人而言，其中的樂趣遠(yuǎn)大于苦惱。而本書的剩余部分將試圖搭建一些橋梁，為通過這樣的焦油坑提供一些指導(dǎo)。

--本書的目的第二章 人月神話

1.在眾多軟件項目中，缺乏合理的時間進(jìn)度是造成項目滯后的最主要原因，它比其他所有因素加起來的影響還大。導(dǎo)致災(zāi)難的原因是：

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

第二，我們采用的估算技術(shù)隱含地假設(shè)人和月可以互換，錯誤地將進(jìn)度與工作量相互混淆

第三，由于對自己的估算缺乏信心，軟件經(jīng)理通常不會有耐心持續(xù)地進(jìn)行估算這項工作。第四，對進(jìn)度缺少跟蹤和監(jiān)督。

第五，當(dāng)意識到進(jìn)度的偏移時，下意識（以及傳統(tǒng)）的反應(yīng)是增加人力。

2.系統(tǒng)開發(fā)過程中，樂觀主義并不應(yīng)該是理所應(yīng)當(dāng)?shù)摹?/p>

在單個任務(wù)中，“一切都將運(yùn)轉(zhuǎn)正?！钡募僭O(shè)在時間進(jìn)度上具有可實現(xiàn)性。因為所遇的延遲是一個概率分布曲線，“不會延遲”僅具有有限的概率，所以現(xiàn)實情況可能會像計劃安排的那樣順利。然而大型的編程工作，或多或少包含了很多任務(wù)，某些任務(wù)間還具有前后的次序，從而一切正常的概率變得非常小，甚至接近于無。

3.成本的確隨開發(fā)產(chǎn)品的人數(shù)和時間的不同，有著很大的變化，進(jìn)度卻不是如此。因此我認(rèn)為用人月作為衡量一項工作的規(guī)模是一個危險和帶有欺騙性的神話。它暗示著人員數(shù)量和時間是可以相互替換的。

因為軟件開發(fā)本質(zhì)上是一項系統(tǒng)的工作--錯綜復(fù)雜關(guān)系下的一種實踐--溝通、交流的工作量非常大，它很快會消耗任務(wù)分解所節(jié)省下來的個人時間。從而，添加更多的人手，實際上是延長了，而不是縮短了時間進(jìn)度。

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

對于任務(wù)的進(jìn)度安排，以下是作者使用了很多年的經(jīng)驗法則：

1/3 計劃

1/6 編碼

1/4 構(gòu)件測試和早期系統(tǒng)測試（單元測試）

1/4 系統(tǒng)測試

5.如果發(fā)現(xiàn)項目的實際進(jìn)度滯后于預(yù)計的進(jìn)度，項目經(jīng)理最好的辦法是重新安排進(jìn)度，而不是增加項目人手。

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

起來的影響還要大。

第三章 外科手術(shù)隊伍

1.對于效率和概念的完整性來說，最好由少數(shù)干練的人員來設(shè)計和開發(fā)，而對于大型 系統(tǒng)，則需要大量的人手，以使產(chǎn)品能在時間上滿足要求。如何調(diào)和這兩方面的矛盾呢？--本章要解決的問題

2.Mills的建議：

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

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

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

兩個秘書

程序職員：維護(hù)編程產(chǎn)品庫中所有團(tuán)隊的技術(shù)記錄。

工具維護(hù)人員：保證所有基本服務(wù)的可靠性，以及承擔(dān)團(tuán)隊成員所需要的特殊工具（特 別是交互式計算機(jī)服務(wù)）的構(gòu)建、維護(hù)和升級責(zé)任。

測試人員：各個功能設(shè)計系統(tǒng)測試用例的對頭，同時也是日常調(diào)試設(shè)計測試數(shù)據(jù)的助手。負(fù)責(zé)計劃測試的步驟和為測試搭建測試平臺。

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

3.當(dāng)進(jìn)行大系統(tǒng)開發(fā)時：

要有一個系統(tǒng)結(jié)構(gòu)師從上至下地進(jìn)行所有的設(shè)計。要使工作易于管理，必須清晰地劃分體

系結(jié)構(gòu)設(shè)計和實現(xiàn)之間的界線，系統(tǒng)結(jié)構(gòu)師必須一絲不茍地專注于體系結(jié)構(gòu)。

第四章 貴族專制、民主政治和系統(tǒng)設(shè)計

1.概念一致性

在系統(tǒng)設(shè)計中，概念完整性應(yīng)該是最重要的考慮因素。也就是說為了反映一系列 連貫的設(shè)計思路，寧可省略一些不規(guī)則的特性和改進(jìn)，也不提倡獨(dú)立和無法整合 的系統(tǒng)，哪怕它們其實包含著許多很好的設(shè)計。

2.功能與理解上復(fù)雜程度的比值才是系統(tǒng)設(shè)計的最終測試標(biāo)準(zhǔn)。但是功能本身 或者易于使用都無法成為一個好的設(shè)計評判標(biāo)準(zhǔn)。

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

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

5.系統(tǒng)的體系結(jié)構(gòu)(architecture)指的是完整和詳細(xì)的用戶接口說明。體系結(jié) 構(gòu)必須同實現(xiàn)仔細(xì)地區(qū)分開來。

6.作者不認(rèn)為只有結(jié)構(gòu)師才有好的創(chuàng)意。新的概念經(jīng)常來自實現(xiàn)者或者用戶。然而系統(tǒng)的概念完整性決定了使用的容易程度。不能與系統(tǒng)基本概念進(jìn)行整合的 良好想法和特色，最好放到一邊，不予考慮。如果出現(xiàn)了很多非常重要但不兼容 的構(gòu)想，就應(yīng)該拋棄原來的設(shè)計，對不同基本概念進(jìn)行合并，在合并后的系統(tǒng)上 重新開始。

7.概念的完整性的確要求系統(tǒng)只反映唯一的設(shè)計理念，用戶所見的技術(shù)說明來 自少數(shù)人的思想。實際工作被劃分成體系結(jié)構(gòu)、設(shè)計實現(xiàn)和物理實現(xiàn)，但這并不 意味著該開發(fā)模式下的系統(tǒng)需要更長的時間來創(chuàng)建。經(jīng)驗顯示恰恰相反，整個系

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

第五章 畫蛇添足

1.本章的目標(biāo)：結(jié)構(gòu)設(shè)計師要避免向系統(tǒng)中添加很多不實際的功能（避免

畫蛇添足）。

2.盡早交流和持續(xù)溝通能使結(jié)構(gòu)師有較好的成本意識，以及使開發(fā)人員獲

得對設(shè)計的信心，并且不會混淆各自的責(zé)任分工。

3.面對估算過高的難題，結(jié)構(gòu)師有兩個選擇：削減設(shè)計或者建議成本更低的實現(xiàn)方法--挑戰(zhàn)估算的結(jié)果。后者是固有的主觀感性反應(yīng)。此時，結(jié)構(gòu)師 是在向開發(fā)人員的做事方式提出挑戰(zhàn)。想要成功，結(jié)構(gòu)師必須

牢記是開發(fā)人員承擔(dān)創(chuàng)造性和發(fā)明性的實現(xiàn)責(zé)任，所以結(jié)構(gòu)師只能建議，而 不能支配；

時刻準(zhǔn)備著為所指定的說明建議一種實現(xiàn)的方法，同樣準(zhǔn)備接受其他任何能 達(dá)到目標(biāo)的方法；

對上述的建議保持低調(diào)和平靜；

準(zhǔn)備放棄堅持所作的改進(jìn)建議。

4.一個可以開闊結(jié)構(gòu)師眼界的準(zhǔn)則是為每個小功能分配一個值：每次改進(jìn)，功能 x 不超過 m 字節(jié)的內(nèi)存和 n 微秒。這些值會在一開始作為決策的向?qū)?，在物理實現(xiàn)期間指南和對所有人的警示。

5.項目經(jīng)理必須堅持至少擁有兩個系統(tǒng)以上開發(fā)經(jīng)驗的結(jié)構(gòu)師的決定。同時，保持對特殊誘惑的警覺，他可以不斷提出正確的問題，確保原則上的概念和 目標(biāo)在詳細(xì)設(shè)計中得到完整的體現(xiàn)。

第六章 貫徹執(zhí)行

1.問題：項目經(jīng)理如何確保每個人聽從、理解并實現(xiàn)結(jié)構(gòu)師的決策？對于有多個結(jié)構(gòu)師的小組如何保持系統(tǒng)概念上的完整性。

2.手冊、或者書面規(guī)格說明，是一個非常必要的工具。手冊是產(chǎn)品的外部規(guī)格說明，它

描述和規(guī)定了用戶所見的每一個細(xì)節(jié)；同樣的，它也是結(jié)構(gòu)師主要的工作產(chǎn)物。

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

后者是編程實現(xiàn)人員的工作范疇，而實現(xiàn)人員的設(shè)計和創(chuàng)造是不應(yīng)該被限制的。體系結(jié)構(gòu)

設(shè)計人員必須為自己描述的任何特性準(zhǔn)備一種實現(xiàn)方法，但是他不應(yīng)該試圖支配具體的實

現(xiàn)過程。

規(guī)格說明的風(fēng)格必須清晰、完整和準(zhǔn)確。用戶常常會單獨(dú)提到某個定義，所以每條說明都

必須重復(fù)所有的基本要素，所以所有文字都要相互一致。

3.規(guī)格說明中，形式化定義是精確的，它們傾向于更加完整；差異得更加明顯，可以更

快地完成。但是形式化定義的缺點(diǎn)是不易理解。記敘性文字則可以顯示結(jié)構(gòu)性的原則，描

述階段上或?qū)哟紊系慕Y(jié)構(gòu)，以及提供例子。應(yīng)同時包括形式化和記敘性定義兩種方式。

4.通過會議的方式，開發(fā)人員進(jìn)行溝通和討論問題。

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

整潔和規(guī)范。

6.對于存有疑問的實現(xiàn)人員，應(yīng)鼓勵他們打電話詢問相應(yīng)的結(jié)構(gòu)師，而不是一邊自行猜

測一邊工作。

一種有用的機(jī)制是由結(jié)構(gòu)師保存電話日志。日志中，他記錄了每一個問題和相應(yīng)的回答。每周，對若干結(jié)構(gòu)師的日志進(jìn)行合并，重新整理，并發(fā)布給用戶和實現(xiàn)人員。這種機(jī)制很

不正式，但非?？旖莺鸵子诶斫?。

7.在最后的分析中，用戶是獨(dú)立的監(jiān)督人員。在殘酷的現(xiàn)實使用環(huán)境中，每個細(xì)微缺陷

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

試人員總會發(fā)現(xiàn)一些沒有貫徹執(zhí)行、設(shè)計決策沒有正確理解或準(zhǔn)確實現(xiàn)的地方。出于這方

面的原因，設(shè)立測試小組是使設(shè)計決策得以貫徹執(zhí)行的必要手段，同樣也是需要盡早著手，與設(shè)計同時實現(xiàn)的重要環(huán)節(jié)。

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

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

2.缺乏交流引起進(jìn)度災(zāi)難、功能的不合理和系統(tǒng)缺陷紛紛出現(xiàn)。隨著工作的進(jìn)行，許多小組慢慢地修改自己程序的功能、規(guī)模和速度，他們明確或者隱含地更改了一些有效輸入和輸出結(jié)果用法上的約定。

團(tuán)隊如何進(jìn)行相互之間的交流溝通：

清晰定義小組內(nèi)部的相互關(guān)系和充分利用電話，能鼓勵大量的電話溝通，從而達(dá)到對所書寫文檔的共同理解。

常規(guī)項目會議。會議中，團(tuán)隊一個接一個地進(jìn)行簡要的技術(shù)陳述。這種方式非常有用，能澄清成百上千的細(xì)小誤解。

在項目的開始階段，應(yīng)該準(zhǔn)備正式的項目工作手冊。

3.項目工作手冊不是獨(dú)立的一篇文檔，它是對項目必須產(chǎn)出的一系列文檔進(jìn)行組織的一種結(jié)構(gòu)。

項目所有的文檔都必須是該結(jié)構(gòu)的一部分。這包括目的、外部規(guī)格說明、接口說明、技術(shù)標(biāo)準(zhǔn)、內(nèi)部說明和管理備忘錄。

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

技術(shù)說明幾乎是必不可少的。如果某人就硬件和軟件的某部分，去查看一系列相關(guān)的用戶手冊。他發(fā)現(xiàn)的不僅僅是思路，而且還有能追溯到最早備忘錄的許多文字和章節(jié)，這些備忘錄對產(chǎn)品提出建議或者解釋設(shè)計。

正確的文檔結(jié)構(gòu)非常重要。事先將項目工作手冊設(shè)計好，能保證文檔的結(jié)構(gòu)本身是規(guī)范的。另外，有了文檔結(jié)構(gòu)，后來書寫的文字就可以放置在合適的章節(jié)中。

控制信息發(fā)布，確保信息能到達(dá)所有需要它的人的手中。

5.團(tuán)隊組織的目的是減少不必要的交流和合作的數(shù)量。減少交流的方法是人力劃分和限定職責(zé)范圍。當(dāng)使用人力劃分和職責(zé)限定時，樹狀管理結(jié)構(gòu)所映出對詳細(xì)交流的需要會相應(yīng)減少。

第八章 胸有成竹

1.問題：系統(tǒng)編程需要花費(fèi)多長時間？需要多少工作量？如何進(jìn)行估計？

2.工作量是規(guī)模的冪函數(shù)。

Portman的數(shù)據(jù)：工作花費(fèi)的時間大約是估計的兩倍。

Aron、Harr、OS/360的數(shù)據(jù)：生產(chǎn)率會根據(jù)任務(wù)本身的復(fù)雜度和困難程度表現(xiàn)出顯著差異。

Carbato的數(shù)據(jù)：對常用的編程語句而言。生產(chǎn)率似乎是固定的。這個固定的生產(chǎn)率包括了編程中需要注釋，并可能存在錯誤的情況。使用適當(dāng)?shù)母呒壵Z言，編程的 生產(chǎn)率可以提高5倍。

第九章 削足適履

1.系統(tǒng)的空間規(guī)模：規(guī)模是軟件系統(tǒng)產(chǎn)品用戶成本中如此大的一個組成部分，開發(fā) 人員必須設(shè)置規(guī)模的目標(biāo)，控制規(guī)模，考慮減小規(guī)模的方法。同任何開銷一樣，規(guī)模 本身不是壞事，但不必要的規(guī)模是不可取的。

2.對項目經(jīng)理而言，規(guī)?？刂萍仁羌夹g(shù)工作的一部分，也是管理工作的一部分。必 須研究用戶和他們的應(yīng)用，以設(shè)置將開發(fā)系統(tǒng)的規(guī)模。接著，把這些系統(tǒng)劃分成若干 部分，并設(shè)定每個部分的規(guī)模目標(biāo)。由于規(guī)模--速度權(quán)衡方案的結(jié)果在很大的范圍內(nèi) 變化，規(guī)模目標(biāo)的設(shè)置是一件頗具技巧的事情，需要對每個可用方案有深刻的了解。聰明的項目經(jīng)理還會給自己預(yù)留一些空間，在工作推行時分配。

僅對核心程序設(shè)定規(guī)模目標(biāo)是不夠的，必須把所有的方面都編入預(yù)算。

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

培養(yǎng)開發(fā)人員從系統(tǒng)整體出發(fā)，面對用戶的態(tài)度。

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

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

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

5.戰(zhàn)略上的突破常來自數(shù)據(jù)或表的重新表達(dá)--這是程序的核心所在。數(shù)據(jù)的表現(xiàn)形 式時編程的根本。

第十章 提綱挈領(lǐng)

1.文檔的跟蹤維護(hù)是項目監(jiān)督和預(yù)警的機(jī)制。文檔本身可以作為檢查

列表、狀態(tài)控制，也可以作為匯報的數(shù)據(jù)基礎(chǔ)。

2.軟件項目文檔的內(nèi)容：

目標(biāo)。待完成的目標(biāo)、迫切需要的資源、約束和優(yōu)先級。軟件開發(fā)網(wǎng)

產(chǎn)品技術(shù)說明。

進(jìn)度表。

資金預(yù)算。

工作空間分配。

人員組織。

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

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

定的決策。

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

都向著相同的方向前進(jìn)，所以他的工作主要是溝通，而不是做出決定。文

檔能極大地減輕他的負(fù)擔(dān)。

最后，文檔可以作為數(shù)據(jù)基礎(chǔ)和檢查列表。通過周期性的回顧，他能清楚

項目所處的狀態(tài)，以及哪些需要重點(diǎn)進(jìn)行更改和調(diào)整。

項目經(jīng)理的任務(wù)是制訂計劃，并根據(jù)計劃實現(xiàn)。只有書面計劃是精確和可

以溝通的。通過遵循文檔開展工作，項目經(jīng)理能更清晰和快速地設(shè)定自己的方向。

第十一章 未雨綢繆

1.對于大多數(shù)項目，第一個開發(fā)的系統(tǒng)并不合用?？赡芴⑻?，而且難以 使用，或者三者兼而有之。要解決所有的問題，除了重新開始以外，沒有其他的 辦法--即開發(fā)一個更靈巧或者更好的系統(tǒng)。系統(tǒng)的丟棄和重新設(shè)計可以一步完成，也可以一塊塊地實現(xiàn)。所有大型系統(tǒng)的經(jīng)驗都顯示，這是必須完成的步驟。--構(gòu)建一個試驗性的系統(tǒng)，然后拋棄它。

2.一旦認(rèn)識到實驗性的系統(tǒng)必須被構(gòu)建和丟棄，具有變更思想的重新設(shè)計不可 避免。

3.為變化設(shè)計系統(tǒng)，包括細(xì)致的模塊化、可擴(kuò)展的函數(shù)、精確完整的模塊間接 口設(shè)計、完備的文檔。另外，還可能會采用包括調(diào)用隊列和表驅(qū)動技術(shù)。

最重要的措施是使用高級語言和自文檔技術(shù)，以減少變更引起的錯誤。采用編譯時的操作來整合標(biāo)準(zhǔn)說明，在很大程度上幫助了變化的調(diào)整。

變更的階段化是一種必要的技術(shù)。每個產(chǎn)品都應(yīng)該有數(shù)字版本號，每個版本都應(yīng) 該有自己的日程表和凍結(jié)日期。在此之后的變更屬于下一個版本的范疇。

4.為變更計劃組織架構(gòu)和團(tuán)隊。

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

缺陷不能被徹底修復(fù)的原因：

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

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

6.維護(hù)工作破壞系統(tǒng)的架構(gòu)，增加了系統(tǒng)的混亂程度。隨著時間的推移，系統(tǒng) 變得越來越無序，無法再成為下一步進(jìn)展的基礎(chǔ)。這時，系統(tǒng)的重新設(shè)計完全是 必要的。

系統(tǒng)軟件開發(fā)是減少混亂度的過程，軟件維護(hù)是提高混亂度的過程，即使是最熟 練的軟件維護(hù)工作，也只是放緩了系統(tǒng)退化的進(jìn)程。

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

第1章 焦油坑

這一章分成兩個部分：

? 程序（Program）、程序產(chǎn)品（Programming Product）、編程系統(tǒng)（Programming System）、編程系統(tǒng)產(chǎn)品（Programming Product System）的概念

? 程序員的工作性質(zhì)

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

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

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

最高級的形式是編程系統(tǒng)產(chǎn)品，從書中的表述來看，就是編程系統(tǒng)+各類文檔，文檔是為了后續(xù)維護(hù)和升級方便而準(zhǔn)備的。智力產(chǎn)品如果沒有說明書真是一場噩夢啊，之前我們經(jīng)歷過的不少系統(tǒng)到了后續(xù)維護(hù)的時候發(fā)現(xiàn)文檔補(bǔ)齊，維護(hù)人員真是傷透腦筋，最后問題太多了索性就提議推倒重做?？梢哉f如果是文檔齊備一點(diǎn)，我們公司很多系統(tǒng)的壽命是可以更長的。

第2章 人月神話