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

～-7-6　字?jǐn)?shù)：407

1不同的社會經(jīng)驗(yàn)，不同的思想狀態(tài)，對讀本書的心得也不一樣，我在此說說我的讀后感，書中有許多非常好的觀點(diǎn)，但我只把我感觸最深的寫下來。這確實(shí)是一本很值得多次閱讀的好書，每次閱讀可能都能從中得到一些提示。

1.外科手術(shù)隊(duì)伍TheSurgicalTeam

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

2.貴族～，民主政治Aristocracy，Democracy，System

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

有四個問題：

1。如何得到概念的完整性

2。是否要有一位杰出的精英，或者說是結(jié)構(gòu)設(shè)計(jì)師的貴族～.....3.如何避免結(jié)構(gòu)設(shè)計(jì)師產(chǎn)出無法實(shí)現(xiàn)或代價(jià)高昂的技術(shù)規(guī)格說明，使大家陷入困境。

4。如何才能與實(shí)現(xiàn)人員就技術(shù)說明的瑣碎細(xì)節(jié)充分溝通，以確保設(shè)計(jì)被正確地理解，并精確地整合到產(chǎn)品中。

對1。2。4的回答基本上都可以找到，但第3個似乎找不到。

3.畫蛇添足TheSecond-SystemEffect

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

4.貫徹執(zhí)行passingtheword

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

5.為什么巴比倫塔會失敗WhydidtheTowerofBabelFail？

講述巴比倫塔會失敗的原因是缺乏交流。

6.胸有成竹CallingtheShot

主要講述如何計(jì)算編程時間，以及提出幾個人的經(jīng)驗(yàn)算法。

講述的各種算法可能都不太適合與現(xiàn)在的高級語言，但portman的觀點(diǎn)仍然適合現(xiàn)在，即編程人員實(shí)際的編程時間只有50％，其他的時間都花在了無關(guān)的瑣碎事情上。

7.削足適履TenpoundsinaFive-poundSack

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

8.提綱擎領(lǐng)TheDocumentaryHypothesis

說明文檔的作用

9.未雨綢繆plantoThrowOneAway

唯一不變的是變化本身。

在大型項(xiàng)目中，項(xiàng)目經(jīng)理需要有兩個和三個頂級程序員作為技術(shù)輕騎兵，當(dāng)工作繁忙最密集的時候，他們能急馳飛奔，解決各種問題。講述技術(shù)人員與項(xiàng)目人員的互換是，對我有一定的提示，但圖中IBM的兩條職位晉升線，不太理解。

10.干將莫邪SharpTools

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

11.整體部分TheWholeandtheparts

一讀這一章，就讓我感觸頗深，特別是這句話＂BELL實(shí)驗(yàn)室監(jiān)控系統(tǒng)項(xiàng)目的V.A.Vyssotsky提出，＇關(guān)鍵的工作是產(chǎn)品定義。許許多多的失敗完全源于那些產(chǎn)品未精確定義的地方＇，細(xì)致的功能定義，詳細(xì)的規(guī)格說明，規(guī)范話的功能描述說明以及這些方法的實(shí)施，大大減少了系統(tǒng)中必須查找的BUG數(shù)量＂。雖然這句話的意思只是說明精確定義產(chǎn)品將減少BUG的數(shù)量，但我看到了系統(tǒng)分析的最重要的工作——產(chǎn)品定義?，F(xiàn)在，許多開發(fā)人員嘴里口口聲聲說也做過需求調(diào)研、系統(tǒng)分析、系統(tǒng)設(shè)計(jì)，但大多數(shù)沒有涉及到產(chǎn)品定義的深度，嚴(yán)格意義上不能叫做系統(tǒng)分析。這句話對我的以后想從事系統(tǒng)分析工作有很大的幫助。

這一章余下的內(nèi)容，也值得一看，雖然有些地方有些過時，但剔除BUG的設(shè)計(jì)以及部分測試/調(diào)試方法仍值得一看。

12.禍起蕭墻HatchingaCatastrophe

