【正文】 法控制的事物（特別是程序）；權(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í)的威脅。形式化定義是精確的，它們傾向于更加完整；差異得更加明顯，可以更快地完成。調(diào)試，是一種檢驗(yàn)程序中的方法。每個(gè)開發(fā)機(jī)構(gòu)都需要這樣一個(gè)獨(dú)立的技術(shù)監(jiān)督部門，來保證其公正性。其實(shí)，對(duì)于一個(gè)項(xiàng)目，我們要盡量做到完美，減少以后的維護(hù)困難和成本。先民們所說的圣人以及通神者，皆因他們多數(shù)時(shí)候在準(zhǔn)確地預(yù)言自己的切實(shí)。我們也覺察，在大多數(shù)情形下，先哲們的預(yù)言在實(shí)踐中被檢討著，只是偶爾“不太靈光”。那么在“小那么一點(diǎn)點(diǎn)的”工程項(xiàng)目中，是不是這些答案就無須定了呢?例如Brooks的眾多提倡，對(duì)于某些目標(biāo)——例如你要用為期三個(gè)月的工夫開發(fā)一個(gè)的產(chǎn)品——就并不是很管用。而按照《人月神話》的數(shù)據(jù)：人均效率800號(hào)召/人年，則這個(gè)“大型項(xiàng)目”。從性質(zhì)上來說，Brooks在《人月神話》中只是談?wù)摿舜笮凸こ痰膮栃?，以及相?yīng)規(guī)模下的群體創(chuàng)立。反到來，只有把工程做大，大到“爽利”錯(cuò)過了含義，而“宏偉”變成了性質(zhì)的時(shí)候，傳統(tǒng)工程就可感受任何失利找到借口：看啊，Brooks就說過“未曾銀彈”嘛。Brooks感受編程系統(tǒng)產(chǎn)品的工作量可能是自力更生小型過程的9倍(在告終大約雷同功能的情形下)。Brooks談?wù)摰木幊滔到y(tǒng)產(chǎn)品的規(guī)模究竟有多大呢?我想起碼該當(dāng)是以IBM 360為參看的。例如Ap正是因?yàn)楦鹬亻_發(fā)人員的稟性與力氣，以及互相間的配合而獲得了效率的晉級(jí)。但萬一這種預(yù)言的前提不準(zhǔn)確，那么未來定然脫離這種波及而回到它該當(dāng)?shù)氖聭B(tài)上去。然而我感受懇摯的可怕之處在于：現(xiàn)今凡是論及工程(且不要讓人感受是離經(jīng)叛道)，那么所解說的定然是Brooks的這么的經(jīng)驗(yàn)以及由此推出的見解，可能在不違拗這些經(jīng)驗(yàn)和見解上的一些翔實(shí)的實(shí)作措施!我們?nèi)徊活檿兴允羌傧?，還是性質(zhì)的推論，可能只是假象歸納的一個(gè)(未必準(zhǔn)確的)答案。維護(hù)成本受用戶數(shù)目的嚴(yán)重影響，用戶越多，所發(fā)現(xiàn)的錯(cuò)誤也越多。產(chǎn)品測(cè)試時(shí)每個(gè)產(chǎn)品在提交給用戶的一道程序。規(guī)模預(yù)算必須與分配的功能相關(guān)聯(lián)； 在指明模塊大小的同時(shí)，確切定義模塊的功能。手冊(cè)、或者書面規(guī)格說明，是一個(gè)非常必要的工具，盡管光有文檔是不夠的。對(duì)于編程，有其樂趣和苦惱。成本的確隨開發(fā)產(chǎn)品的人數(shù)和時(shí)間的不同，有著很大的變化，進(jìn)度卻不是如此。維護(hù)成本受用戶數(shù)目的嚴(yán)重影響，用戶越多，所發(fā)現(xiàn)的錯(cuò)誤也越多。產(chǎn)品測(cè)試時(shí)每個(gè)產(chǎn)品在提交給用戶的一道程序。規(guī)模預(yù)算必須與分配的功能相關(guān)聯(lián)； 在指明模塊大小的同時(shí)，確切定義模塊的功能。手冊(cè)、或者書面規(guī)格說明，是一個(gè)非常必要的工具，盡管光有文檔是不夠的。對(duì)于編程，有其樂趣和苦惱。成本的確隨開發(fā)產(chǎn)品的人數(shù)和時(shí)間的不同，有著很大的變化，進(jìn)度卻不是如此。作者認(rèn)為軟件項(xiàng)目具有人狼的特性，因?yàn)檐浖?xiàng)目也可能變成一個(gè)怪物，一個(gè)落后進(jìn)度、超出預(yù)算、存在大量缺陷的怪物。 a Catastrophe這章節(jié)說明使項(xiàng)目進(jìn)度拖后的最大原因不是重要的事件，如新技術(shù)、重組等，而是一些瑣碎的小事，每件小事只耽誤半天或一天時(shí)間，但這種小事多以后，將使項(xiàng)目的進(jìn)度嚴(yán)重拖后。 Pounds in a FivePound Sack主要講述程序占用的空間等，在70年代比較突出，但現(xiàn)在好多了。在此我說說書中許多非常好的觀點(diǎn)。這個(gè)辦法行不通的話，難道只有“加班”一條路了？如果不想加班，不想削減功能，不想推遲發(fā)布日期，那么。”不知道其他公司的程序員們?nèi)绾慰?。無論對(duì)小軟件還是大軟件，都必須由一個(gè)設(shè)計(jì)師主導(dǎo)，最多兩個(gè)人討論來共同完成軟件的整體設(shè)計(jì)。由于OS/360是多達(dá)1000位程式師共同合作的大型軟件開發(fā)工作﹐讓他深刻了解到大型軟件開發(fā)的技術(shù)和管理上所面臨的種種困難和挑戰(zhàn)。那么，就當(dāng)作，新組建了一個(gè)團(tuán)隊(duì)吧。而本書作者Brooks得出的結(jié)論是對(duì)我是震撼性的：“向進(jìn)度落后的項(xiàng)目中增加人手，只會(huì)使進(jìn)度更加落后”。我的同事中有一個(gè)牛人，做出的貢獻(xiàn)特別大，應(yīng)該相當(dāng)于我們公司普通的十個(gè)程序員，不過工資最多也就是普通程序員的二倍。但要注意以后的Bug修改，功能擴(kuò)展的時(shí)候，也要時(shí)刻留意與最初的設(shè)計(jì)是否概念上相容。1，保持設(shè)計(jì)的概念完整。把感觸比較深的幾點(diǎn)記下來，順便整理一下自己的思路，與大家分享。概念的完整性，對(duì)于很多小規(guī)模軟件，由于開發(fā)人員不多，開發(fā)經(jīng)理一般都能控制住所有的代碼，概念完整性在組織層面就維持住了。不知道其他公司的程序員們?nèi)绾慰础Ｓ浀卯?dāng)年看《C＋＋編程思想》，Bruce說“十個(gè)婦女不能在一個(gè)月內(nèi)生下小孩”（大意），于我心有戚戚焉。要小心的是，新加入的人可能對(duì)原來的組織造成沖擊，或者對(duì)原來的設(shè)計(jì)有不同意見（特別是加入的人中有比較強(qiáng)大的設(shè)計(jì)者）。在1956~1965 之間﹐Brooks實(shí)際領(lǐng)導(dǎo)IBM 360 大型電腦的開發(fā)計(jì)劃﹐包括硬體結(jié)構(gòu)及龐大的OS/360作業(yè)系統(tǒng)在內(nèi)﹐因之他具有IBM 大型電腦之父的尊稱。本書對(duì)我觸動(dòng)最大的，一是保持設(shè)計(jì)的概念完整。二是“一個(gè)拿2倍工資的人，生產(chǎn)率可能是其他人的10倍。以前，增加人手基本是挽救進(jìn)度落后項(xiàng)目的主要辦法。不同的社會(huì)經(jīng)驗(yàn)，不同的思想狀態(tài)，對(duì)讀本書的心得也不一樣。講述的各種算法可能都不太適合與現(xiàn)在的高級(jí)語言，但Portman的觀點(diǎn)仍然適合現(xiàn)在，即編程人員實(shí)際的編程時(shí)間只有50%，其他的時(shí)間都花在了無關(guān)的瑣碎事情上。雖然這句話的意思只是說明精確定義產(chǎn)品將減少BUG的數(shù)量，但我看到了系統(tǒng)分析的最重要的工作——產(chǎn)品定義。(No Silver Bull