《人月神話》是本神奇的書，竟然還用一章把前面各章的要點(diǎn)做了總結(jié)部服∷艚悖看前面章節(jié)的時(shí)候，就覺得作者的輸出觀點(diǎn)能力很強(qiáng)饲宿，很容易就忘了厦酬，最后作者竟然給了總結(jié)，實(shí)屬驚喜瘫想。摘錄在這里仗阅，常看常新国夜。

在看外科手術(shù)團(tuán)隊(duì)這章時(shí)减噪，聯(lián)想到阿米巴經(jīng)營也用了類似的管理方法。

第 1 章 焦油坑

1.1 編程系統(tǒng)產(chǎn)品（Programming Systems Product）開發(fā)的工作量是供個(gè)人使用的车吹、獨(dú)立開發(fā)的構(gòu)件程序的九倍筹裕。我估計(jì)軟件構(gòu)件產(chǎn)品化引起了 3 倍工作量，將軟件構(gòu)件整合成完整系統(tǒng)所需要的設(shè)計(jì)窄驹、集成和測(cè)試又強(qiáng)加了 3 倍的工作量朝卒，這些高成本的構(gòu)件在根本上是相互獨(dú)立的。

1.2 編程行業(yè)“滿足我們內(nèi)心深處的創(chuàng)造渴望和愉悅所有人的共有情感”乐埠，提供了五種樂趣：

• 創(chuàng)建事物的快樂
• 開發(fā)對(duì)其他人有用的東西的樂趣
• 將可以活動(dòng)抗斤、相互嚙合的零部件組裝成類似迷宮的東西囚企，這個(gè)過程所體現(xiàn)出令人神魂顛倒的魅力
• 面對(duì)不重復(fù)的任務(wù)，不間斷學(xué)習(xí)的樂趣
• 工作在如此易于駕馭的介質(zhì)上的樂趣——純粹的思維活動(dòng)瑞眼，其存在龙宏、移動(dòng)和運(yùn)轉(zhuǎn)方式完全不同于實(shí)際物體

1.3 同樣，這個(gè)行業(yè)具有一些內(nèi)在固有的苦惱：

• 將做事方式調(diào)整到追求完美伤疙，是學(xué)習(xí)編程的最困難部分
• 由其他人來設(shè)定目標(biāo)银酗，并且必須依靠自己無法控制的事物（特別是程序）；權(quán)威不等同于責(zé)任
• 實(shí)際情況看起來要比這一點(diǎn)好一些：真正的權(quán)威來自于每次任務(wù)的完成
• 任何創(chuàng)造性活動(dòng)都伴隨著枯燥艱苦的勞動(dòng)徒像，編程也不例外
• 人們通常期望項(xiàng)目在接近結(jié)束時(shí)黍特，（bug、工作時(shí)間）能收斂得快一些厨姚，然而軟件項(xiàng)目的情況卻是越接近完成衅澈，收斂得越慢
• 產(chǎn)品在即將完成時(shí)總面臨著陳舊過時(shí)的威脅

第 2 章 人月神話

2.1 缺乏合理的時(shí)間進(jìn)度是造成項(xiàng)目滯后的最主要原因键菱，它比其他所有因素加起來影響還大谬墙。

2.2 良好的烹飪需要時(shí)間，某些任務(wù)無法在不損害結(jié)果的情況下加快速度经备。

2.3 所有的編程人員都是樂觀主義者：“一切都將運(yùn)作良好”拭抬。

2.4 由于編程人員通過純粹的思維活動(dòng)來開發(fā)，所以我們期待在實(shí)現(xiàn)過程中不會(huì)碰到困難侵蒙。

2.5 但是造虎，我們的構(gòu)思是有缺陷的，因此總會(huì)有 bug纷闺。

2.6 我們圍繞成本核算的估計(jì)技術(shù)算凿，混淆了工作量和項(xiàng)目進(jìn)展。人月是危險(xiǎn)和帶有欺騙性的神話犁功，因?yàn)樗凳救藛T數(shù)量和時(shí)間是可以相互替換的氓轰。

2.7 在若干人員中分解任務(wù)會(huì)引發(fā)額外的溝通工作量——培訓(xùn)和相互溝通。

2.8 關(guān)于進(jìn)度安排浸卦，我的經(jīng)驗(yàn)是為 1/3 計(jì)劃署鸡、1/6 編碼、1/4 構(gòu)件測(cè)試以及 1/4 系統(tǒng)測(cè)試限嫌。
2.9 作為一個(gè)學(xué)科靴庆，我們?nèi)狈?shù)據(jù)估計(jì)。

2.10 因?yàn)槲覀儗?duì)自己的估計(jì)技術(shù)不確定怒医，所以在管理和客戶的壓力下炉抒，我們常常缺乏堅(jiān)持的勇氣。

2.11 Brook 法則：向進(jìn)度落后的項(xiàng)目中增加人手稚叹，只會(huì)使進(jìn)度更加落后焰薄。

2.12 向軟件項(xiàng)目中增派人手從三個(gè)方面增加了項(xiàng)目必要的總體工作量：任務(wù)重新分配本身和所造成的工作中斷禽笑；培訓(xùn)新人員；額外的相互溝通蛤奥。

第 3 章 外科手術(shù)隊(duì)伍

3.1 同樣有兩年經(jīng)驗(yàn)而且在受到同樣的培訓(xùn)的情況下佳镜，優(yōu)秀的專業(yè)程序員的工作效率是較差程序員的十倍。（Sackman凡桥、Erikson 和 Grand）

3.2 Sackman央渣、Erikson 和 Grand 的數(shù)據(jù)顯示經(jīng)驗(yàn)和實(shí)際表現(xiàn)之間沒有相互聯(lián)系。我懷疑這種現(xiàn)象是否普遍成立癞谒。

3.3 小型梗搅、精干隊(duì)伍是最好的——盡可能的少。

3.4 兩個(gè)人的團(tuán)隊(duì)衰猛，其中一個(gè)項(xiàng)目經(jīng)理迟蜜，常常是最佳的人員使用方法。[留意一下上帝對(duì)婚姻的設(shè)計(jì)啡省。]

3.5 對(duì)于真正意義上的大型系統(tǒng)娜睛，小型精干的隊(duì)伍太慢了。

3.6 實(shí)際上卦睹，絕大多數(shù)大型編程系統(tǒng)的經(jīng)驗(yàn)顯示出畦戒，一擁而上的開發(fā)方法是高成本、速度緩慢结序、不充分的障斋，開發(fā)出的產(chǎn)品無法進(jìn)行概念上的集成。