這章節(jié)說明使項(xiàng)目進(jìn)度拖后的最大原因不是重要的事件，如新技術(shù)、重組等，而是一些瑣碎的小事，每件小事只耽誤半天或一天時間，但這種小事多以后，將使項(xiàng)目的進(jìn)度嚴(yán)重拖后。

項(xiàng)目對于公司就如程序?qū)y試工程師一樣，如果不了解它，它就是一個黑盒子，如果不打開這個黑盒子，你可能永遠(yuǎn)不知道盒子里面有什么。這部分描寫項(xiàng)目經(jīng)理以及小組主管的一些心理，值得一看。

13.另外一面Theotherface

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

不了解，就無法真正擁有——歌德，作者引用的歌德的話來描述文檔對客戶的重要性，提出客戶需要什么樣的文檔以及文檔的格式和包含的內(nèi)容，指出當(dāng)時存在的大多數(shù)文檔只描述了樹木，形容了樹葉，但沒有整個森林的圖案。

想想，這種情況在現(xiàn)在仍然沒有改變。于是作者提出了兩個觀點(diǎn)：

&n

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

2.自文檔化（self-documenting）的程序：提出文檔與程序合為一體，能很好的解決文檔與程序分開造成的文檔過時的問題，并說明了在程序中加入文檔的一些方法和技巧。2002年，我看到一位網(wǎng)友關(guān)于文檔與程序合一的文章，當(dāng)時就覺得是個好方法，沒想到70年代，老美已經(jīng)提出來了。

14.沒有銀彈-軟件工程中的根本和次要問題(NoSilverBullet-EssenceandAccidentinsoftwareEngineering)

這是一篇論文，發(fā)表于1986年，我自認(rèn)為我的理論水平?jīng)]有上升到可以對他的論點(diǎn)和論據(jù)做出懷疑或質(zhì)疑的結(jié)論，我只是說說我的感想。

人狼是傳說中的妖怪，只有銀彈才能殺死他。作者認(rèn)為軟件項(xiàng)目具有人狼的特性，因?yàn)檐浖?xiàng)目也可能變成一個怪物，一個落后進(jìn)度、超出預(yù)算、存在大量缺陷的怪物。作者通過軟件系統(tǒng)的內(nèi)在特性復(fù)雜性、一致性、可變性和不可見性來分析說明了軟件天生就沒有銀彈。

作者試圖通過分析軟件問題的本質(zhì)和很多侯選銀彈的特征來探究其中的原因。他行動的第一步是將大塊的“巨無霸理論”替換成“微生物理論”。這個變化的過程告訴你，進(jìn)步是逐步取得的，伴隨著辛勤的勞動，對規(guī)范化過程應(yīng)

進(jìn)行持續(xù)不懈的努力，而這個努力的過程相應(yīng)的就誕生了軟件工程。作者對軟件工程誕生的原因做出這樣的解釋，我覺得符合外國思維的特點(diǎn)，這正是國人所缺乏。記得有一位朋友說過，中國媽媽與德國媽媽的區(qū)別，他說，如果手里拿的針掉到地上了，中國媽媽的第一反應(yīng)是估計(jì)針掉下去的范圍，然后在這個范圍里面找，可能很快就找到了，也可能一直都找不到；但德國媽媽不同，她會拿一根粉筆來，把整個屋子畫成一個大圈，接著把大圈分成許許多多的小圈，然后再到每個小圈里找，雖然比較慢，但最終肯定可以找到。仔細(xì)想象，大多數(shù)情況下，中國媽媽都會找到得比較快，這確實(shí)符合大多數(shù)中國媽媽的思維習(xí)慣，每個中國媽媽都這樣找，這好象是與生俱來的本事，但為什么德國媽媽沒有這個本事呢？是德國媽媽笨嗎？為什么中國媽媽也有找不到的情況？而德國媽媽，雖然速度慢了點(diǎn)，卻始終能夠找得到？如果把這件故事推而廣之，多年以后，德國媽媽創(chuàng)建了找針工程，她通過多次找針的實(shí)驗(yàn)數(shù)據(jù)，分析出針掉到整個房間中各個小圈的概率，總結(jié)出針在哪個小圈的概率最大，很快就可以找到針，找針?biāo)俣仍缫迅哌^中國媽媽，而中國媽媽還在依循與生俱來的本事。你能說德國媽媽笨嗎？為什么中國媽媽和德國媽媽會有這么大的區(qū)別？是德國媽媽把大塊的“巨無霸理論”替換成“微生物理論”嗎？我覺得是是，你說呢？作者在后面的論述中用數(shù)學(xué)和物理的發(fā)展為例子也說明了，這種思想的成立。

