人月神話

焦油坑

1. 編程系統(tǒng)產(chǎn)品開發(fā)的工作量是供個人使用的，獨立開發(fā)的構(gòu)件程序的9倍样漆。我估計軟件構(gòu)件產(chǎn)品化引起了3倍工作量抓韩，將軟件構(gòu)件整合成完成系統(tǒng)所需要的設(shè)計，集成和測試又強(qiáng)加了3倍工作量领跛，這些高成本的構(gòu)件在根本上是互相獨立的。
2. 編程行業(yè)“滿足我們內(nèi)心深處的創(chuàng)造渴望和愉悅所有人的共有情感”撤奸，其提供了五種樂趣：

• 創(chuàng)建事物的快樂
• 開發(fā)對其他人有用的東西的樂趣
• 將可以活動吠昭，相互嚙合的零部件組裝成類似迷宮的東西，這個過程所體現(xiàn)出令人神魂顛倒的魅力胧瓜。
• 面對不重復(fù)的任務(wù)矢棚，不斷學(xué)習(xí)的樂趣。
• 純粹的思維活動府喳。

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

• 將做事方式調(diào)正到追求完美是學(xué)習(xí)編程的最困難的部分。
• 由其他人設(shè)定目標(biāo)，并且必須依靠自己無法控制的事物兜粘，權(quán)威不等同于責(zé)任
• 任何創(chuàng)造性活動都伴隨著枯燥艱苦的勞動申窘，編程也不例外
• 人們通常期望項目在接近結(jié)束時，軟件項目能收斂得快一些孔轴，然后剃法，情況卻是越接近完成，收斂得越慢距糖。
• 產(chǎn)品在完成前總面臨著陳舊過時的威脅玄窝；只有實際需要時，才會用到最新的設(shè)想悍引。

人月神話

1. 缺乏合理的時間進(jìn)度是造成項目滯后的主要原因，它比其他所有因素的總和影響還大帽氓。
2. 所有的編程人員都是樂觀主義者“一切都將運作良好”
3. 由于編程人員通過純粹的思維活動來開發(fā)趣斤，我們期待在實現(xiàn)過程中不會碰到困難。
4. 但是黎休，我們的構(gòu)思本身是有缺陷的浓领，因此總會有bug。
5. 圍繞著成本合算的估計技術(shù)势腮，混淆了工作量和項目進(jìn)度联贩。人月是危險和帶有欺騙性的神話，因為它暗示了人員數(shù)量和時間可以互相替換的捎拯。
6. 在若干人員中分解任務(wù)會引發(fā)額外的溝通工作量-培訓(xùn)和相互溝通泪幌。
7. 關(guān)于進(jìn)度安排，我的經(jīng)驗是1/3計劃署照，1/6編碼祸泪，1/4構(gòu)件測試以及1/4系統(tǒng)測試。
8. 作為一門學(xué)科建芙，我們?nèi)狈?shù)據(jù)估計没隘。
9. 我們對自己的估計技術(shù)不確定，因為在管理和客戶的壓力下禁荸，我們常常缺乏堅持的勇氣右蒲。
10. Brooks法則：為進(jìn)度落后的項目增加人手，只會使進(jìn)度更加落后赶熟。
11. 向軟件項目中增派人手三個方面增加了項目必要的總體工作量：任務(wù)重新分配本身和所造成的工作中斷：培訓(xùn)新人員：額外的互相溝通瑰妄。

外科手術(shù)隊伍

1. 同樣有兩年講演而且在收到同樣培訓(xùn)的情況下，優(yōu)秀的專業(yè)程序員的生產(chǎn)率是較差的程序員的10倍钧大。
2. 小型翰撑，精干隊伍是最好的-思緒盡可能少。
3. 實際上，絕大數(shù)大型編程系統(tǒng)的經(jīng)驗顯示眶诈，一擁而上的開發(fā)方法是高成本涨醋，速度緩慢，低效的逝撬，開發(fā)出的產(chǎn)品無法進(jìn)行概念上的集成浴骂。
4. 一位首席程序員，類似于外科手術(shù)隊伍的團(tuán)隊架構(gòu)提供了一種方法-既能獲得由少數(shù)頭腦產(chǎn)生的產(chǎn)品完整性宪潮，又能得到多位協(xié)助人員的總體生產(chǎn)率溯警，還徹底減少了溝通的工作量。