3.7 一位首席程序員徐鹤、類似于外科手術(shù)隊(duì)伍的團(tuán)隊(duì)架構(gòu)提供了一種方法——既能獲得由少數(shù)頭腦產(chǎn)生的產(chǎn)品完整性垃环，又能得到多位協(xié)助人員的總體生產(chǎn)率，還徹底地減少了溝通的工作量返敬。

第 4 章 貴族專制遂庄、民主政治和系統(tǒng)設(shè)計(jì)

4.1 “概念完整性是系統(tǒng)設(shè)計(jì)中最重要的考慮因素”。

4.2 “功能與理解上的復(fù)雜程度的比值才是系統(tǒng)設(shè)計(jì)的最終測(cè)試標(biāo)準(zhǔn)”救赐，而不僅僅是豐富的功能涧团。[該比值是對(duì)易用性的一種測(cè)量，由簡單和復(fù)雜應(yīng)用共同驗(yàn)證经磅。]

4.3 為了獲得概念完整性泌绣，設(shè)計(jì)必須由一個(gè)人或者具有共識(shí)的小型團(tuán)隊(duì)來完成。

4.4 “對(duì)于非常大型的項(xiàng)目预厌，將設(shè)計(jì)方法阿迈、體系結(jié)構(gòu)方面的工作與具體實(shí)現(xiàn)相分離是獲得概念完整性的強(qiáng)有力方法≡矗”[同樣適用于小型項(xiàng)目苗沧。]

4.5 “如果要得到系統(tǒng)概念上的完整性刊棕，那么必須控制這些概念。這實(shí)際上是一種無需任何歉意的貴族專制統(tǒng)治待逞∩牵”

4.6 紀(jì)律、規(guī)則對(duì)行業(yè)是有益的识樱。外部的體系結(jié)構(gòu)規(guī)定實(shí)際上是增強(qiáng)嗤无，而不是限制實(shí)現(xiàn)小組的創(chuàng)造性。

4.7 概念上統(tǒng)一的系統(tǒng)能更快地開發(fā)和測(cè)試怜庸。

4.8 體系結(jié)構(gòu)（architecture）当犯、設(shè)計(jì)實(shí)現(xiàn)（implementation）、物理實(shí)現(xiàn)（realization）的許多工作可以并發(fā)進(jìn)行割疾。[軟件和硬件設(shè)計(jì)同樣可以并行嚎卫。]

第 5 章 畫蛇添足

5.1 盡早交流和持續(xù)溝通能使結(jié)構(gòu)師有較好的成本意識(shí)，以及使開發(fā)人員獲得對(duì)設(shè)計(jì)的信心宏榕，并且不會(huì)混淆各自的責(zé)任分工拓诸。

5.2 結(jié)構(gòu)師如何成功地影響實(shí)現(xiàn)：

• 牢記是開發(fā)人員承擔(dān)創(chuàng)造性的實(shí)現(xiàn)責(zé)任；結(jié)構(gòu)師只能提出建議担扑。

• 時(shí)刻準(zhǔn)備著為所指定的說明建議一種實(shí)現(xiàn)的方法恰响，準(zhǔn)備接受任何其他可行的方法。

• 對(duì)上述的建議保持低調(diào)和平靜涌献。

• 準(zhǔn)備對(duì)所建議的改進(jìn)放棄堅(jiān)持。

• 聽取開發(fā)人員在體系結(jié)構(gòu)上改進(jìn)的建議首有。

5.3 第二個(gè)系統(tǒng)是人們所設(shè)計(jì)的最危險(xiǎn)的系統(tǒng)燕垃，通常的傾向是過分地進(jìn)行設(shè)計(jì)。

5.4 OS/360 是典型的畫蛇添足（second-system effect）的例子井联。[Windows NT 似乎是90 年代的例子卜壕。]

5.5 為功能分配一個(gè)字節(jié)和微秒的優(yōu)先權(quán)值是一個(gè)很有價(jià)值的規(guī)范化方法。

第 6 章 貫徹執(zhí)行

6.1 即使是大型的設(shè)計(jì)團(tuán)隊(duì)烙常，設(shè)計(jì)結(jié)果也必須由一個(gè)或兩個(gè)人來完成轴捎，以確保這些決定是一致的。

6.2 必須明確定義體系結(jié)構(gòu)中與先前定義不同的地方蚕脏，重新定義的詳細(xì)程度應(yīng)該與原先的說明一致侦副。

6.3 出于精確性的考慮，我們需要形式化的設(shè)計(jì)定義驼鞭，同樣秦驯，我們需要記敘性定義來加深理解。

6.4 必須采用形式化定義和記敘性定義中的一種作為標(biāo)準(zhǔn)挣棕，另一種作為輔助措施译隘；它們都可以作為表達(dá)的標(biāo)準(zhǔn)亲桥。

6.5 設(shè)計(jì)實(shí)現(xiàn)，包括模擬仿真固耘，可以充當(dāng)一種形式化定義的方法题篷；這種方法有一些嚴(yán)重的缺點(diǎn)。

6.6 直接整合是一種強(qiáng)制推行軟件的結(jié)構(gòu)性標(biāo)準(zhǔn)的方法厅目。[硬件上也是如此——考慮內(nèi)建在 ROM 中的 Mac WIMP 接口悼凑。]

6.7 “如果起初至少有兩種以上的實(shí)現(xiàn)，那么（體系結(jié)構(gòu)）定義會(huì)更加整潔璧瞬，會(huì)更加規(guī)范户辫。”

6.8 允許體系結(jié)構(gòu)師對(duì)實(shí)現(xiàn)人員的詢問做出電話應(yīng)答解釋是非常重要的嗤锉，并且必須進(jìn)行日志記錄和整理發(fā)布渔欢。[電子郵件是一種可選的介質(zhì)。]

6.9 “項(xiàng)目經(jīng)理最好的朋友就是他每天要面對(duì)的敵人——獨(dú)立的產(chǎn)品測(cè)試機(jī)構(gòu)/小組瘟忱“露睿”

第 7 章 為什么巴比倫塔會(huì)失敗访诱？

7.1 巴比倫塔項(xiàng)目的失敗是因?yàn)槿狈涣鞯姘ぃ约敖涣鞯慕Y(jié)果——組織。

交流