余下的作者把軟件工程按“巨無霸理論”替換成“微生物理論”的過程詳細(xì)的說明，值得看，我關(guān)注的不是具體的內(nèi)容，具體內(nèi)容可能有些不合適宜，我關(guān)注的是作者的思考方式以及處理方法，這是非常重要的。

在“以往解決次要困難的一些突破”和“銀彈的希望”章節(jié)，從概念上講述了軟件的發(fā)展，其中講到“專家系統(tǒng)”時，使我想起一部科幻電影，忘了電影名字了，有個情節(jié)大致是這樣的，一位非常有經(jīng)驗(yàn)的主管死后，有一名較優(yōu)秀的下屬接任，但這時出現(xiàn)了一位非常厲害的敵人，這位新主管無論如何也戰(zhàn)勝不了敵人，這時想起了以前的主管，心想前主管一定有辦法對付這個敵人，而前主管的大腦就存放在系統(tǒng)里，

第二篇：人月神話讀后感

人月神話讀后感

二十九年前(1975)﹐IBM大型電腦之父──Fred Brooks 出版一本書﹕“The Mythical Man-Month”。收集了他在1960年代領(lǐng)導(dǎo)1000多人共同發(fā)展OS/360大型軟件系統(tǒng)的心得和經(jīng)驗(yàn)。該書是論文集﹐其中有一篇文章叫“The Mythical Man-Month”﹐他就以此作為書名。在1956~1965 之間﹐Brooks實(shí)際領(lǐng)導(dǎo)IBM 360 大型電腦的開發(fā)計(jì)劃﹐包括硬體結(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)驗(yàn)心得收集在這本書里。人們常拿Man-Month（多少人﹐做多少個月）來計(jì)算軟件的工作量﹐但是Brooks發(fā)現(xiàn)軟件的開發(fā)工作是需要人與人之間密切溝通的﹐使得設(shè)計(jì)工作不易分割﹐所以Man-Month 為單位的計(jì)算方法是有問題的(mythical)。也就得出著名的Brooks法則── 「對于進(jìn)度已落后的軟件開發(fā)計(jì)劃而言﹐若再增加人力﹐只會讓其更加落后?！?Adding manpower to a late software project makes it later)這是該書名稱的涵義。

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

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

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

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

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

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

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

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

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

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

3.畫蛇添足The Second-System Effect

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

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

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

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

6.胸有成竹Calling the Shot

主要講述如何計(jì)算編程時間，以及提出幾個人的經(jīng)驗(yàn)算法。講述的各種算法可能都不太適合與現(xiàn)在的高級語言，但Portman的觀點(diǎn)仍然適合現(xiàn)在，即編程人員實(shí)際的編程時間只有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

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

10.干將莫邪Sharp Tools

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

11.整體部分The Whole and the Parts

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

12.禍起蕭墻Hatching a Catastrophe

這章節(jié)說明使項(xiàng)目進(jìn)度拖后的最大原因不是重要的事件，如新技術(shù)、重組等，而是一些瑣碎的小事，每件小事只耽誤半天或一天時間，但這種小事多以后，將使項(xiàng)目的進(jìn)度嚴(yán)重拖后。項(xiàng)目對于公司就如程序?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)為軟件項(xiàng)目具有人狼的特性，因?yàn)檐浖?xiàng)目也可能變成一個怪物，一個落后進(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è)計(jì)和測試等概念的結(jié)構(gòu)，而不是概念的表述和實(shí)現(xiàn)概念，雖然實(shí)現(xiàn)概念可能占用了小于90%的時間，就如現(xiàn)今的軟件開發(fā)一樣，系統(tǒng)分析通常占用的整個項(xiàng)目開發(fā)時間不超過20%，而80%的時間花在編程上一樣。

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

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

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