貴族專制狡相，民主政治和系統(tǒng)設(shè)計

1. “概念完整性是系統(tǒng)設(shè)計中最重要的考慮因素梯轻。”
2. “功能與理解上的復(fù)雜程度的比值才是系統(tǒng)設(shè)計的最終測試標(biāo)準(zhǔn)”尽棕，而不是豐富的功能喳挑。
3. 為了獲得概念完整性，設(shè)計必須由一個人或者具有共識的小型團(tuán)隊來完成滔悉。
4. 將體系結(jié)構(gòu)方面與具體實現(xiàn)相分離是獲得概念完整性的強(qiáng)有力方法伊诵。
5. 如果要得到系統(tǒng)概念上的完整性，就必須有人控制這些概念回官。實際上是一種無序任何歉意的貴族專制統(tǒng)治曹宴。
6. 概念上統(tǒng)一的系統(tǒng)能更快地開發(fā)和測試。
7. 體系結(jié)構(gòu)歉提，設(shè)計實現(xiàn)笛坦，物理實現(xiàn)的許多工作可以并行。

畫蛇添足

1. 盡早交流和持續(xù)溝通能使結(jié)構(gòu)師有較好的成本意識唯袄，使開發(fā)人員獲得對設(shè)計的信心弯屈，并且不會混淆各自的責(zé)任分工。
2. 結(jié)構(gòu)師如何成功地影響實現(xiàn)：

• 牢記開發(fā)人員承擔(dān)創(chuàng)造性的實現(xiàn)責(zé)任恋拷；結(jié)構(gòu)師只能提出建議资厉。
• 時刻準(zhǔn)備著所指定的說明建議一種實現(xiàn)的方法，準(zhǔn)備接受任何其他可行的方法
• 對上述建議保持低調(diào)和平靜蔬顾。
• 準(zhǔn)備對所建議的改進(jìn)放棄堅持宴偿。
• 聽取開發(fā)人員在體系結(jié)構(gòu)上改進(jìn)的建議。

3. 第二個系統(tǒng)是人們所設(shè)計的最危險的系統(tǒng)诀豁，通常的傾向是過分地進(jìn)行設(shè)計窄刘。

貫徹執(zhí)行

1. 即使是大型的設(shè)計團(tuán)隊，設(shè)計結(jié)果也必須由一個或兩個人來完成舷胜，以確保這些決定是一致的娩践。
2. 必須明確定義體系結(jié)構(gòu)與先前定義不同的地方。
3. 處于精確性的考慮，我們需要形式化地設(shè)計定義翻伺，同樣材泄，我們需要記敘性定義來加深理解。

為什么巴比倫塔會失敗

1. 巴比倫塔項目的失敗是因為缺乏交流以及交流的結(jié)果 - 組織吨岭。
2. “因為左手不知道右手在做什么拉宗，從而進(jìn)度災(zāi)難，功能的不合理和系統(tǒng)缺陷紛紛出現(xiàn)辣辫〉┦拢”由于存在對其他人的各種假設(shè)，團(tuán)隊成員之間的理解開始出現(xiàn)偏差急灭。
3. 團(tuán)隊?wèi)?yīng)該以盡可能多的方式進(jìn)行互相之間交流姐浮，非正式地進(jìn)行簡要技術(shù)陳述的常規(guī)項目會議，共享的正式項目工作手冊化戳。
4. 項目工作手冊“不是獨立的一篇文檔”它是對項目必須產(chǎn)生的一系列文檔進(jìn)行組織的一種結(jié)構(gòu)单料。
5. 項目所有的文檔都必須是該結(jié)構(gòu)的一部分。
6. 需要盡早和仔細(xì)地設(shè)計工作手冊結(jié)構(gòu)点楼。
7. 事先制定良好結(jié)構(gòu)的工作手冊“可將后來書寫的文字放置在合適的章節(jié)中”并且可以提高產(chǎn)品手冊的質(zhì)量。
8. 每一個團(tuán)隊成員稱該了解所有的材料白对。
9. 實時更新是至關(guān)重要的掠廓。
10. 共享的電子手冊是能達(dá)到所有這些目標(biāo)的，更好的甩恼，更加低廉的蟀瞧，更加簡單的機(jī)制。
11. 團(tuán)隊組織的目標(biāo)是為了減少必須的交流和協(xié)作量条摸。
12. 組織中的交流是網(wǎng)狀么悦污，而不是樹狀結(jié)構(gòu)， 因此所有的特殊組織機(jī)制（往往體現(xiàn)為組織結(jié)構(gòu)中的虛線部分）都是為了進(jìn)行調(diào)整钉蒲，以克服樹狀組織結(jié)構(gòu)中交流缺乏的困難切端。
13. 每個子項目具有里那個領(lǐng)導(dǎo)角色 - 產(chǎn)品負(fù)責(zé)任，技術(shù)主管或結(jié)構(gòu)師顷啼。這兩個角色的職能有很大的區(qū)別踏枣，需要不同的技能。
14. 兩個角色的任意組合都可以是非常有效的钙蒙。