7.2 “因?yàn)樽笫植恢烙沂衷谧鍪裁创ゲ耍瑥亩M(jìn)度災(zāi)難九榔、功能的不合理和系統(tǒng)缺陷紛紛出現(xiàn)∥邢啵”由于對(duì)其他人的各種假設(shè)哲泊，團(tuán)隊(duì)成員之間的理解開始出現(xiàn)偏差。

7.3 團(tuán)隊(duì)?wèi)?yīng)該以盡可能多的方式進(jìn)行相互之間的交流：非正式催蝗、常規(guī)項(xiàng)目會(huì)議切威，會(huì)上進(jìn)行簡要的技術(shù)陳述、共享的正式項(xiàng)目工作手冊(cè)丙号。[以及電子郵件先朦。]

項(xiàng)目工作手冊(cè)

7.4 項(xiàng)目工作手冊(cè)“不是獨(dú)立的一篇文檔，它是對(duì)項(xiàng)目必須產(chǎn)生的一系列文檔進(jìn)行組織的一種結(jié)構(gòu)犬缨≡海”

7.5 “項(xiàng)目所有的文檔都必須是該（工作手冊(cè)）結(jié)構(gòu)的一部分”槌撸”

7.6 需要盡早和仔細(xì)地設(shè)計(jì)工作手冊(cè)結(jié)構(gòu)截酷。

7.7 事先制訂了良好結(jié)構(gòu)的工作手冊(cè)“可以將后來書寫的文字放置在合適的章節(jié)中”，并且可以提高產(chǎn)品手冊(cè)的質(zhì)量。

7.8 “每一個(gè)團(tuán)隊(duì)成員應(yīng)該了解所有的材料（工作手冊(cè)）迂苛∪龋”[我想說的是，每個(gè)團(tuán)隊(duì)成員應(yīng)該能夠看到所有材料三幻，網(wǎng)頁即可滿足要求就漾。]

7.9 實(shí)時(shí)更新是至關(guān)重要的。

7.10 工作手冊(cè)的使用者應(yīng)該將注意力集中在上次閱讀后的變更念搬，以及關(guān)于這些變更重要性的評(píng)述抑堡。

7.11 OS/360 項(xiàng)目工作手冊(cè)開始采用的是紙介質(zhì)，后來換成了微縮膠片朗徊。

7.12 今天[即使在 1975 年]首妖，共享的電子手冊(cè)是能更好達(dá)到所有這些目標(biāo)、更加低廉爷恳、更加簡單的機(jī)制有缆。

7.13 仍然需要用變更條和修訂日期[或具備同等功能的方法]來標(biāo)記文字；仍然需要后進(jìn)先出（LIFO）的電子化變更小結(jié)温亲。

7.14 Parnas 強(qiáng)烈地認(rèn)為使每個(gè)人看到每件事的目標(biāo)是完全錯(cuò)誤的棚壁；各個(gè)部分應(yīng)該被封裝，從而沒有人需要或者允許看到其他部分的內(nèi)部結(jié)構(gòu)栈虚，只需要了解接口袖外。

7.15 Parnas 的建議的確是災(zāi)難的處方。[Parnas 讓我認(rèn)可了該觀點(diǎn)魂务，使我徹底地改變了想法曼验。]

組織架構(gòu)

7.16 團(tuán)隊(duì)組織的目標(biāo)是為了減少必要的交流和協(xié)作量。

7.17 為了減少交流头镊，組織結(jié)構(gòu)包括了人力劃分（division of labor）和限定職責(zé)范圍（specialization of function）蚣驼。

7.18 傳統(tǒng)的樹狀組織結(jié)構(gòu)反映了權(quán)力的結(jié)構(gòu)原理——不允許雙重領(lǐng)導(dǎo)。

7.19 組織中的交流是網(wǎng)狀相艇，而不是樹狀結(jié)構(gòu)，因而所有的特殊組織機(jī)制（往往體現(xiàn)成組織結(jié)構(gòu)圖中的虛線部分）都是為了進(jìn)行調(diào)整纯陨，以克服樹狀組織結(jié)構(gòu)中交流缺乏的困難坛芽。

7.20 每個(gè)子項(xiàng)目具有兩個(gè)領(lǐng)導(dǎo)角色——產(chǎn)品負(fù)責(zé)人、技術(shù)主管或結(jié)構(gòu)師翼抠。這兩個(gè)角色的職能有著很大的區(qū)別咙轩，需要不同的技能。

7.21 兩種角色中的任意組合可以是非常有效的：

• 產(chǎn)品負(fù)責(zé)人和技術(shù)主管是同一個(gè)人阴颖。

• 產(chǎn)品負(fù)責(zé)人作為總指揮活喊，技術(shù)主管充當(dāng)其左右手。

• 技術(shù)主管作為總指揮量愧，產(chǎn)品負(fù)責(zé)人充當(dāng)其左右手钾菊。

第 8 章 胸有成竹

8.1 僅僅通過對(duì)編碼部分的估計(jì)帅矗，然后乘以任務(wù)其他部分的相對(duì)系數(shù)，是無法得出對(duì)整項(xiàng)工作的精確估計(jì)的煞烫。

8.2 構(gòu)建獨(dú)立小型程序的數(shù)據(jù)不適用于編程系統(tǒng)項(xiàng)目浑此。

8.3 程序開發(fā)呈程序規(guī)模的指數(shù)增長。

8.4 一些發(fā)表的研究報(bào)告顯示指數(shù)約為 1.5滞详。[Boehm 的數(shù)據(jù)并不完全一致凛俱，在 1.05 和1.2 之間變化。]

8.5 Portman 的 ICL 數(shù)據(jù)顯示相對(duì)于其他活動(dòng)開銷料饥，全職程序員僅將 50％的時(shí)間用于編程和調(diào)試蒲犬。

8.6 IBM 的 Aron 數(shù)據(jù)顯示，生產(chǎn)率是系統(tǒng)各個(gè)部分交互的函數(shù)岸啡，在 1.5K 千代碼行/人年至 10K 千代碼行/人年的范圍內(nèi)變化原叮。

8.7 Harr 的 Bell 實(shí)驗(yàn)室數(shù)據(jù)顯示對(duì)于已完成的產(chǎn)品，操作系統(tǒng)類的生產(chǎn)率大約是0.6KLOC/人年凰狞，編譯類工作的生產(chǎn)率大約為 2.2KLOC/人年篇裁。

