【正文】 不過，我決定去買本英文版回來，收藏，以后再多看幾次。需要注意的一點(diǎn)是，即使是總設(shè)計(jì)師一直是同一個人，他腦海中所認(rèn)為理所當(dāng)然的規(guī)則或者概念，很可能由于沒有明確的文檔化，而沒有成為所有開發(fā)者共同的概念。而且不要逐步加入，一定要一次性加入。 Tools主要講述項(xiàng)目中管理好各種工具的重要性，項(xiàng)目經(jīng)理首先要制定一種策略，讓各種工具成為公用的工具，這樣才能使開發(fā)、維護(hù)和使用這種工具的開發(fā)人員的效率更高，這種工具可能是開發(fā)人員開發(fā)出來的，也可能是使用現(xiàn)有的，可能是通用的，也可能是專用的或個人偏好的。他行動的第一步是將大塊的“巨無霸理論”替換成“微生物理論”。開發(fā)一個軟件，我們要有合理的時間進(jìn)度，開發(fā)人員要少而精，概念完整性必須考慮在內(nèi)，要盡量做到盡早交流和持續(xù)溝通。然而調(diào)試是系統(tǒng)編程中很慢和較困難的部分，而漫長的調(diào)試周轉(zhuǎn)時間是調(diào)試的禍根。在計(jì)算機(jī)技術(shù)進(jìn)步的同時，計(jì)算機(jī)相關(guān)學(xué)科知識也在飛速發(fā)展。開發(fā)一個軟件，我們要有合理的時間進(jìn)度，開發(fā)人員要少而精，概念完整性必須考慮在內(nèi)，要盡量做到盡早交流和持續(xù)溝通。然而調(diào)試是系統(tǒng)編程中很慢和較困難的部分，而漫長的調(diào)試周轉(zhuǎn)時間是調(diào)試的禍根。在計(jì)算機(jī)技術(shù)進(jìn)步的同時，計(jì)算機(jī)相關(guān)學(xué)科知識也在飛速發(fā)展。下表則列出一些不同的例子：注1：我例舉了爽利的一些見解，并不闡明我是Ap/Xp的fans。另外，還必需大約一倍的人工，來負(fù)責(zé)除開代碼之外的測驗(yàn)、管教、文檔和溝通等工作。為什么“爽利”之初頗受爭議?為什么爽利對一些中小型的群體顯得管用和可厲行?為什么當(dāng)這些爭議被擺在現(xiàn)在的獲勝平息爾后，傳統(tǒng)工程的理論家們卻不忘恨恨地評上一句：那是一種不能(或難以)利用于大型工程的措施呢?!因?yàn)槿f一大家都很“爽利”，都只做比這些大型工程“小那么一點(diǎn)點(diǎn)”的工程，那么傳統(tǒng)工程的專家們就失業(yè)了。然而在我看來，Brooks早曾經(jīng)在最佳位置上，給出了撬動它們的一個支點(diǎn)：Brooks感受發(fā)生“自力更生小型過程”與“編程系統(tǒng)產(chǎn)品”是不同的問題。大師們預(yù)言了未來也就改換了未來，即便未來未必“該當(dāng)”好像他所預(yù)言的那樣。其維護(hù)基本上不同于硬件的維護(hù)，它主要由各種變更組成，如修復(fù)設(shè)計(jì)缺陷、新增功能、或者是使用環(huán)境或者配置變換引起的調(diào)整而且維護(hù)總成本通常是開發(fā)成本的40％或更多。通常，開發(fā)一個軟件我們還會設(shè)立規(guī)模目標(biāo)，控制規(guī)模，發(fā)明一些減少規(guī)模的方法——就如同硬件開發(fā)人員為減少元器件所做的一樣。從而，添加更多的人手，實(shí)際上是延長了，而不是縮短了時間進(jìn)度。其維護(hù)基本上不同于硬件的維護(hù)，它主要由各種變更組成，如修復(fù)設(shè)計(jì)缺陷、新增功能、或者是使用環(huán)境或者配置變換引起的調(diào)整而且維護(hù)總成本通常是開發(fā)成本的40％或更多。通常，開發(fā)一個軟件我們還會設(shè)立規(guī)模目標(biāo)，控制規(guī)模，發(fā)明一些減少規(guī)模的方法——就如同硬件開發(fā)人員為減少元器件所做的一樣。從而，添加更多的人手，實(shí)際上是延長了，而不是縮短了時間進(jìn)度。(No Silver BulletEssence and Accident in software Engineering)人狼是傳說中的妖怪，只有銀彈才能殺死他。講述的各種算法可能都不太適合與現(xiàn)在的高級語言，但Portman的觀點(diǎn)仍然適合現(xiàn)在，即編程人員實(shí)際的編程時間只有50%，其他的時間都花在了無關(guān)的瑣碎事情上。以前，增加人手基本是挽救進(jìn)度落后項(xiàng)目的主要辦法。本書對我觸動最大的，一是保持設(shè)計(jì)的概念完整。要小心的是，新加入的人可能對原來的組織造成沖擊，或者對原來的設(shè)計(jì)有不同意見（特別是加入的人中有比較強(qiáng)大的設(shè)計(jì)者）。不知道其他公司的程序員們?nèi)绾慰础０迅杏|比較深的幾點(diǎn)記下來，順便整理一下自己的思路，與大家分享。但要注意以后的Bug修改，功能擴(kuò)展的時候，也要時刻留意與最初的設(shè)計(jì)是否概念上相容。而本書作者Brooks得出的結(jié)論是對我是震撼性的：“向進(jìn)度落后的項(xiàng)目中增加人手，只會使進(jìn)度更加落后”。由于OS/360是多達(dá)1000位程式師共同合作的大型軟件開發(fā)工作﹐讓他深刻了解到大型軟件開發(fā)的技術(shù)和管理上所面臨的種種困難和挑戰(zhàn)?！辈恢榔渌镜某绦騿T們?nèi)绾慰础Ｔ诖宋艺f說書中許多非常好的觀點(diǎn)。 a Catastrophe這章節(jié)說明使項(xiàng)目進(jìn)度拖后的最大原因不是重要的事件，如新技術(shù)、重組等，而是一些瑣碎的小事，每件小事只耽誤半天或一天時間，但這種小事多以后，將使項(xiàng)目的進(jìn)度嚴(yán)重拖后。成本的確隨開發(fā)產(chǎn)品的人數(shù)和時間的不同，有著很大的變化，進(jìn)度卻不是如此。手冊、或者書面規(guī)格說明，是一個非常必要的工具，盡管光有文檔是不夠的。產(chǎn)品測試時每個產(chǎn)品在提交給用戶的一道程序。成本的確隨開發(fā)產(chǎn)品的人數(shù)和時間的不同，有著很大的變化，進(jìn)度卻不是如此。手冊、或者書面規(guī)格說明，是一個非常必要的工具，盡管光有文檔是不夠的。產(chǎn)品測試時每個產(chǎn)品在提交給用戶的一道程序。然而我感受懇摯的可怕之處在于：現(xiàn)今凡是論及工程(且不要讓人感受是離經(jīng)叛道)，那么所解說的定然是Brooks的這么的經(jīng)驗(yàn)以及由此推出的見解，可能在不違拗這些經(jīng)驗(yàn)和見解上的一些翔實(shí)的實(shí)作措施!我們?nèi)徊活檿兴允羌傧?，還是性質(zhì)的推論，可能只是假象歸納的一個(未必準(zhǔn)確的)答案。例如Ap正是因?yàn)楦鹬亻_發(fā)人員的稟性與力氣，以及互相間的配合而獲得了效率的晉級。Brooks感受編程系統(tǒng)產(chǎn)品的工作量可能是自力更生小型過程的9倍(在告終大約雷同功能的情形下)。從性質(zhì)上來說，Brooks在《人月神話》中只是談?wù)摿舜笮凸こ痰膮栃校约跋鄳?yīng)規(guī)模下的群體創(chuàng)立。那么在“小那么一點(diǎn)點(diǎn)的”工程項(xiàng)目中，是不是這些答案就無須定了呢?例如Brooks的眾多提倡，對于某些目標(biāo)——例如你要用為期三個月的工夫開發(fā)一個的產(chǎn)品——就并不是很管用。先民們所說的圣人以及通神者，皆因他們