胸有成竹

1. 僅僅通過對編碼部分時間的估計茵瀑，然后乘以其他部分的相對系數(shù)，是無法得出對整項工作的精確估計的躬厌。
2. 構(gòu)建獨立小程序的數(shù)據(jù)不適用于編程系統(tǒng)項目马昨。
3. 當(dāng)使用適當(dāng)?shù)母呒壵Z言時，程序編制的生產(chǎn)率可以提高五倍。

削足適履

1. 除了運行時間意外鸿捧，程序所占據(jù)的內(nèi)存空間也是主要的開銷屹篓。
2. 從系統(tǒng)整體出發(fā)以及面相用戶的態(tài)度是軟件編程管理人員最重要的職能。
3. 為了取的良好的空間- 時間折中笛谦，開發(fā)隊伍需要得到特定的某種語言或機(jī)型的編程技能培訓(xùn)抱虐，特別是在使用新語言或者新機(jī)器時。
4. 編程需要技術(shù)積累饥脑，每個項目需要自己的標(biāo)準(zhǔn)組件庫恳邀。
5. 精煉，充分和快速的程序往往是戰(zhàn)略性突破的結(jié)果灶轰，而不僅僅是技巧上的提高谣沸。
6. 這種突破常常是一種新型算法。

提綱挈領(lǐng)

1. 在一片文件的汪洋中笋颤，少數(shù)文檔成為了關(guān)鍵的樞紐乳附，每個項目管理的工作都圍繞著他們運轉(zhuǎn)。
2. 對于計算機(jī)硬件開發(fā)項目伴澄，關(guān)鍵文檔是目標(biāo)赋除，手冊，進(jìn)度非凌，預(yù)算举农，組織結(jié)構(gòu)圖，空間分配以及機(jī)器本身的報價敞嗡，預(yù)測和價格颁糟。
3. 對文檔進(jìn)行規(guī)范化。
4. 項目經(jīng)理的基本職責(zé)是使每個人都向著相同的方向進(jìn)行喉悴。
5. 項目經(jīng)歷的主要日常工作是溝通棱貌，而不是做出決定，文檔使各項計劃和決策在整個團(tuán)隊范圍內(nèi)得到交流箕肃。

未雨綢繆