《人月神話》讀后感

通過閱讀《人月神話》，我從中學(xué)到了一些東西：

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

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

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

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

良好的工作手冊和組織架構(gòu)可以開發(fā)出更加符合用戶的需求。手冊、或者書面規(guī)格說明，是一個非常必要的工具，盡管光有文檔是不夠的。手冊是產(chǎn)品的外部規(guī)格說明，它描述和規(guī)定了用戶所見的每一個細(xì)節(jié)；同樣的，它也是結(jié)構(gòu)師主要的工作產(chǎn)物。

形式化定義是精確的，它們傾向于更加完整；差異得更加明顯，可以更快地完成。但是形式化定義的缺點(diǎn)是不易理解。記敘性文字則可以顯示結(jié)構(gòu)性的原則，描述階段上或?qū)哟紊系慕Y(jié)構(gòu)，以及提供例子。它可以很容易地表達(dá)異常和強(qiáng)調(diào)對比的關(guān)系，最重要的是，它可以解釋原因。在表達(dá)的精確和簡明性上，目前所提出的形式化定義，具有了令人驚異的效果，增強(qiáng)了我們進(jìn)行準(zhǔn)確表達(dá)的信心。

通常，開發(fā)一個軟件我們還會設(shè)立規(guī)模目標(biāo)，控制規(guī)模，發(fā)明一些減少規(guī)模的方法——

就如同硬件開發(fā)人員為減少元器件所做的一樣。規(guī)模預(yù)算必須與分配的功能相關(guān)聯(lián)； 在指明模塊大小的同時，確切定義模塊的功能。培養(yǎng)開發(fā)人員從系統(tǒng)整體出發(fā)、面向用戶的態(tài)度是軟件編程管理人員最重要的職能。

調(diào)試，是一種檢驗(yàn)程序中的方法。然而調(diào)試是系統(tǒng)編程中很慢和較困難的部分，而漫長的調(diào)試周轉(zhuǎn)時間是調(diào)試的禍根。它可以持續(xù)一個很長的時間，從而可能影響項(xiàng)目的交付日期。

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

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

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

在計(jì)算機(jī)技術(shù)進(jìn)步的同時，計(jì)算機(jī)相關(guān)學(xué)科知識也在飛速發(fā)展。興趣太多，令人興奮的學(xué)習(xí)、研究和思考的機(jī)會也太多——多么不可思議的矛盾??！這個神奇的時代遠(yuǎn)遠(yuǎn)沒有結(jié)束，它依然在飛速發(fā)展。更多的樂趣，盡在將來。

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

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

《人月神話》讀后感

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

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

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

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

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

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

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

形式化定義是精確的，它們傾向于更加完整；差異得更加明顯，可以更快地完成。但是形式化定義的缺點(diǎn)是不易理解。記敘性文字則可以顯示結(jié)構(gòu)性的原則，描述階段上或?qū)哟紊系慕Y(jié)構(gòu)，以及提供例子。它可以很容易地表達(dá)異常和強(qiáng)調(diào)對比的關(guān)系，最重要的是，它可以解釋原因。在表達(dá)的精確和簡明性上，目前所提出的形式化定義，具有了令人驚異的效果，增強(qiáng)了我們進(jìn)行準(zhǔn)確表達(dá)的信心。

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

調(diào)試，是一種檢驗(yàn)程序中的方法。然而調(diào)試是系統(tǒng)編程中很慢和較困難的部分，而漫長的調(diào)試周轉(zhuǎn)時間是調(diào)試的禍根。它可以持續(xù)一個很長的時間，從而可能影響項(xiàng)目的交付日期。

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

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

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

在計(jì)算機(jī)技術(shù)進(jìn)步的同時，計(jì)算機(jī)相關(guān)學(xué)科知識也在飛速發(fā)展。興趣太多，令人興奮的學(xué)習(xí)、研究和思考的機(jī)會也太多——多么不可思議的矛盾??！這個神奇的時代遠(yuǎn)遠(yuǎn)沒有結(jié)束，它依然在飛速發(fā)展。更多的樂趣，盡在將來。