8.8 Brooks 的 OS/360S 數(shù)據(jù)與 Harr 的數(shù)據(jù)一致：操作系統(tǒng) 0.6～0.8KLOC/人年，編譯器 2～3 KLOC/人年赡若。

8.9 Corbato 的 MIT 項(xiàng)目 MULTICS 數(shù)據(jù)顯示达布，在操作系統(tǒng)和編譯器混合類型上的生產(chǎn)率 是 1.2KLOC/人年，但這些是 PL/I 的代碼行逾冬，而其他所有的數(shù)據(jù)是匯編代碼行黍聂。

8.10 在基本語句級(jí)別，生產(chǎn)率看上去是個(gè)常數(shù)身腻。

8.11 當(dāng)使用適當(dāng)?shù)母呒?jí)語言時(shí)产还，程序編制的生產(chǎn)率可以提高 5 倍。

第 9 章 削足適履

9.1 除了運(yùn)行時(shí)間以外嘀趟，所占據(jù)的內(nèi)存空間也是主要開銷脐区。特別是對(duì)于操作系統(tǒng)，它的很多程序是永久駐留在內(nèi)存中她按。

9.2 即便如此牛隅，花費(fèi)在駐留程序所占據(jù)內(nèi)存上的金錢仍是物有所值的，比其他任何在配置上投資的效果要好酌泰。規(guī)模本身不是壞事媒佣，但不必要的規(guī)模是不可取的。

9.3 軟件開發(fā)人員必須設(shè)立規(guī)模目標(biāo)陵刹，控制規(guī)模默伍，發(fā)明一些減少規(guī)模的方法——就如同硬件開發(fā)人員為減少元器件所做的一樣。

9.4 規(guī)模預(yù)算不僅僅在占據(jù)內(nèi)存方面是明確的，同時(shí)還應(yīng)該指明程序?qū)Υ疟P的訪問次數(shù)也糊。

9.5 規(guī)模預(yù)算必須與分配的功能相關(guān)聯(lián)炼蹦；在指明模塊大小的同時(shí)，確切定義模塊的功能显设。

9.6 在大型的團(tuán)隊(duì)中框弛，各個(gè)小組傾向于不斷地局部優(yōu)化，以滿足自己的目標(biāo)捕捂，而較少考慮隊(duì)用戶的整體影響瑟枫。這種方向性的問題是大型項(xiàng)目的主要危險(xiǎn)。

9.7 在整個(gè)實(shí)現(xiàn)的過程期間指攒，系統(tǒng)結(jié)構(gòu)師必須保持持續(xù)的警覺慷妙，確保連貫的系統(tǒng)完整性。

9.8 培養(yǎng)開發(fā)人員從系統(tǒng)整體出發(fā)允悦、面向用戶的態(tài)度是軟件編程管理人員最重要的職能膝擂。

9.9 在早期應(yīng)該制訂策略，以決定用戶可選項(xiàng)目的粗細(xì)程度隙弛，因?yàn)閷⑺鼈冏鳛檎w大包能夠節(jié)省內(nèi)存空間架馋。[常常還可以節(jié)約市場(chǎng)成本。]

9.10 臨時(shí)空間的尺寸全闷，以及每次磁盤訪問的程序數(shù)量是很關(guān)鍵的決策叉寂，因?yàn)樾阅苁且?guī)模的非線性函數(shù)。[這個(gè)整體決策已顯得過時(shí)——起初是由于虛擬內(nèi)存总珠，后來則是成本低廉的內(nèi)存∑流ⅲ現(xiàn)在的用戶通常會(huì)購買能容納主要應(yīng)用程序所有代碼的內(nèi)存。]

9.11 為了取得良好的空間－時(shí)間折衷局服，開發(fā)隊(duì)伍需要得到特定與某種語言或者機(jī)型的編程技能培訓(xùn)钓瞭，特別是在使用新語言或者新機(jī)器時(shí)。

9.12 編程需要技術(shù)積累淫奔，每個(gè)項(xiàng)目需要自己的標(biāo)準(zhǔn)組件庫山涡。

9.13 庫中的每個(gè)組件需要有兩個(gè)版本，運(yùn)行速度較快和短小精煉的唆迁。[現(xiàn)在看來有些過時(shí)佳鳖。]

9.14 精煉、充分和快速的程序媒惕。往往是戰(zhàn)略性突破的結(jié)果，而不僅僅技巧上的提高来庭。

9.15 這種突破常常是一種新型算法妒蔚。

9.16 更普遍的是，戰(zhàn)略上突破常來自于數(shù)據(jù)或表的重新表達(dá)。數(shù)據(jù)的表現(xiàn)形式是編程的根本肴盏。

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

10.1 “前提：在一片文件的汪洋中科盛，少數(shù)文檔形成了關(guān)鍵的樞紐，每個(gè)項(xiàng)目管理的工作都圍繞著它們運(yùn)轉(zhuǎn)菜皂。它們是經(jīng)理們的主要個(gè)人工具贞绵。”

10.2 對(duì)于計(jì)算機(jī)硬件開發(fā)項(xiàng)目恍飘，關(guān)鍵文檔是目標(biāo)榨崩、手冊(cè)、進(jìn)度章母、預(yù)算母蛛、組織機(jī)構(gòu)圖、空間分配乳怎、以及機(jī)器本身的報(bào)價(jià)彩郊、預(yù)測(cè)和價(jià)格。

10.3 對(duì)于大學(xué)科系蚪缀，關(guān)鍵文檔類似：目標(biāo)秫逝、課程描述、學(xué)位要求询枚、研究報(bào)告违帆、課程表和課程的安排、預(yù)算哩盲、教室分配前方、教師和研究生助手的分配。

10.4 對(duì)于軟件項(xiàng)目廉油，要求是相同的：目標(biāo)惠险、用戶手冊(cè)、內(nèi)部文檔抒线、進(jìn)度班巩、預(yù)算、組織機(jī)構(gòu)圖和工作空間分配嘶炭。

10.5 因此抱慌，即使是小型項(xiàng)目，項(xiàng)目經(jīng)理也應(yīng)該在項(xiàng)目早期規(guī)范化上述的一系列文檔眨猎。

10.6 以上集合中每一個(gè)文檔的準(zhǔn)備工作都將注意力集中在對(duì)討論的思索和提煉抑进，而書寫這項(xiàng)活動(dòng)需要上百次的細(xì)小決定，正是由于它們的存在睡陪，人們才能從令人迷惑的現(xiàn)象中得到清晰寺渗、確定的策略匿情。