1. 第一個開發(fā)的系統(tǒng)對于大多數(shù)項目并合用婚脱。它可能太慢，太大突雪，而且難以使用起惕，或者三者兼而有之。
2. 系統(tǒng)的丟棄和重新設(shè)計可以一步完成咏删，也可以一塊塊地實現(xiàn)惹想，但這是必須完成的步驟。
3. 開發(fā)人員交付的是用戶滿意陳谷督函，而不僅僅是實際的產(chǎn)品嘀粱。
4. 用戶的實際需要和用戶感覺會隨著程序的構(gòu)建激挪，測試和使用而變化。
5. 軟件產(chǎn)品易于掌握的特性和不可見性锋叨，導(dǎo)致它的構(gòu)建人員面臨著永恒的需求變更垄分。
6. 目標(biāo)上的一些正常變化無可避免，事先為他們做準(zhǔn)備總比假設(shè)他們不會出現(xiàn)要好的多娃磺。
7. 高級語言的使用薄湿，編譯時操作，通過引用的聲明整合和自文檔技術(shù)能減少變更引起的錯誤偷卧。
8. 程序員不愿意為設(shè)計書寫聞到那股豺瘤，不僅僅是因為惰性，更多的是源于設(shè)計人員的躊躇 - 要為自己嘗試性的設(shè)計決策進(jìn)行辯解听诸。
9. 為變更組建團(tuán)隊比為變更進(jìn)行設(shè)計更加困難坐求。
10. 只要管理人員和技術(shù)人才的天賦允許，老板必須對他們的能力培養(yǎng)給予極大的關(guān)注晌梨，使管理人員和技術(shù)人才具有互換性桥嗤，特別是希望在技術(shù)和管理角色之間自由地分配人手的時候。
11. 對于一個廣泛使用的程序仔蝌，其維護(hù)總成本通常是開發(fā)成本的40%或更多泛领。
12. 維護(hù)成本受用戶數(shù)目的影響。用戶越多敛惊，所發(fā)現(xiàn)的錯誤也越多师逸。
13. 缺陷修復(fù)總會以20%-50%的幾率引入新的bug。
14. 每次修復(fù)之后豆混，必須重新運行先前所有的測試用例，確保系統(tǒng)不會以更隱蔽的方式被破壞动知。
15. 所有修改都傾向與破壞系統(tǒng)的架構(gòu)皿伺，增加了系統(tǒng)的混亂程度。即使是最熟練的軟件維護(hù)工作盒粮，也只是延緩了系統(tǒng)退化到不可修復(fù)的混亂狀態(tài)的進(jìn)程鸵鸥，以致必須要重新進(jìn)行設(shè)計。

干將莫邪

1. 拋開理論不談丹皱，一次分配給某個小組的連續(xù)的目標(biāo)時間快被證明是最好的安排方法妒穴，比不同小組的穿插使用更為有效。
2. 主程序庫應(yīng)劃分為 1 一系列獨立的私有開發(fā)庫 2 正處在系統(tǒng)測試下的系統(tǒng)集成子庫 3 發(fā)布版本摊崭。正式的分離和進(jìn)度提供了控制讼油。
3. 高級語言不僅提高了生產(chǎn)率，還改進(jìn)了調(diào)試呢簸，bug更少矮台，而且更容易尋找乏屯。

整體部分

1. 許許多多的失敗完全源于那些產(chǎn)品未精確定義的地方。
2. 有時必須回退瘦赫，推翻頂層設(shè)計辰晕，重新開始。
3. 系統(tǒng)調(diào)試所花費的時間會比預(yù)料的更長确虱。
4. 系統(tǒng)調(diào)試的困難程度證明了需要一種完備系統(tǒng)化和可計劃的方法含友。
5. 開發(fā)大量的輔助調(diào)試平臺和測試代碼是很值得的，代碼量甚至可能有測試對象的一半校辩。
6. 必須有人對變更和版本進(jìn)行控制和文檔化窘问。

禍起蕭墻

1. 一天一天的進(jìn)度落后比起重大災(zāi)難更難以識別，更不容易防范和更加難以擬補召川。
2. 李成碧必須是具體的南缓，特定的和可度量的事件，能進(jìn)行 清晰的定義荧呐。
3. 慢性進(jìn)度偏離是士氣殺手汉形。
4. 進(jìn)取對于杰出的軟件開發(fā)團(tuán)隊是不可缺乏的必要品德。
5. PERT餓準(zhǔn)備工作是PERT圖使用中最有價值的部分倍阐。
6. 第一份PERT圖總是很恐怖概疆。
7. 每個老板同時需要采取行動的異常信息以及用來進(jìn)行分析和早期預(yù)警的狀態(tài)數(shù)據(jù)。
8. 狀態(tài)的獲取是困難的峰搪，因為下屬經(jīng)理有充分的理由不提供信息共享岔冀。
9. 老板的不良反應(yīng)肯定會對信息的完全公開造成壓制，相反概耻，仔細(xì)區(qū)分狀態(tài)報告使套，毫無驚慌地接收報告，決不越俎代庖鞠柄，將能鼓勵誠實的匯報侦高。

