【正文】 etEssence and Accident in software Engineering)人狼是傳說中的妖怪，只有銀彈才能殺死他。第三篇：《人月神話》讀后感《人月神話》讀后感通過閱讀《人月神話》，我從中學(xué)到了一些東西：首先，開發(fā)一個(gè)項(xiàng)目，我們錯(cuò)誤的認(rèn)為用人月這個(gè)工作量單位來估計(jì)和進(jìn)行進(jìn)度安排。從而，添加更多的人手，實(shí)際上是延長了，而不是縮短了時(shí)間進(jìn)度。良好的工作手冊和組織架構(gòu)可以開發(fā)出更加符合用戶的需求。通常，開發(fā)一個(gè)軟件我們還會設(shè)立規(guī)模目標(biāo)，控制規(guī)模，發(fā)明一些減少規(guī)模的方法——就如同硬件開發(fā)人員為減少元器件所做的一樣。進(jìn)度表有時(shí)可以根據(jù)進(jìn)展情況進(jìn)行適度的修改。其維護(hù)基本上不同于硬件的維護(hù)，它主要由各種變更組成，如修復(fù)設(shè)計(jì)缺陷、新增功能、或者是使用環(huán)境或者配置變換引起的調(diào)整而且維護(hù)總成本通常是開發(fā)成本的40％或更多。Brooks 博士為人們管理復(fù)雜項(xiàng)目提供了最具洞察力的見解,既有很多發(fā)人深省的觀點(diǎn),又有大量軟件工程的實(shí)踐,影響著一代又一代….通過閱讀《人月神話》，我從中學(xué)到了一些東西：首先，開發(fā)一個(gè)項(xiàng)目，我們錯(cuò)誤的認(rèn)為用人月這個(gè)工作量單位來估計(jì)和進(jìn)行進(jìn)度安排。從而，添加更多的人手，實(shí)際上是延長了，而不是縮短了時(shí)間進(jìn)度。良好的工作手冊和組織架構(gòu)可以開發(fā)出更加符合用戶的需求。通常，開發(fā)一個(gè)軟件我們還會設(shè)立規(guī)模目標(biāo)，控制規(guī)模，發(fā)明一些減少規(guī)模的方法——就如同硬件開發(fā)人員為減少元器件所做的一樣。進(jìn)度表有時(shí)可以根據(jù)進(jìn)展情況進(jìn)行適度的修改。其維護(hù)基本上不同于硬件的維護(hù)，它主要由各種變更組成，如修復(fù)設(shè)計(jì)缺陷、新增功能、或者是使用環(huán)境或者配置變換引起的調(diào)整而且維護(hù)總成本通常是開發(fā)成本的40％或更多。我在開篇中說《人月神話》“是一本可怕的書”。大師們預(yù)言了未來也就改換了未來，即便未來未必“該當(dāng)”好像他所預(yù)言的那樣。我們追憶上一細(xì)節(jié)，在《人月神話》中的那“31%的答案”的前提——也即便那7%的性質(zhì)中，如下兩項(xiàng)是顯明猜忌的(也是重要置疑)：目標(biāo)的性質(zhì)：是大型工程，是系統(tǒng)項(xiàng)目，而不是過程個(gè)體的性質(zhì)：是私利性的其實(shí)早就有人意識到個(gè)體的性質(zhì)“未必全是私利的”，尊重這些個(gè)體就會帶來一些收獲。然而在我看來，Brooks早曾經(jīng)在最佳位置上，給出了撬動它們的一個(gè)支點(diǎn)：Brooks感受發(fā)生“自力更生小型過程”與“編程系統(tǒng)產(chǎn)品”是不同的問題。Brooks所述的工程是要獲得編程系統(tǒng)產(chǎn)品。為什么“爽利”之初頗受爭議?為什么爽利對一些中小型的群體顯得管用和可厲行?為什么當(dāng)這些爭議被擺在現(xiàn)在的獲勝平息爾后，傳統(tǒng)工程的理論家們卻不忘恨恨地評上一句：那是一種不能(或難以)利用于大型工程的措施呢?!因?yàn)槿f一大家都很“爽利”，都只做比這些大型工程“小那么一點(diǎn)點(diǎn)”的工程，那么傳統(tǒng)工程的專家們就失業(yè)了。而我們，便按照這么的設(shè)定來擺開了全副軟件工作的工程化厲行。另外，還必需大約一倍的人工，來負(fù)責(zé)除開代碼之外的測驗(yàn)、管教、文檔和溝通等工作?？赡艽蠹s無法厲行——例如你的群體總共只有6個(gè)人，連“外科手術(shù)式的群體”都組織不起來，讀后感《人月神話讀后感》。下表則列出一些不同的例子：注1：我例舉了爽利的一些見解，并不闡明我是Ap/Xp的fans。只有當(dāng)這個(gè)“多數(shù)時(shí)候”變成半點(diǎn)的時(shí)候，先民們才會置疑圣人和通神者的力氣。在計(jì)算機(jī)技術(shù)進(jìn)步的同時(shí)，計(jì)算機(jī)相關(guān)學(xué)科知識也在飛速發(fā)展。產(chǎn)品－測試小組則是顧客的代理人，專門尋找缺陷。然而調(diào)試是系統(tǒng)編程中很慢和較困難的部分，而漫長的調(diào)試周轉(zhuǎn)時(shí)間是調(diào)試的禍根。但是形式化定義的缺點(diǎn)是不易理解。開發(fā)一個(gè)軟件，我們要有合理的時(shí)間進(jìn)度，開發(fā)人員要少而精，概念完整性必須考慮在內(nèi)，要盡量做到盡早交流和持續(xù)溝通。人數(shù)和時(shí)間的互換僅僅適用于以下情況：某個(gè)任務(wù)可以分解給參與人員，并且他們之間不需要相互的交流，而在系統(tǒng)編程中近乎不可能。在計(jì)算機(jī)技術(shù)進(jìn)步的同時(shí)，計(jì)算機(jī)相關(guān)學(xué)科知識也在飛速發(fā)展。產(chǎn)品－測試小組則是顧客的代理人，專門尋找缺陷。然而調(diào)試是系統(tǒng)編程中很慢和較困難的部分，而漫長的調(diào)試周轉(zhuǎn)時(shí)間是調(diào)試的禍根。但是形式化定義的缺點(diǎn)是不易理解。開發(fā)一個(gè)軟件，我們要有合理的時(shí)間進(jìn)度，開發(fā)人員要少而精，概念完整性必須考慮在內(nèi)，要盡量做到盡早交流和持續(xù)溝通。人數(shù)和時(shí)間的互換僅僅適用于以下情況：某個(gè)任務(wù)可以分解給參與人員，并且他們之間不需要相互的交流，而在系統(tǒng)編程中近乎不可能。他行動的第一步是將大塊的“巨無霸理論”替換成“微生物理論”。不了解，就無法真正擁有——歌德，作者引用的歌德的話來描述文檔對客戶的重要性，提出客戶需要什么樣的文檔以及文檔的格式和包含的內(nèi)容，指出當(dāng)時(shí)存在的大多數(shù)文檔只描述了樹木，形容了樹葉，但沒有整個(gè)森林的圖案。 Tools主要講述項(xiàng)目中管理好各種工具的重要性，項(xiàng)目經(jīng)理首先要制定一種策略，讓各種工具成為公用的工具，這樣才能使開發(fā)、維護(hù)和使用這種工具的開發(fā)人員的效率更高，這種工具可能是開發(fā)人員開發(fā)出來的，也可能是使用現(xiàn)有的，可能是通用的，也可能是專用的或個(gè)人偏好的。 SecondSystem Effect講述的基本都是基于IBM 360操作系統(tǒng)以及編譯程序等方面的經(jīng)驗(yàn)，講述如何避免開發(fā)第二個(gè)系統(tǒng)的風(fēng)險(xiǎn)，作者認(rèn)為開發(fā)第二個(gè)系統(tǒng)的設(shè)計(jì)師設(shè)計(jì)出來的系統(tǒng)是最危險(xiǎn)的,因此要求他們自律。而且不要逐步加入，一定要一次性加入。微軟就是這種思路吧，把最聰明的人集中在一起，想不成功都難。需要注意的一點(diǎn)是，即使是總設(shè)計(jì)師一直是同一個(gè)人，他腦海中所認(rèn)為理所當(dāng)然的規(guī)則或者概念，很可能由于沒有明確的文檔化，而沒有成為所有開發(fā)者共同的概念。也就得出著名的Brooks法則── 「對于進(jìn)度已落后的軟件開發(fā)計(jì)劃而言﹐若再增加人力﹐只會讓其更加落