10.7 對(duì)每個(gè)關(guān)鍵文檔的維護(hù)提供了狀態(tài)監(jiān)督和預(yù)警機(jī)制。

10.8 每個(gè)文檔本身就可以作為檢查列表或者數(shù)據(jù)庫信殊。

10.9 項(xiàng)目經(jīng)理的基本職責(zé)是使每個(gè)人都向著相同的方向前進(jìn)炬称。

10.10 項(xiàng)目經(jīng)理的主要日常工作是溝通，而不是做出決定涡拘；文檔使各項(xiàng)計(jì)劃和決策在整個(gè)團(tuán)隊(duì)范圍內(nèi)得到交流玲躯。

10.11 只有一小部分管理人員的時(shí)間——可能只有 20%——用來從自己頭腦外部獲取信息。

10.12 出于這個(gè)原因鳄乏，廣受吹捧的市場(chǎng)概念——支持管理人員的“完備信息管理系統(tǒng)”并不基于反映管理人員行為的有效模型跷车。

第 11 章 未雨綢繆

11.1 化學(xué)工程師已經(jīng)認(rèn)識(shí)到無法一步將實(shí)驗(yàn)室工作臺(tái)上的反應(yīng)過程移到工廠中，需要一個(gè)實(shí)驗(yàn)性工廠（pilot planet）來為提高產(chǎn)量和在缺乏保護(hù)的環(huán)境下運(yùn)作提供寶貴經(jīng)驗(yàn)汞窗。

11.2 對(duì)于編程產(chǎn)品而言姓赤，這樣的中間步驟是同樣必要的，但是軟件工程師在著手發(fā)布產(chǎn)品之前仲吏，卻并不會(huì)常規(guī)地進(jìn)行試驗(yàn)性系統(tǒng)的現(xiàn)場(chǎng)測(cè)試不铆。[現(xiàn)在，這已經(jīng)成為了一項(xiàng)普遍的實(shí)踐裹唆，beta 版本誓斥。它不同于有限功能的原型，alpha 版本许帐，后者同樣是我所倡導(dǎo)的實(shí)踐劳坑。]

11.3 對(duì)于大多數(shù)項(xiàng)目，第一個(gè)開發(fā)的系統(tǒng)并不合用成畦。它可能太慢距芬、太大，而且難以使用循帐，或者三者兼而有之框仔。

11.4 系統(tǒng)的丟棄和重新設(shè)計(jì)可以一步完成，也可以一塊塊地實(shí)現(xiàn)拄养。這是個(gè)必須完成的步驟离斩。

11.5 將開發(fā)的第一個(gè)系統(tǒng)——丟棄原型——發(fā)布給用戶，可以獲得時(shí)間瘪匿，但是它的代價(jià)高昂——對(duì)于用戶跛梗，使用極度痛苦；對(duì)于重新開發(fā)的人員棋弥，分散了精力核偿；對(duì)于產(chǎn)品，影響了聲譽(yù)顽染，即使最好的再設(shè)計(jì)也難以挽回名聲宪祥。

11.6 因此聂薪，為舍棄而計(jì)劃，無論如何蝗羊，你一定要這樣做。

11.7 “開發(fā)人員交付的是用戶滿意程度仁锯，而不僅僅是實(shí)際的產(chǎn)品耀找。”（Cosgrove）

11.8 用戶的實(shí)際需要和用戶感覺會(huì)隨著程序的構(gòu)建业崖、測(cè)試和使用而變化野芒。

11.9 軟件產(chǎn)品易于掌握的特性和不可見性，導(dǎo)致了它的構(gòu)建人員（特別容易）面臨著永恒的需求變更双炕。

11.10 目標(biāo)上（和開發(fā)策略上）的一些正常變化無可避免狞悲，事先為它們做準(zhǔn)備總比假設(shè)它們不會(huì)出現(xiàn)要好得多。

11.11 為變更計(jì)劃軟件產(chǎn)品的技術(shù)妇斤，特別是細(xì)致的模塊接口文檔——非常地廣為人知摇锋，但并沒有相同規(guī)模的實(shí)踐。盡可能地使用表驅(qū)動(dòng)技術(shù)同樣是有所幫助的站超。[現(xiàn)在內(nèi)存的成本和規(guī)模使這項(xiàng)技術(shù)越來越出眾荸恕。]

11.12 高級(jí)語言的使用、編譯時(shí)操作死相、通過引用的聲明整合和自文檔技術(shù)能減少變更引起的錯(cuò)誤融求。

11.13 采用定義良好的數(shù)字化版本將變更量子（階段）化。[當(dāng)今的標(biāo)準(zhǔn)實(shí)踐算撮。]為變更計(jì)劃組織架構(gòu)

11.14 程序員不愿意為設(shè)計(jì)書寫文檔的原因生宛，不僅僅是由于惰性。更多的是源于設(shè)計(jì)人員的躊躇——要為自己嘗試性的設(shè)計(jì)決策進(jìn)行辯解肮柜。（Cosgrove）

11.15 為變更組建團(tuán)隊(duì)比為變更進(jìn)行設(shè)計(jì)更加困難陷舅。

11.16 只要管理人員和技術(shù)人才的天賦允許，老板必須對(duì)他們的能力培養(yǎng)給予極大的關(guān)注素挽，使管理人員和技術(shù)人才具有互換性蔑赘；特別是希望能在技術(shù)和管理角色之間自由地分配人手的時(shí)候。

11.17 具有兩條晉升線的高效組織機(jī)構(gòu)预明，存在著一些社會(huì)性的障礙缩赛，人們必須警惕和積極地同它做持續(xù)的斗爭。

11.18 很容易為不同的晉升線建立相互一致的薪水級(jí)別撰糠，但要同等威信的建立需要一些強(qiáng)烈的心理措施：相同的辦公室酥馍、一樣的支持和技術(shù)調(diào)動(dòng)的優(yōu)先補(bǔ)償。

11.19 組建外科手術(shù)隊(duì)伍式的軟件開發(fā)團(tuán)隊(duì)是對(duì)上述問題所有方面的徹底沖擊阅酪。對(duì)于靈活組織架構(gòu)問題旨袒，這的確是一個(gè)長期行之有效的解決方案汁针。

前進(jìn)兩步，后退一步——程序維護(hù)

11.20 程序維護(hù)基本上不同于硬件的維護(hù)砚尽；它主要由各種變更組成施无，如修復(fù)設(shè)計(jì)缺陷、新增功能必孤、或者是使用環(huán)境或者配置變換引起的調(diào)整猾骡。

