在軟件領(lǐng)域，很少能有像《人月神話》一樣具有深遠影響力和暢銷不衰的著作。Brooks博士為人們管理復(fù)雜項目提供了最具洞察力的見解，既有很多發(fā)人深省的觀點，又有大量軟件工程的實踐。本書內(nèi)容來自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的項目管理經(jīng)驗，該項目堪稱軟件開發(fā)項目管理的典范。該書英文原版一經(jīng)面世，即引起業(yè)內(nèi)人士的強烈反響，后又譯為德、法、日、俄、中、韓等多種文字，全球銷售數(shù)百萬冊。確立了其在行業(yè)內(nèi)的經(jīng)典地位。在《人月神話》第一次出版40年后的今天，我們重新整理了Brooks博士的經(jīng)典內(nèi)容，并將國內(nèi)軟件開發(fā)領(lǐng)域先行者們對《人月神話》中的實踐及系統(tǒng)理論的使用經(jīng)驗和心得集結(jié)成冊免費贈與大家共享，更使本書成為國內(nèi)從業(yè)者的必讀經(jīng)典之一。本書讀者包括：軟件開發(fā)人員、軟件項目經(jīng)理、系統(tǒng)分析師等IT從業(yè)者。
作者簡介：
小弗雷德里克布魯克斯曾獲得美國計算機領(lǐng)域最具聲望的圖靈獎(A.M.TuringAward)。美國計算機協(xié)會(ACM)稱贊他“對計算機體系結(jié)構(gòu)、操作系統(tǒng)和軟件工程做出了里程碑式的貢獻”。布魯克斯博士1956年開始任職于IBM公司，早期擔任Stretch和Harvest計算機的體系建構(gòu)師。他被認為是“IBM360系統(tǒng)之父”，曾擔任360系統(tǒng)的項目經(jīng)理。憑借在此項目中的杰出貢獻，他與BobEvans和ErichBloch在1985年獲得了美國國家技術(shù)獎(NationalMedalofTechnology)。布魯克斯博士創(chuàng)立了北卡羅來納大學的計算機科學系，并于1965-1985年擔任系主任。他還曾任職于美國國家科技局和國防科學技術(shù)委員會。目前其仍活躍于從事虛擬環(huán)境和科學可視化等方面的研究工作，2010年獲得虛擬現(xiàn)實事業(yè)獎(IEEEVirtualRealityCareerAward)。
目錄：
第1章焦油坑1
編程系統(tǒng)產(chǎn)品4
職業(yè)的樂趣6
職業(yè)的苦惱8
第2章人月神話11
樂觀主義14
人月16
系統(tǒng)測試19
空泛的估算21
重復(fù)產(chǎn)生的進度災(zāi)難22
第3章外科手術(shù)隊伍27
問題30
Mills的建議32
如何運作35
團隊的擴建36第1章焦油坑1編程系統(tǒng)產(chǎn)品4職業(yè)的樂趣6職業(yè)的苦惱8第2章人月神話11樂觀主義14人月16系統(tǒng)測試19空泛的估算21重復(fù)產(chǎn)生的進度災(zāi)難22第3章外科手術(shù)隊伍27問題30Mills的建議32如何運作35團隊的擴建36第4章貴族專制、民主政治和系統(tǒng)設(shè)計39概念的完整性42獲得概念的完整性43貴族專制統(tǒng)治和民主政治44在等待時，實現(xiàn)人員應(yīng)該做什么47第5章畫蛇添足51結(jié)構(gòu)師的交互準則和機制54自律——開發(fā)第二個系統(tǒng)所帶來的后果55第6章貫徹執(zhí)行59文檔化的規(guī)格說明——手冊62形式化定義63直接整合66會議和大會66多重實現(xiàn)68電話日志68產(chǎn)品測試69第7章為什么巴比倫塔會失敗71巴比倫塔的管理教訓75大型編程項目中的交流76項目工作手冊76大型編程項目的組織架構(gòu)80第8章胸有成竹85Portman的數(shù)據(jù)89Aron的數(shù)據(jù)90Harr的數(shù)據(jù)90OS/360的數(shù)據(jù)92Corbató的數(shù)據(jù)93第9章削足適履95作為成本的程序空間98規(guī)�？刂�99空間技能100數(shù)據(jù)的表現(xiàn)形式是編程的根本102第10章提綱挈領(lǐng)105計算機產(chǎn)品的文檔108大學科系的文檔110軟件項目的文檔110為什么要有正式的文檔111第11章未雨綢繆113試驗性工廠和增大規(guī)模116唯一不變的就是變化本身117為變更設(shè)計系統(tǒng)117為變更計劃組織架構(gòu)118前進兩步，后退一步120前進一步，后退一步122第12章干將莫邪125目標機器129輔助機器和數(shù)據(jù)服務(wù)131高級語言和交互式編程134第13章整體部分139剔除bug的設(shè)計142構(gòu)件單元調(diào)試144系統(tǒng)集成調(diào)試147第14章禍起蕭墻153里程碑還是沉重的負擔156“其他的部分反正會落后”158地毯的下面159第15章另外一面165需要什么樣的文檔169流程圖171自文檔化的程序175第16章沒有銀彈181摘要184介紹184根本困難185以往解決次要困難的一些突破190銀彈的希望192針對概念上根本問題的頗具前途的方法200第17章再論“沒有銀彈”209人狼和其他恐怖傳說212存在著銀彈——就在這里212含糊的表達將會導致誤解213Harel的分析216Jones的觀點——質(zhì)量帶來生產(chǎn)率221那么，生產(chǎn)率的情形如何222面向?qū)ο缶幊獭@顆銅質(zhì)子彈可以嗎223重用的情況怎樣225學習大量的詞匯——對軟件重用的一個可預(yù)見但還沒有被預(yù)言的問題228子彈的本質(zhì)——形勢沒有發(fā)生改變229第18章《人月神話》的觀點：是與非231第1章焦油坑234第2章人月神話235第3章外科手術(shù)隊伍236第4章貴族專制、民主政治和系統(tǒng)設(shè)計237第5章畫蛇添足238第6章貫徹執(zhí)行239第7章為什么巴比倫塔會失敗240第8章胸有成竹242第9章削足適履243第10章提綱挈領(lǐng)245第11章未雨綢繆246第12章干將莫邪249第13章整體部分251第14章禍起蕭墻253第15章另外一面255第1版結(jié)束語256第19章20年后的《人月神話》257為什么要出版20周年紀念版本260核心觀點——概念完整性和結(jié)構(gòu)師261開發(fā)第二個系統(tǒng)所引起的后果——盲目的功能和頻率猜測263圖形界面的成功265沒有構(gòu)建舍棄原型——瀑布模型是錯誤的269增量開發(fā)模型更佳——漸進地精化272關(guān)于信息隱藏，Parnas是正確的，我是錯誤的276人月到底有多少神話色彩？Boehm的模型和數(shù)據(jù)278人就是一切(或者說，幾乎是一切)280放棄權(quán)力的力量281最令人驚訝的新事物是什么？數(shù)百萬的計算機283全新的軟件產(chǎn)業(yè)——塑料薄膜包裝的成品軟件286買來開發(fā)——使用塑料包裝的成品軟件包作為構(gòu)件288軟件工程的狀態(tài)和未來290結(jié)束語：令人向往、激動人心和充滿樂趣的50年293注解與參考文獻295附錄：人月落地實戰(zhàn)體驗315一、名家談人月3171.年金3172.《人月神話》與實踐3183.FrankChance評人月3274.軟件尚方寶劍(SilverBullet)何在330二、名著評人月339三、讀者感言3511.讀書有感——人月神話3512.我這幾天很煩(產(chǎn)品概念完整性)3533.關(guān)于我們的思考——“項目開發(fā)”及讀《人月神話》有感3554.我的“人月神話”3585.《人月神話》軟玉生香360前言神品——代序*
這是本書中唯一的一節(jié)廢話。*
我是一個書狂，積習甚深，費盡心機在軟件工程、系統(tǒng)工程方面積累了一些書。書，在我看來當分為神品、精品和普通三等，其中神品、精品又分別有一、二和三品之分。我所收集的書中，軟件工程書大都屬于精品，神品只有兩本，F(xiàn)rederickP.Brooks的這本書就屬于神品之列。
軟件作為一個行業(yè)，逐步背起了“solvingthe wrong problem”(解決錯誤的問題)的名聲。問題決定解決方案，這也就是說，我們一直在制造錯誤解決方案！這方面有大量的神品——代序*這是本書中唯一的一節(jié)廢話。*我是一個書狂，積習甚深，費盡心機在軟件工程、系統(tǒng)工程方面積累了一些書。書，在我看來當分為神品、精品和普通三等，其中神品、精品又分別有一、二和三品之分。我所收集的書中，軟件工程書大都屬于精品，神品只有兩本，F(xiàn)rederickP.Brooks的這本書就屬于神品之列。軟件作為一個行業(yè)，逐步背起了“solvingthewrongproblem”(解決錯誤的問題)的名聲。問題決定解決方案，這也就是說，我們一直在制造錯誤解決方案！這方面有大量的證據(jù)，其中最著名的是美國政府統(tǒng)計署(GAO)的數(shù)據(jù)：全球最大的軟件消費商(美國軍方)每年要花費數(shù)十億美元購買軟件，而在其所購軟件中，可直接使用的只占2%，另外3%需要做一些修改，其余95%都成了垃圾。一句話，不管這些軟件是否符合需求規(guī)格，它們都顯然沒有滿足客戶的需求。面向?qū)ο蠹夹g(shù)并沒有給我們帶來“神奇的效應(yīng)”，不管開發(fā)商如何吹噓面向?qū)ο驩O(Object-Oriented)工具多么萬能，也不管那些OO狂熱者多么毅然地前赴后繼，這方面的數(shù)據(jù)從20世紀80年代以來并沒有發(fā)生大的改觀。這實在令我們的軟件工程專家和從業(yè)人員們羞愧，因為它揭示了我們可能一開始就從根本上做錯了什么！20世紀90年代中期，當軟件工程一代宗師MichaelJackson(非歌壇巨星MichaelJackson)宣布他們的研究結(jié)果時，立刻在軟件工程界激起了陣陣漣漪。Jackson指出，軟件從業(yè)人員和方法學大師們只是簡單地模仿和照搬其他學科的方法，卻將最重要的方面(問題域)忽略了。他指出，面向?qū)ο蠓椒ê徒Y(jié)構(gòu)化方法對問題域的處理沒有什么大的區(qū)別，卻被人們過分地用美好的詞匯美化了：“...Youcanseetheresultsclearlyinmanyobject-orientedmodelingdescriptions.Oftentheyareaccompaniedbyfinewordsaboutmodelingtherealworld.Butwhenyoulookcloselyyoucanseethattheyarereallydescriptionsofprogrammingobjects,pureandsimple.Anysimilaritytoreal-worldobjects,livingordead,ispurelycoincidental...”(……從眾多面向?qū)ο蠼５拿枋鲋校憧梢院芮宄乜吹竭@些惡果。而且它們還經(jīng)常伴隨著有關(guān)現(xiàn)實世界建模的非常美好的詞匯。然而，仔細看看，你就會發(fā)現(xiàn)它們其實是徹頭徹尾的編程對象！如果說有任何和現(xiàn)實世界對象相似的地方，不管是死是活，純屬巧合……)回首軟件工程近40年的發(fā)展，Jackson哀嘆軟件行業(yè)普遍缺乏專業(yè)性，充滿了業(yè)余人員，“手中有一個錘子，看到什么都是釘子”，誰都可以開發(fā)性命攸關(guān)的軟件。這就是我們面臨的嚴峻而復(fù)雜的現(xiàn)實，也許您會感到震驚！然而在大師FrederickP.Brooks眼里，是那么的平靜。因為早在28年前，他就在《人月神話》(TheMythicalMan-Month)這本不朽著作中對這些內(nèi)容做了深入論述。這本小冊子行文優(yōu)美，思想博大精深，字字真言，精讀之有不盡的趣味，藏之又是極珍貴的文獻，名眼高人，自能鑒之。前些年，一位朋友從印度歸來，說此書在印度極為普及，我也動起筆來，但慚愧終未成正果。汪穎兄素來勤懇，明知此翻譯為“successwithoutapplause,diligencewithoutreward”(沒有掌聲的成功，沒有回報的勤勉)，卻兢兢業(yè)業(yè)，反復(fù)琢磨，歷經(jīng)單調(diào)、繁瑣、艱辛的勞動，終于付梓。欽佩之余隨即作序共勉。DaveWangSEForumChina2002年3月于深圳20周年紀念版序言令我驚奇和高興的是，《人月神話》在20年后仍然繼續(xù)流行，印數(shù)超過了250000冊。人們經(jīng)常問，我在1975年提出的觀點和建議，哪些是我仍然堅持的，哪些是已經(jīng)改變了的，又是怎樣改變的？盡管我在一些講座上也分析過這個問題，但我還是一直想把它寫成文章。PeterGordon現(xiàn)在是Addison-Wesley的出版伙伴，他從1980年開始和我共事。他非常有耐心，對我?guī)椭艽�。他建議我們準備一個紀念版本。我們決定不對原版本做任何修訂，只是原封不動地重印(除了一些無足輕重的修正)，并用更新的思想來擴充它。第16章重印了一篇在1986年IFIPS會議上的論文“沒有銀彈：軟件工程的根本和次要問題”(NoSilverBullet：EssenceandAccidentsofSoftwareEngineering)。這篇文章來自我在國防科學委員會主持軍用軟件方面研究時的經(jīng)驗。我當時的研究合作者，也是我的執(zhí)行秘書，RobertL.Patrick，他幫助我回想和感受那些做過的軟件大項目。1987年，IEEE的《計算機》(Computer)雜志重印了這篇論文，使它傳播得更廣了。“沒有銀彈”被證明是富有煽動性的，它預(yù)言10年內(nèi)沒有任何編程技巧能夠給軟件的生產(chǎn)率帶來數(shù)量級上的提高。10年只剩下一年了，我的預(yù)言看來是安全了�！皼]有銀彈”激起了越來越多文字上的劇烈爭論，比《人月神話》還要多。因此在第17章，我對一些公開的批評做了說明，并更新了在1986年提出的觀點。在準備《人月神話》的回顧和更新時，一直在進行的軟件工程研究和經(jīng)驗已經(jīng)批評、證實或否定了少數(shù)書中斷言的觀點，也影響了我。剝?nèi)ポo助的爭論和數(shù)據(jù)后，把那些觀點粗略地分類，對我來說是很有幫助的。我在第18章列出了這些觀點的概要，希望這些單調(diào)的陳述能夠引來爭論和證據(jù)，然后得到證實、否定、更新或精煉。第19章是一篇更新的短文。讀者應(yīng)該注意的是，新觀點并不像原來的書一樣來自我的親身經(jīng)歷。我在大學里工作，而不是在工業(yè)界，做的是小規(guī)模的項目，而不是大項目。自1986年以來，我就只是教授軟件工程，不再做這方面的研究。我現(xiàn)在的研究領(lǐng)域是虛擬環(huán)境及其應(yīng)用。在這次回顧的準備過程中，我找了一些正在軟件工程領(lǐng)域工作的朋友，征求他們現(xiàn)在的觀點。他們很樂意與我分享他們的想法，并仔細地對草稿提出了意見，這些都使我重新受到啟發(fā)。感謝BarryBoehm、KenBrooks、DickCase、JamesCoggins、TomDeMarco、JimMcCarthy、DavidParnas、EarlWheeler和EdwardYourdon。感謝FayWard對新的章節(jié)進行了出色的技術(shù)加工。感謝我在國防科學委員會軍事軟件工作組的同事GordonBell、BruceBuchanan、RickHayes-Roth，特別是DavidParnas，感謝他們的洞察力和生動的想法。感謝RebekahBierly對第16章的論文進行了技術(shù)加工。我把軟件問題分成“根本的”和“次要的”，這是受NancyGreenwoodBrooks的啟發(fā)，她在一篇“Suzuki小提琴教育”的論文中應(yīng)用了這樣的分析方法。在1975年版本的序言中，Addison-Wesley出版社按規(guī)定不允許我在書中向該社的一些扮演了關(guān)鍵角色的員工致謝�？墒�，有兩個人的貢獻必須特別指出：執(zhí)行編輯NormanStanton和美術(shù)指導HerbertBoes。Boes設(shè)計了優(yōu)雅風格的版式和封面，他在評注時特別提到：“頁邊的空白要寬，字體和版面要有想象力�！备匾氖�，他提出了至關(guān)重要的建議：為每一章的開頭配一幅圖片(當時我只有“焦油坑”和“蘭斯大教堂”的圖片)。尋找這些圖片使我多花了一年的時間，但我永遠感激這個忠告。SoliDeoGloria——愿神獨得榮耀。FrederickP.Brooks,Jr.ChapelHill,N.C.1995年3月第1版序言在很多方面，管理一個大型的計算機編程項目與管理其他行業(yè)的大型工程很相似——比大多數(shù)程序員所認為的還要相似；在另外一些方面，它又有差別——比大多數(shù)職業(yè)經(jīng)理人所認為的差別還要大。這個領(lǐng)域的知識在于累積�，F(xiàn)在，AFIPS(美國信息處理學會聯(lián)合會)已經(jīng)有了一些討論和會議，也出版了一些書籍和論文，但是還沒有成形的方法對這一領(lǐng)域來進行系統(tǒng)地闡述。提供這樣一本主要反映個人觀點的小書看來是合適的。雖然我原來從事計算機科學的編程方面的工作，但是在1956—1963年，自動控制程序和高級語言編譯器開發(fā)出來的時候，我主要參加的是硬件構(gòu)架方面的工作。1964年，我成為操作系統(tǒng)OS/360的經(jīng)理，我發(fā)現(xiàn)前些年的進展使編程世界改變了很多。雖然是失敗的，但管理OS/360的開發(fā)仍是一次很有幫助的經(jīng)歷。負責這次開發(fā)項目的團隊，包括我的繼任經(jīng)理F.M.Trapnell，有很多值得自豪的東西。該系統(tǒng)在設(shè)計和執(zhí)行方面都很出色，并被成功地應(yīng)用到很多領(lǐng)域，特別是設(shè)備獨立的輸入輸出和外部庫管理，在很多技術(shù)革新中被廣泛復(fù)制�，F(xiàn)在，這一系統(tǒng)是十分可靠的，相當有效且非常通用。但是，并不是所有的努力都是成功的。所有OS/360的用戶很快就能發(fā)現(xiàn)它應(yīng)該能夠做得更好。設(shè)計和執(zhí)行上的缺陷在控制程序中特別普遍，相比之下，語言編譯器就好得多。大多數(shù)缺陷發(fā)生在1964—1965年的設(shè)計階段，所以這肯定是我的責任。此外，這個產(chǎn)品發(fā)布推遲了，需要的內(nèi)存比計劃中的要多，成本也是估計的好幾倍，而且第一次發(fā)布時并不能很好地運行，直到發(fā)布了幾次以后，問題才得以解決。按照當初接受OS/360任務(wù)時的協(xié)議，在1965年離開IBM后，我來到ChapelHill。我開始分析OS/360的經(jīng)驗，看能不能從中學到什么管理和技術(shù)上的教訓。特別要說明的是，System/360硬件開發(fā)和OS/360軟件開發(fā)中的管理經(jīng)驗是大相徑庭的。對TomWatson關(guān)于為什么編程難以管理的探索性問題，這本書是一份遲來的答案。在這次探索中，我和1964—1965年的經(jīng)理助理R.P.Case，還有1965—1968年的經(jīng)理F.M.Trapnell進行了長談，從中受益很多。我還對比了其他大型編程項目經(jīng)理的結(jié)論，這些項目經(jīng)理包括我唯一一本讀過一遍以上的書，是FredBrooks的《人月神話》，實際上我每過一兩年都會重讀一遍。部分原因是這本書文筆很好，另外就是書中的忠告很有價值，即使是在25年以后。當然，很多細節(jié)上的地方與我們做事情的方法有所不同。我們的工作更自動化，計算機的“馬力”更強勁，但書中依然有許多好的忠告，因此，我非常推崇這本書。這是我唯一能想起來的能從中體會到樂趣和思想的計算機科學書籍。
——BrianKernighan，名著《C程序設(shè)計語言》的合著者之一(與DennisM.Ritchie合作)
(《人月神話》)仍然是計算機書籍中被引用次數(shù)最多的書籍，而且即便本書最初出版于1975年，其內(nèi)容至今仍未過時。在閱讀的時候，每隔幾頁不說一句“對極了”是很難受的。
——SteveMcConnell，Construx公司首席軟件工程師，名著《代碼大全》、《快速軟件開發(fā)》的作者
這是一本經(jīng)典著作，與軟件開發(fā)有關(guān)的每一個人都應(yīng)該不止一遍地讀這本書。我唯一一本讀過一遍以上的書，是FredBrooks的《人月神話》，實際上我每過一兩年都會重讀一遍。部分原因是這本書文筆很好，另外就是書中的忠告很有價值，即使是在25年以后。當然，很多細節(jié)上的地方與我們做事情的方法有所不同。我們的工作更自動化，計算機的“馬力”更強勁，但書中依然有許多好的忠告，因此，我非常推崇這本書。這是我唯一能想起來的能從中體會到樂趣和思想的計算機科學書籍。——BrianKernighan，名著《C程序設(shè)計語言》的合著者之一(與DennisM.Ritchie合作)(《人月神話》)仍然是計算機書籍中被引用次數(shù)最多的書籍，而且即便本書最初出版于1975年，其內(nèi)容至今仍未過時。在閱讀的時候，每隔幾頁不說一句“對極了”是很難受的。——SteveMcConnell，Construx公司首席軟件工程師，名著《代碼大全》、《快速軟件開發(fā)》的作者這是一本經(jīng)典著作，與軟件開發(fā)有關(guān)的每一個人都應(yīng)該不止一遍地讀這本書。——PhilippeKruchten，Rational統(tǒng)一過程首席架構(gòu)師史前史中，沒有別的場景比巨獸們在焦油坑中垂死掙扎的場面更令人震撼。上帝見證著恐龍、猛犸象、劍齒虎在焦油中掙扎。它們掙扎得越猛烈，焦油糾纏得就越緊，沒有哪種猛獸足夠強壯或具有足夠的技巧，能夠掙脫束縛，它們最后都沉到了坑底。過去幾十年的大型系統(tǒng)開發(fā)就猶如這樣一個焦油坑，很多大型和強壯的動物在其中劇烈地掙扎。他們中大多數(shù)開發(fā)出了可運行的系統(tǒng)——不過只有極少數(shù)的項目滿足了目標、進度和預(yù)算的要求。各種團隊，大型的或小型的，龐雜的或精干的，一個接一個地淹沒在了焦油坑中。表面上看起來好像沒有任何一個單獨的問題會導致困難，每個問題都能獲得解決，但是當它們相互糾纏和累積在一起的時候，團隊的行動就會變得越來越慢。對于問題的麻煩程度，每個人似乎都會感到驚訝，并且很難看清問題的本質(zhì)。不過，如果我們想解決問題，就必須試圖先去了解問題。因此，首先讓我們來認識一下系統(tǒng)開發(fā)這個職業(yè)，以及充滿在這個職業(yè)中的樂趣和苦惱吧！編程系統(tǒng)產(chǎn)品報紙上經(jīng)常會出現(xiàn)這樣的新聞，講述兩個程序員如何在經(jīng)過改造的簡陋車庫中，編出超過大型團隊工作量的重要程序。接著，每個編程人員準備相信這樣的神話，因為他知道自己能以超過產(chǎn)業(yè)化團隊的1000代碼行/年的生產(chǎn)率來開發(fā)任何程序。為什么不是所有的產(chǎn)業(yè)化隊伍都會被這種專注的二人組合所替代？我們必須看一下產(chǎn)出的是什么。圖1-1的左上部分是程序(Program)。它本身是完整的，可以由作者在所開發(fā)的系統(tǒng)平臺上運行。它通常是車庫中產(chǎn)出的產(chǎn)品，以及作為單個程序員生產(chǎn)率的評估標準。圖1-1編程系統(tǒng)產(chǎn)品的演進有兩種途徑可以使程序轉(zhuǎn)變成更有用但是成本更高的產(chǎn)物，這兩種途徑表現(xiàn)為圖中的邊界。水平邊界以下，程序轉(zhuǎn)變成編程產(chǎn)品(ProgrammingProduct)。這是可以被任何人運行、測試、修復(fù)和擴展的程序。它可以在多種操作系統(tǒng)平臺上運行，供多套數(shù)據(jù)使用。要成為通用的編程產(chǎn)品，程序必須按照普遍認可的風格來編寫，特別是輸入的范圍和形式必須廣泛地適用于所有可以合理使用的基本算法。接著，對程序進行徹底測試，確保它的穩(wěn)定性和可靠性，使其值得信賴。這就意味著必須準備、運行和記錄詳盡的測試用例庫，用來檢查輸入的邊界和范圍。此外，要將程序提升為程序產(chǎn)品，還需要有完備的文檔，每個人都可以加以使用、修復(fù)和擴展。經(jīng)驗數(shù)據(jù)表明，相同功能的編程產(chǎn)品的成本，至少是已調(diào)試的程序的成本的3倍。回到圖中，垂直邊界的右邊，程序轉(zhuǎn)變成編程系統(tǒng)(ProgrammingSystem)中的一個構(gòu)件單元。它是在功能上能相互協(xié)作、具有規(guī)范的格式、可以進行交互的程序集合，并可以用來組裝和搭建整個系統(tǒng)。要成為編程系統(tǒng)構(gòu)件，程序必須按照一定的要求編制，使輸入和輸出在語法和語義上與精確定義的接口一致。同時程序還要符合預(yù)先定義的資源限制——內(nèi)存空間、輸入輸出設(shè)備、計算機時間。最后，程序必須同其他系統(tǒng)構(gòu)件單元一道，以任何能想象到的組合進行測試。由于測試用例會隨著組合不斷增加，所以測試的范圍必須廣泛。因為一些意想不到的交互會產(chǎn)生許多不易察覺的bug，測試工作將會非常耗時，因此相同功能的編程系統(tǒng)構(gòu)件的成本至少是獨立程序的3倍。如果系統(tǒng)有大量的組成單元，成本還會更高。圖1-1的右下部分代表編程系統(tǒng)產(chǎn)品(ProgrammingSystemsProduct)。與以上的所有的簡單的程序都不同的是，它的成本高達9倍。然而，只有它才是真正有用的產(chǎn)品，是大多數(shù)系統(tǒng)開發(fā)的目標。職業(yè)的樂趣編程為什么有趣？作為回報，它的從業(yè)者期望得到什么樣的快樂？首先，這種快樂是一種創(chuàng)建事物的純粹快樂。如同小孩在玩泥巴時感到快樂一樣，成年人喜歡創(chuàng)建事物，特別是自己進行設(shè)計。我想這種快樂是上帝創(chuàng)造世界的折射，一種呈現(xiàn)在每片獨特的、嶄新的樹葉和雪花上的喜悅。其次，這種快樂來自于開發(fā)對他人有用的東西。內(nèi)心深處，我們期望我們的勞動成果能夠被他人使用，并能對他們有所幫助。從這一角度而言，這同小孩用粘土為“爸爸的辦公室”捏制鉛筆盒沒有任何本質(zhì)的區(qū)別。第三，快樂來自于整個過程體現(xiàn)出的一股強大的魅力——將相互嚙合的零部件組裝在一起，看到它們以精妙的方式運行著，并收到了預(yù)期的效果。比起彈球游戲機或自動電唱機所具有的迷人魅力，程序化的計算機毫不遜色。第四，這種快樂是持續(xù)學習的快樂，它來自于這項工作的非重復(fù)特性。人們所面臨的問題總有這樣那樣的不同，因而解決問題的人可以從中學習新的事物，有時是實踐上的，有時是理論上的，或者兼而有之。最后，這種快樂還來自于在易于駕馭的介質(zhì)上工作。程序員，就像詩人一樣，幾乎僅僅在單純的思考中工作。程序員憑空地運用自己的想象，來建造自己的“城堡”。很少有創(chuàng)造介質(zhì)如此靈活，如此易于精煉和重建，如此容易實現(xiàn)概念上的設(shè)想(不過我們將會看到，容易駕馭的特性也有它自己的問題)。然而程序畢竟同詩歌不同，它是實實在在的東西；它可以移動和運行，能獨立產(chǎn)生可見的輸出；它能打印結(jié)果，繪制圖形，發(fā)出聲音，移動支架。神話和傳說中的魔術(shù)在我們的時代已變成現(xiàn)實。在鍵盤上鍵入正確的咒語，屏幕會活動、變幻，顯示出前所未有的也不可能存在的事物。編程的快樂在于它不僅滿足了我們內(nèi)心深處進行創(chuàng)造的渴望，而且還喚醒了每個人內(nèi)心的情感。
|