另外一面

1. 對于軟件編程產(chǎn)品來說，程序向用戶所呈現(xiàn)的面貌- 聞到那股厌杜，與提供給機(jī)器識別的內(nèi)容同樣重要奉呛。
2. 即使是完全開發(fā)給自己使用的程序，描述性文字也是必須的夯尽，因為他們會被用戶-作者所遺忘瞧壮。
3. 培訓(xùn)和管理人員基本上沒有向編程人員成功地灌輸對待聞到那股的積極態(tài)度 - 文檔能在整個生命周期對客服懶惰和進(jìn)度的壓力起促進(jìn)和激勵作用。
4. 大多數(shù)聞到那股只提供了很少的總結(jié)性內(nèi)容匙握。必須放慢腳步咆槽，穩(wěn)妥地進(jìn)行。
5. 流程圖是被吹捧的最過分的一種程序文檔肺孤。
6. 如果這樣罗晕，很少有程序需要一頁紙以上的流程圖
7. 程序員改人員所使用的文檔中济欢，除了描述事件如何，還應(yīng)闡述它為什么那樣小渊，對于加深理解法褥，目的是非常關(guān)鍵的，即使是高級語言的語法酬屉，也不能表達(dá)目的半等。
8. 軟件系統(tǒng)可能是人類創(chuàng)造中最錯綜復(fù)雜的事物。
9. 軟件工程的焦油坑在將來很長一段事件內(nèi)仍然會使人們舉步維艱呐萨，無法自拔杀饵。

• 從程序到編程產(chǎn)品至少是開發(fā)程序時間的三倍，需要有完備的文檔谬擦，每個人都可加已使用切距，修復(fù)和擴(kuò)展。

職業(yè)的樂趣

• 這種快樂是一種創(chuàng)造事物的純粹快樂惨远，特別是自己進(jìn)行設(shè)計谜悟。
• 其次，這種快樂來自于開發(fā)對他人有用的東西北秽。內(nèi)心深處葡幸。我們期望我們的勞動成果能夠被他人使用，并能對他們有所幫助贺氓。
• 第三蔚叨，快樂來自于整體過程體現(xiàn)出的一股強(qiáng)大的而魅力，并收到了預(yù)期的效果辙培。
• 持續(xù)學(xué)習(xí)的快樂蔑水，來自于這項工作的非重復(fù)特性，人們所面臨的問題總有這樣那樣的不同扬蕊，因而解決問題的人可以從中學(xué)習(xí)新的事物肤粱。
• 程序員就像詩人一樣，幾乎僅僅在單純的思考中工作厨相。程序員憑空地運用自己的想象，來建造自己的“城堡”鸥鹉。

職業(yè)的苦惱

• 苦惱來自于追求完美蛮穿。我認(rèn)為，學(xué)習(xí)編程最困難的部分毁渗，是將做事的方式向追求完美的方向調(diào)整践磅。
• 其次，苦惱來自由他人來設(shè)定目標(biāo)灸异，供給資源和提供信息府适。
• 對于系統(tǒng)編程人員而言羔飞，對其他人的依賴是一件非常痛苦的事情。他依靠其他人的程序檐春，而這些程序往往設(shè)計的并不合理逻淌，實現(xiàn)出拙劣，發(fā)布不完成整疟暖，文檔記錄很糟糕卡儒。
• 尋找瑣碎的bug是一項重復(fù)行的勞動，往往枯燥沉悶俐巴。

人月

• 用人月作為衡量工作的規(guī)模是一個危險和帶有欺騙性的神話骨望。
• 人數(shù)和時間的互換僅僅適用于，他們之間不需要相互交流欣舵。
• 溝通所增加的負(fù)擔(dān)：培訓(xùn)和相互交流擎鸠。在一個不可分解的任務(wù)時，人數(shù)的增加反而會使得項目時間增加缘圈。
• 軟件開發(fā)本質(zhì)是一項系統(tǒng)工作 - 錯綜復(fù)雜關(guān)系下的一種實踐劣光，溝通，交流的工作量非常大准验，添加更多的人手赎线，實際上延長了而不是縮短了時間進(jìn)度。