11.21 對(duì)于一個(gè)廣泛使用的程序，其維護(hù)總成本通常是開發(fā)成本的 40％或更多敷搪。

11.22 維護(hù)成本受用戶數(shù)目的嚴(yán)重影響兴想。用戶越多，所發(fā)現(xiàn)的錯(cuò)誤也越多赡勘。

11.23 Campbell 指出了一個(gè)顯示產(chǎn)品生命期中每月 bug 數(shù)的有趣曲線嫂便，它先是下降，然后攀升闸与。

11.24 缺陷修復(fù)總會(huì)以（20－50）%的機(jī)率引入新的 bug毙替。

11.25 在每次修復(fù)之后，必須重新運(yùn)行先前所有的測(cè)試用例几迄，從而確保系統(tǒng)不會(huì)以更隱蔽的方式被破壞蔚龙。

11.26 能消除、至少是能指明副作用的程序設(shè)計(jì)方法映胁，對(duì)維護(hù)成本有很大的影響木羹。

11.27 同樣，設(shè)計(jì)實(shí)現(xiàn)的人員越少解孙、接口越少坑填，產(chǎn)生的錯(cuò)誤也就越少。

前進(jìn)一步弛姜，后退一步——系統(tǒng)熵隨時(shí)間增加

11.28 Lehman 和 Belady 發(fā)現(xiàn)模塊數(shù)量隨大型操作系統(tǒng)（OS/360）版本號(hào)的增加呈線性增長脐瑰，但是受到影響的模塊以版本號(hào)指數(shù)的級(jí)別增長。

11.29 所有修改都傾向于破壞系統(tǒng)的架構(gòu)廷臼，增加了系統(tǒng)的混亂程度苍在。即使是最熟練的軟件維護(hù)工作，也只是放緩了系統(tǒng)退化到不可修復(fù)混亂的進(jìn)程荠商，從中必須要重新進(jìn)行設(shè)計(jì)寂恬。[許多程序升級(jí)的真正需要，如性能等莱没，尤其會(huì)沖擊它的內(nèi)部結(jié)構(gòu)邊界初肉。原有邊界引發(fā)的不足常常在日后才會(huì)出現(xiàn)。]

第 12 章 干將莫邪

12.1 項(xiàng)目經(jīng)理應(yīng)該制訂一套策略饰躲，以及為通用工具的開發(fā)分配資源牙咏，與此同時(shí)臼隔，他還必須意識(shí)到專業(yè)工具的需求。

12.2 開發(fā)操作系統(tǒng)的隊(duì)伍需要自己的目標(biāo)機(jī)器妄壶，進(jìn)行調(diào)試開發(fā)工作摔握。相對(duì)于最快的速度而言，它更需要最大限度的內(nèi)存盯拱，還需要安排一名系統(tǒng)程序員盒发，以保證機(jī)器上的標(biāo)準(zhǔn)軟件是即時(shí)更新和實(shí)時(shí)可用的。

12.3 同時(shí)還需要配備調(diào)試機(jī)器或者軟件狡逢，以便在調(diào)試過程中，所有類型的程序參數(shù)可以被自動(dòng)計(jì)數(shù)和測(cè)量拼卵。

12.4 目標(biāo)機(jī)器的使用需求量是一種特殊曲線：剛開始使用率非常低奢浑，突然出現(xiàn)爆發(fā)性的增長，接著趨于平緩腋腮。

12.5 同天文工作者一樣雀彼，系統(tǒng)調(diào)試總是大部分在夜間完成。

12.6 拋開理論不談即寡，一次分配給某個(gè)小組連續(xù)的目標(biāo)時(shí)間塊被證明是最好的安排方法徊哑，比不同小組的穿插使用更為有效。

12.7 盡管技術(shù)不斷變化聪富，這種采用時(shí)間塊來安排匱乏計(jì)算機(jī)資源的方式仍得以延續(xù)20 年[在 1975 年]莺丑，是因?yàn)樗纳a(chǎn)率最高。[在 1995 年依然如此]

12.8 如果目標(biāo)機(jī)器是新產(chǎn)品墩蔓，則需要一個(gè)目標(biāo)機(jī)器的邏輯仿真裝置梢莽。這樣，可以更 快地得到輔助調(diào)試平臺(tái)奸披。即使在真正機(jī)器出現(xiàn)之后昏名，仿真裝置仍可提供可靠的調(diào)試平臺(tái)。

12.9 主程序庫應(yīng)該被劃分成（1）一系列獨(dú)立的私有開發(fā)庫阵面；（2）正處在系統(tǒng)測(cè)試下的系統(tǒng)集成子庫轻局；（3）發(fā)布版本。正式的分離和進(jìn)度提供了控制样刷。

12.10 在編制程序的項(xiàng)目中仑扑，節(jié)省最大工作量的工具可能是文本編輯系統(tǒng)。

12.11 系統(tǒng)文檔中的巨大容量帶來了新的不理解問題[例如颂斜，看看 Unix]夫壁，但是它比大多數(shù)未能詳細(xì)描述編程系統(tǒng)特性的短小文章更加可取。

12.12 自頂向下沃疮、徹底地開發(fā)一個(gè)性能仿真裝置盒让。盡可能早地開始這項(xiàng)工作梅肤，仔細(xì)地聽取 “它們表達(dá)的意見”。

高級(jí)語言

12.13 只有懶散和惰性會(huì)妨礙高級(jí)語言和交互式編程的廣泛應(yīng)用邑茄。[如今它們已經(jīng)在全世界使用姨蝴。]

12.14 高級(jí)語言不僅僅提升了生產(chǎn)率，而且還改進(jìn)了調(diào)試：bug 更少肺缕，以及更容易尋找左医。

12.15 傳統(tǒng)的反對(duì)意見——功能、目標(biāo)代碼的尺寸同木、目標(biāo)代碼的速度浮梢，隨著語言和編譯器技術(shù)的進(jìn)步已不再成為問題。

12.16 現(xiàn)在可供合理選擇的語言是 PL/I彤路。[不再正確秕硝。]

交互式編程

12.17 某些應(yīng)用上，批處理系統(tǒng)決不會(huì)被交互式系統(tǒng)所替代洲尊。[依然成立远豺。]

12.18 調(diào)試是系統(tǒng)編程中很慢和較困難的部分，而漫長的調(diào)試周轉(zhuǎn)時(shí)間是調(diào)試的禍根坞嘀。

12.19 有限的數(shù)據(jù)表明了系統(tǒng)軟件開發(fā)中躯护，交互式編程的生產(chǎn)率至少是原來的兩倍。

第 13 章 整體部分

13.1 第 4丽涩、5棺滞、6 章所意味的煞費(fèi)苦心、詳盡體系結(jié)構(gòu)工作不但使產(chǎn)品更加易于使用内狸，而且使開發(fā)更容易進(jìn)行以及 bug 更不容易產(chǎn)生检眯。

13.2 V.A.Vyssotsky 提出，“許許多多的失敗完全源于那些產(chǎn)品未精確定義的地方昆淡∶倘常”

13.3 在編寫任何代碼之前，規(guī)格說明必須提交給測(cè)試小組昂灵，以詳細(xì)地檢查說明的完整性和明確性避凝。開發(fā)人員自己不會(huì)完成這項(xiàng)工作。（Vyssotsky）

13.4 “十年內(nèi)[1965～1975]眨补，Wirth 的自頂向下進(jìn)行設(shè)計(jì)[逐步細(xì)化]將會(huì)是最重要的新型形式化軟件開發(fā)方法管削。”

13.5 Wirth 主張?jiān)诿總€(gè)步驟中撑螺，盡可能使用級(jí)別較高的表達(dá)方法含思。

13.6 好的自頂向下設(shè)計(jì)從四個(gè)方面避免了 bug。

13.7 有時(shí)必須回退，推翻頂層設(shè)計(jì)含潘，重新開始饲做。

13.8 結(jié)構(gòu)化編程中，程序的控制結(jié)構(gòu)僅由支配代碼塊（相對(duì)于任意的跳轉(zhuǎn)）的給定集合所組成遏弱。這種方法出色地避免了 bug盆均，是一種正確的思考方式。

13.9 Gold 結(jié)果顯示了漱逸，在交互式調(diào)試過程中泪姨，第一次交互取得的工作進(jìn)展是后續(xù)交互的三倍。這實(shí)際上獲益于在調(diào)試開始之前仔細(xì)地調(diào)試計(jì)劃饰抒。[我認(rèn)為在 1995 年依然如此肮砾。]

13.10 我發(fā)現(xiàn)對(duì)良好終端系統(tǒng)的正確使用，往往要求每兩小時(shí)的終端會(huì)話對(duì)應(yīng)于兩小時(shí)的桌面工作：1 小時(shí)會(huì)話后的清理和文檔工作袋坑；1 小時(shí)為下一次計(jì)劃變更和測(cè)試唇敞。

13.11 系統(tǒng)調(diào)試（相對(duì)于單元測(cè)試）花費(fèi)的時(shí)間會(huì)比預(yù)料的更長。

13.12 系統(tǒng)調(diào)試的困難程度證明了需要一種完備系統(tǒng)化和可計(jì)劃的方法咒彤。

13.13 系統(tǒng)調(diào)試僅僅應(yīng)該在所有部件能夠運(yùn)作之后開始。（這既不同于為了查出接口bug 所采取 “合在一起嘗試” 的方法咒精；也不同于在所有構(gòu)件單元的 bug 已知镶柱，但未修復(fù)的情況下，即開始系統(tǒng)調(diào)試的做法模叙。）[對(duì)于多個(gè)團(tuán)隊(duì)尤其如此歇拆。]

13.14 開發(fā)大量的輔助調(diào)試平臺(tái)（scaffolding 腳手架）和測(cè)試代碼是很值得的，代碼量甚至可能會(huì)有測(cè)試對(duì)象的一半范咨。

13.15 必須有人對(duì)變更進(jìn)行控制和文檔化故觅，團(tuán)隊(duì)成員應(yīng)使用開發(fā)庫的各種受控拷貝來工作。

13.16 系統(tǒng)測(cè)試期間渠啊，一次只添加一個(gè)構(gòu)件输吏。

13.17 Lehman 和 Belady 出示了證據(jù)，變更的階段（量子）要么很大替蛉，間隔很寬贯溅；要么小和頻繁。后者很容易變得不穩(wěn)定躲查。[Microsoft 的一個(gè)團(tuán)隊(duì)使用了非常小的階段（量子）它浅。結(jié)果是每天晚上需要重新編譯生成增長中的系統(tǒng)。]

第 14 章 禍起蕭墻

14.1 “項(xiàng)目是怎樣延遲了整整一年的時(shí)間镣煮？…一次一天姐霍。”

14.2 一天一天的進(jìn)度落后比起重大災(zāi)難，更難以識(shí)別镊折、更不容易防范和更加難以彌補(bǔ)胯府。

14.3 根據(jù)一個(gè)嚴(yán)格的進(jìn)度表來控制項(xiàng)目的第一個(gè)步驟是制訂進(jìn)度表，進(jìn)度表由里程碑和日期組成腌乡。

14.4 里程碑必須是具體的盟劫、特定的、可度量的事件与纽，能進(jìn)行清晰能定義侣签。

14.5 如果里程碑定義得非常明確，以致于無法自欺欺人時(shí)急迂，程序員很少會(huì)就里程碑的進(jìn)展弄虛作假影所。

14.6 對(duì)于大型開發(fā)項(xiàng)目中的估計(jì)行為，政府的承包商所做的研究顯示：每兩周進(jìn)行仔細(xì)修訂的活動(dòng)時(shí)間估計(jì)僚碎，隨著開始時(shí)間的臨近不會(huì)有太大的變化猴娩；期間內(nèi)對(duì)時(shí)間長短的過 高估計(jì)，會(huì)隨著活動(dòng)的進(jìn)行持續(xù)下降勺阐；過低估計(jì)直到計(jì)劃的結(jié)束日期之前大約三周左右卷中，才有所變化抡草。

14.7 慢性進(jìn)度偏離是士氣殺手溺拱。[Microsoft 的 Jim McCarthy 說：“如果你錯(cuò)過了一個(gè)最終期限（deadline）壶辜，確保制訂下一條 deadline疙渣。2”]

14.8 進(jìn)取對(duì)于杰出的軟件開發(fā)團(tuán)隊(duì)赴魁，同優(yōu)秀的棒球隊(duì)伍一樣崖媚，是不可缺少的必要品德宗弯。

14.9 不存在關(guān)鍵路徑進(jìn)度的替代品撰茎，使人們能夠辨別計(jì)劃偏移的情況愤估。