系統(tǒng)測試

• 軟件任務(wù)的進(jìn)度安排糊饱。1/3計劃垂寥，1/6編碼，1/4構(gòu)件測試和早期系統(tǒng)測試另锋，1/4系統(tǒng)測試滞项，所有的構(gòu)件完成。
• 不為系統(tǒng)測試安排足夠的時間夭坪，簡直就是一場災(zāi)難文判。

進(jìn)度災(zāi)難

• 向進(jìn)度落后的項目增加人手，只會使得進(jìn)度更加落后室梅。
• 項目的時間依賴于順序上的限制
• 人員的最大數(shù)量依賴于獨立子任務(wù)的數(shù)量

問題

• 一流人才組成的小型戏仓，精干的隊伍，而不是那些幾百人大型團(tuán)隊亡鼠，這里的“人”當(dāng)然暗指平庸的程序員
• 優(yōu)秀的程序員和較差的程序員之間生產(chǎn)率的差異赏殃，實際測量出的差異領(lǐng)人吃驚，最好的和最差的表現(xiàn)在生產(chǎn)率上平局能為10：1间涵，在編程速度和空間上具有5：1的驚人差異
• 簡言之仁热，20000美元/年的程序員的生產(chǎn)率可能是10000美元/年的程序員10倍。
• 實際上勾哩，絕大多數(shù)大型編程系統(tǒng)的經(jīng)驗顯示出抗蠢，一擁而上的開發(fā)方法是高成本的举哟，速度緩慢的，低效的迅矛，開發(fā)出的是無法在概念上集成的產(chǎn)品妨猩。

組織架構(gòu)

• 我認(rèn)為產(chǎn)品負(fù)責(zé)任作為管理者是更合適的安排。

控制規(guī)模

• 更深刻的教訓(xùn)體現(xiàn)在以上的經(jīng)驗中诬乞，項目規(guī)模本身很大册赛，缺乏管理和溝通，以至于每個團(tuán)隊成員認(rèn)為自己是爭取小紅花的學(xué)生震嫉，而不是勾踐系統(tǒng)軟件產(chǎn)品的人員森瘪。為了滿足目標(biāo)，每個人都在局部優(yōu)化自己的程序票堵，很少會有人聽再來扼睬，考慮一下對客戶的整體影響。

文檔

• 技術(shù)悴势，周邊組織機(jī)構(gòu)窗宇，行業(yè)傳統(tǒng)等若干因素湊在一起，定義了項目必須準(zhǔn)備的一些文書供祖宗特纤。對于一個剛從技術(shù)人員中任命的項目經(jīng)歷來說军俊，這減脂是一件徹頭徹尾，令人生厭的事情捧存。
• 慢慢地粪躬，他逐漸認(rèn)識到這些文檔的某些部分包含和表達(dá)了一些管理 方面的工作。每分文檔的準(zhǔn)備工作是集中考慮昔穴，并使各種討論意見明細(xì)化的主要時刻镰官。如果不這樣，項目往往會處于無休止的混亂狀態(tài)中吗货，文檔的跟蹤維護(hù)是項目監(jiān)督和預(yù)警的機(jī)制泳唠。文檔本身可以作為檢查列表，狀態(tài)控制宙搬，也可以作為回報的數(shù)據(jù)基礎(chǔ)笨腥。

未雨綢繆

• 對于大多數(shù)項目，第一個開發(fā)的系統(tǒng)并不合用勇垛。它可能太慢扇雕，太大，而且難以使用窥摄，或者三者兼而有之。要解決所有的問題础淤，除了重新開始以外崭放，沒有其他的辦法哨苛。即開始一個更靈巧或更好的系統(tǒng)，系統(tǒng)的丟棄和重新設(shè)計可以一步完成币砂，也可以一塊塊地實現(xiàn)建峭，所有大型系統(tǒng)的經(jīng)驗都顯示，這是必須完成的步驟决摧。而且亿蒸，新的系統(tǒng)概念或新技術(shù)會不斷出現(xiàn)，必須構(gòu)建一個用來拋棄的系統(tǒng)掌桩，因為即使是最優(yōu)秀的項目經(jīng)歷边锁，也不能無所不知地在最開始解決這些問題。
• 我從不建議顧客所有的目標(biāo)和需求的變更必須波岛，能夠或者應(yīng)該整合到設(shè)計中茅坛，項目開始時建立的基準(zhǔn)，肯定會隨著開發(fā)的進(jìn)行越來越高则拷，甚至開發(fā)不出任何產(chǎn)品贡蓖。
• 程序員不愿意為設(shè)計書寫文檔的原因，不僅僅是因為惰性或者時間的壓力煌茬。相反斥铺，設(shè)計人員通常不愿意提交嘗試行的設(shè)計決策，再為他們進(jìn)行辯解坛善×乐“通過設(shè)計文檔化，設(shè)計人員講自己暴露在每個人的批評之嚇浑吟，他必須能夠為他書寫的一切進(jìn)行辯護(hù)笙纤。如果團(tuán)隊加固因此收到任何形式的威脅，則沒有任何東西會被文檔化组力，除非架構(gòu)是完全受到保護(hù)的省容。”
• 對于一個廣泛使用的程序燎字，其維護(hù)總成本通常是開發(fā)成本的40%或更多腥椒。令人吃驚的是，該成本受用戶數(shù)目的影響很大候衍。用戶越多笼蛛，所發(fā)現(xiàn)的錯誤就越多。
• 一個有趣的循環(huán)蛉鹿，上一個版本中被發(fā)現(xiàn)和修復(fù)的bug滨砍，在新的版本中仍會出現(xiàn)，新版本中的新功能會產(chǎn)生新的bug。解決了這些問題以后惋戏，程序會正常運行幾個月领追，接著，錯誤率會重新攀升响逢，這是因為用戶的使用達(dá)到了新的熟練水平绒窑，開始運用新的功能，這種高強(qiáng)度的考驗查處了新功能中很多不易察覺的問題舔亭。
• 用在修復(fù)原有設(shè)計上瑕疵的工作量越來越少些膨，而早期維護(hù)活動本身所引起的漏洞的修復(fù)工作越來越多，隨著時間的推移钦铺，系統(tǒng)變得越來越無序订雾，修復(fù)工作遲早會失去根基。每一步前進(jìn)都伴隨著一步后退职抡，盡管系統(tǒng)在理論上一直可用葬燎，但實際上，整個系統(tǒng)已經(jīng)面目全非缚甩。
• 系統(tǒng)軟件開發(fā)是減少混亂度的過程谱净，所以它本身是處于亞穩(wěn)態(tài)的，軟件維護(hù)是提高混亂度的過程擅威。即使是熟練的軟件維護(hù)工作壕探，也只是放緩了系統(tǒng)退化到非穩(wěn)態(tài)的過程。此時就需要大規(guī)模重構(gòu)郊丛。

工具

• 就工具而言李请，即使是現(xiàn)在，很多軟件項目仍然像經(jīng)營一家五金店厉熟。每個骨干人員都仔細(xì)地保管自己工作生涯的一套工具集导盅，這些工具成為個人技能的直觀證明，正式如此揍瑟，每個編程人員也保留著編輯器白翻，排序，內(nèi)存信息轉(zhuǎn)儲和磁盤空間使用程序的鞏固绢片。
• 所以在前面關(guān)于軟件開發(fā)隊伍的討論中滤馍，我建議為每個團(tuán)隊配備一個工具管理人員。這個角色管理所有通用工具底循，能知道他的客戶和老板如何使用工具巢株。同時，他還能編制老板需要的專業(yè)工具熙涤。

文檔