14.10 PERT 的準(zhǔn)備工作是 PERT 圖使用中最有價(jià)值的部分帮辟。它包括了整個(gè)網(wǎng)狀結(jié)構(gòu)的展開、任務(wù)之間依賴關(guān)系的識(shí)別玩焰、各個(gè)任務(wù)鏈的估計(jì)由驹。這些都要求在項(xiàng)目早期進(jìn)行非常專業(yè)的計(jì)劃。

14.11 第一份 PERT 圖總是很恐怖的震捣，不過人們總是不斷進(jìn)行努力荔棉，運(yùn)用才智制訂下一份 PERT 圖。

14.12 PERT 圖為前面那個(gè)泄氣的借口蒿赢，“其他的部分反正會(huì)落后”润樱，提供了答案。

14.13 每個(gè)老板同時(shí)需要采取行動(dòng)的異常信息以及用來進(jìn)行分析和早期預(yù)警的狀態(tài)數(shù)據(jù)羡棵。

14.14 狀態(tài)的獲取是困難的壹若，因?yàn)橄聦俳?jīng)理有充分的理由不提供信息共享。

14.15 老板的不良反應(yīng)肯定會(huì)對(duì)信息的完全公開造成壓制；相反店展，仔細(xì)區(qū)分狀態(tài)報(bào)告养篓、毫無驚慌地接收?qǐng)?bào)告、決不越俎代庖赂蕴，將能鼓勵(lì)誠實(shí)的匯報(bào)柳弄。

14.16 必須有評(píng)審的機(jī)制，從而所有成員可以通過它了解真正的狀態(tài)概说。出于這個(gè)目的碧注，里程碑的計(jì)劃和完成文檔是關(guān)鍵。

14.17 Vyssotsky：我發(fā)現(xiàn)在里程碑報(bào)告中很容易記錄“計(jì)劃（老板的日期）”和“估計(jì)（最基層經(jīng)理的日期）”的日期糖赔。項(xiàng)目經(jīng)理必須停止對(duì)這些日期的懷疑萍丐。”

14.18 對(duì)于大型項(xiàng)目放典，一個(gè)對(duì)里程碑報(bào)告進(jìn)行維護(hù)的計(jì)劃和控制（Plan and Control）小組是非呈疟洌可貴的。

第 15 章 另外一面

15.1 對(duì)于軟件編程產(chǎn)品來說奋构，程序向用戶所呈現(xiàn)的面貌與提供給機(jī)器識(shí)別的內(nèi)容同樣重要壳影。

15.2 即使對(duì)于完全開發(fā)給自己使用的程序，描述性文字也是必須的弥臼，因?yàn)樗鼈儠?huì)被用戶－作者所遺忘态贤。

15.3 培訓(xùn)和管理人員基本上沒有能向編程人員成功地灌輸對(duì)待文檔的積極態(tài)度 —— 文檔能在整個(gè)生命周期對(duì)克服懶惰和進(jìn)度的壓力起促進(jìn)激勵(lì)作用。

15.4 這樣的失敗并不都是因?yàn)槿狈崆榛蛘哒f服力醋火，而是沒能正確地展示如何有效和經(jīng)濟(jì)地編制文檔。

15.5 大多數(shù)文檔只提供了很少的總結(jié)性內(nèi)容箱吕。必須放慢腳步芥驳，穩(wěn)妥地進(jìn)行。

15.6 由于關(guān)鍵的用戶文檔包含了跟軟件相關(guān)的基本決策茬高，所以它的絕大部分需要在程序編制之前書寫兆旬，它包括了 9 項(xiàng)內(nèi)容（參見相應(yīng)章節(jié)）。

15.7 每一份發(fā)布的程序拷貝應(yīng)該包括一些測(cè)試用例怎栽，其中一部分用于校驗(yàn)輸入數(shù)據(jù)丽猬，一部分用于邊界輸入數(shù)據(jù)，另一部分用于無效的輸入數(shù)據(jù)熏瞄。

15.8 對(duì)于必須修改程序的人而言脚祟，他們所需要程序內(nèi)部結(jié)構(gòu)文檔，同樣要求一份清晰明了的概述强饮，它包括了 5 項(xiàng)內(nèi)容（參見相應(yīng)章節(jié)）由桌。

15.9 流程圖是被吹捧得最過分的一種程序文檔。詳細(xì)逐一記錄的流程圖是一件令人生厭的事情，而且高級(jí)語言的出現(xiàn)使它顯得陳舊過時(shí)行您。（流程圖是圖形化的高級(jí)語言铭乾。）

15.10 如果這樣，很少有程序需要一頁紙以上的流程圖娃循。[在這一點(diǎn)上炕檩，MILSPEC 軍用標(biāo)準(zhǔn)實(shí)在錯(cuò)得很厲害。]

15.11 即使的確需要一張程序結(jié)構(gòu)圖捌斧，也并不需要遵照 ANSI 的流程圖標(biāo)準(zhǔn)笛质。

15.12 為了使文檔易于維護(hù)，將它們合并至源程序是至關(guān)重要的骤星，而不是作為獨(dú)立文檔進(jìn)行保存经瓷。

15.13 最小化文檔負(fù)擔(dān)的 3 個(gè)關(guān)鍵思路：

• 借助那些必須存在的語句，如名稱和聲明等洞难，來附加盡可能多的“文檔”信息舆吮。

• 使用空格和格式來表現(xiàn)從屬和嵌套關(guān)系，提高程序的可讀性队贱。

• 以段落注釋色冀，特別是模塊標(biāo)題的形式，向程序中插入必要的記敘性文字柱嫌。

15.14 程序修改人員所使用的文檔中锋恬，除了描述事情如何以外，還應(yīng)闡述它為什么那樣编丘。對(duì)于加深理解与学，目的是非常關(guān)鍵的，但即使是高級(jí)語言的語法嘉抓，也不能表達(dá)目的索守。

15.15 在線系統(tǒng)的高級(jí)語言（應(yīng)該使用的工具）中，自文檔化技術(shù)發(fā)現(xiàn)了它的絕佳應(yīng)用和強(qiáng)大功能抑片。

原著結(jié)束語

E.1 軟件系統(tǒng)可能是人類創(chuàng)造中最錯(cuò)綜復(fù)雜的事物（從不同類型組成部分?jǐn)?shù)量的角度出發(fā)）卵佛。

E.2 軟件工程的焦油坑在將來很長一段時(shí)間內(nèi)會(huì)繼續(xù)地使人們舉步維艱，無法自拔敞斋。