• 面對那些文檔“簡約”的程序阁苞，我們中的大多數(shù)人都不免曾經(jīng)暗罵那些遠(yuǎn)在他方的匿名作者困檩。因為，一些視圖向新人慢慢地灌輸文檔的重要性那槽，旨在延長軟件的生命期窗看，克服惰性和進(jìn)度的壓力。但是倦炒，很多次嘗試都失敗了，我想可能是由于我們使用了錯誤的方法软瞎。
• 每個用戶都需要一段對程序進(jìn)行描述的文字逢唤。可是太多數(shù)文檔只提供了很少的總結(jié)性內(nèi)容涤浇，無法達(dá)到用戶要求鳖藕，就像是描繪了樹木，形容了樹皮和樹葉只锭，但確沒有一幅森林的圖案著恩，為了得到一份有用的文字描述，就必須放慢腳步蜻展，穩(wěn)妥前行
• 流程圖是被吹捧的最過分的一種程序文檔喉誊，事實上，很多程序甚至不需要流程圖纵顾，很少有程序需要一頁紙以上的流程圖伍茄。
• 現(xiàn)實中，我從來沒有看過一個有經(jīng)驗的編程人員吆你，在開始編寫程序之前碧磅，會例行公事地繪制詳盡的流程圖灸叼。在一些要求流程圖的組織中，流程圖總是事后才補上的曹仗。

如何培養(yǎng)杰出的設(shè)計人員

• 盡可能早地，有系統(tǒng)地識別頂級的設(shè)計人員蠕搜，最好的通常不是最有經(jīng)驗的人員
• 為設(shè)計人員指派一位職業(yè)導(dǎo)師怎茫，負(fù)責(zé)他們技術(shù)方面的成長，仔細(xì)地為他們規(guī)劃職業(yè)生涯讥脐。
• 為每個方面指定和維護(hù)一份職業(yè)計劃遭居，包括與設(shè)計大師的，經(jīng)過仔細(xì)挑選的學(xué)習(xí)過程旬渠，正式的高級教育和短期的課程俱萍，所有這些穿插在設(shè)計和技術(shù)領(lǐng)導(dǎo)能力的培養(yǎng)安排中。
• 為成長中的設(shè)計人員提供交流和激勵的機(jī)會告丢。

面向?qū)ο?/h1>

• 因為OO和各種復(fù)雜語言的聯(lián)系已經(jīng)很緊密枪蘑，人們并沒有被告訴OO是一種設(shè)計方式损谦，并xang他們講授設(shè)計方法和原理，大家只是被告知OO是一種設(shè)計方法岳颇，并向他們講授設(shè)計方法和原理照捡，大家只是被告知OO是這一種特殊工具，而我們可以用任何工具寫出優(yōu)質(zhì)或低劣的代碼话侧。除非我們給人們講解無任何設(shè)計栗精，否則語言所起的所用非常小，結(jié)果人們使用這種語言做出不好的設(shè)計瞻鹏，沒有從中獲得多少價值悲立。而一旦獲得的價值太少，它就不會流行新博。
• 面相對象技術(shù)包含了很多方法學(xué)上的進(jìn)步薪夕，OO的前期投入很多 ，主要是重新培訓(xùn)程序員用很新的方法進(jìn)行思考赫悄。面相對象在整個開發(fā)周期中得到了應(yīng)用原献，但是真正的獲益只有在后續(xù)開發(fā)，拓展和維護(hù)活動中才能體現(xiàn)出來埂淮。Coggin說：面相對象技術(shù)不會加快首次或第二次的開發(fā)姑隅，產(chǎn)品族群中第五個項目的開發(fā)將會異乎尋常的循序。
• 為了預(yù)期中的同诫，但有寫不確定的收益粤策，冒著風(fēng)險投入資金是投資人每天在做的事情。不過误窖，在很多軟件工資叮盘，這需要真正的管理勇氣，一種比技術(shù)競爭力或者優(yōu)秀管理能力更少有的精神霹俺。我認(rèn)為極度的前期投入和收益的推后是使OO技術(shù)應(yīng)用遲緩的最大原因柔吼。

重用的情況

• 大多數(shù)的豐富經(jīng)驗的程序員都擁有自己的私人開發(fā)庫，使用大約30%的重用代碼來開發(fā)軟件丙唧。公司級別的重用能提供70%的重用代碼量愈魏，它需要特殊的開發(fā)庫和管理支持。公司級別的重用代碼意味著需要對項目中的變更進(jìn)行統(tǒng)計和度量想际，從而提高重用的可信程度培漏。