第0章 軟體時間

作者迷戀於一個開放程式碼並可以由遊戲玩家更改程式的一個遊戲，併為在它的基礎上創新和增添一些功能而樂此不疲。

0代表程式設計師的思維方式，因為計算機從0開始計數。

"Hello World " 程式能夠喚醒每個程式設計師心中樂觀的一面。既然能叫它說話，就能讓它做任何事！

計算機器協會(The Association for Computing Machinery ), 維護了一張網頁，上面列出將近兩百種程式語言版本的"Hello World" 程式。簡直就是程式程式碼的羅塞塔石碑。

網頁地址：http://www2.latech.edu/~acm/HelloWorld.html

有興趣時可以看看。

為什麼就是不能像造橋那樣造軟體？

人類文明運行於軟體之上。軟體建立藝術卻隱於暗處，即便對於專家們也是如此。網際網路時間帶來了快速發展的技術產生、公司創立、創造財富等也同時帶來了程式的缺陷問題。而對軟體開發者來說，則過的是時快時慢：如果靈感到了，一切順利，則全然忘記時間，全心投入高速的開發之中。反之遇到瓶頸，則舉步維艱的軟體時間。軟體不能像建造橋樑那樣一勞永逸可以造福上百年。反而漏洞百出，麻煩不斷，錯誤不停。帶來無窮盡的改進和苦惱。

在現代軟體研究領域多有建樹的專家弗裡德里克·布魯克斯(Frederick Brooks) 在1987 年寫了一篇題為（ 沒有銀彈(No Silver Bullet )〉的著名論文。布魯克斯在論文中稱，無論編寫計算機程式是如何地令我們倍感挫敗，也永遠無法找到一種魔法般的突破－我們只能期待漸次前行。1/4個世紀過去了，銀彈仍然沒有發現。

第1章 死定了

一個錯誤就可能讓一個專案“死定了”。往往帶來不可知因素的時間陷阱。

記錄於Bugzilla 中的第44 個缺陷，最初於2003 年1 月19 日登記，描述資訊是“ 當修改窗體大小時出現閃爍”。。安德森認為這是個小問題，不過還是應該查實和修正。可直到將近六個月之後的今天，他仍然沒能修正。問題不在自己和同事編寫的程式碼上，出錯的根源在於一個稱作wxWidgets 的軟體裡面，Chandler 小組採用該軟體作為專案的構造塊。安德森要麼等著wxWidgets的開發者修正程式碼，要麼就得繞過問題所在。

軟體專案難以按進度安排實現，這種情況極為常見。在軟體開發的世界裡，進度延誤普遍到人們特意生造出—個委婉詞來描述它：slippage（失速）。

軟體時間自我扭曲再頭尾相接，如同莫比烏斯環。一般令人費解。進度忽而突飛猛進，忽而不知何故駐足道中。在你以為大功即將告成之時，卻又山窮水盡， 花上整半年時間，一無所得。

IBM System/360 主機作業系統是當時規模最大的軟體專案。那臺巨大而昂貴的大型計算機，本應是後來二十年中生意場上的中流礫柱，但它的孕育和誕生卻飽受延誤和成本超支之苦。正如布魯克斯所言，它變成了一個“瀝青坑”， 一個能粘住大企業的陷阱，哪怕對於IBM 這樣“孔武有力”的公司也不例外。

布魯克斯法則：

向已延誤的專案中補充人力，只會使其繼續延誤。

布魯克斯寫道，軟體開發者通常都是樂天派，他們認定每個缺陷都可以被迅速修正，且修正舊缺陷必能減少新缺陷的數量。

布魯克斯發現，在實際開發中，編碼只佔軟體專案開發時間的1/6, 有一半時間用於測試和修正缺陷。但只有少數專案經理會真正按照這種思路來安排開發人員的工作時間。

所謂“人月", 是一種科學管理概念，它假定生產力可被拆分為不連續、無差異、可替換的單元。

布魯克斯觀察到，“只有在任務能分派給許多互相之間無須溝通的工作者時，人和月才是可互換品。

“對於軟體而言，專案各有差異、工具不斷升級，每當團隊中加入一個新組員，老組員就得放下手邊的工作，幫助新組員進入角色，每位組員都要等待重新分派任務，好讓新組員有事可做。在你意識到這一切之前，已經遠遠落後於進度了。也就是說，每次重新安排進度計劃，都導致僱用更多人力，於是又不得不重新安排進度。

布魯克斯發現，製作軟體的大量工作受困於“序列約束＂，它限制了任務分解的程度：完成某項任務是處理其他任務的先決條件，這與人力投入多少無關。

布魯克斯法則暗示最理想的開發組規模是一個人——無須停下工作與同事溝通的單個開發者。一切均順序進行，確保專案維持布魯克斯所謂“概念上完整”的狀態· 專案中所有環節目標一致，且按計劃完美結合。

但是對於龐大且涉及面極廣的一個程式來說幾乎不可能。從理論上團隊開發就是不得不被認可的，何況實踐上它幾乎必不可少。

開放原始碼軟體開發(open source software development)，它能徹底改變軟體開發的具體過程——將其從少數隱士手裡拿出來，散播到廣大人群中。在它之前，軟體開發都採用大教堂模式。即“最重要的軟體……需要像建教堂一般，由獨立的
巫師或一隊相互隔離的魔法師精心打造，在面世之前絕不釋出beta 版本。”

開發原始碼開發方式（又叫開源集市）在一方面，低成本、廣泛地接入像網際網路那樣的網路， 讓開發者之間能建立迅速、可信的溝通渠道，儲存可
被開放訪問的共享知識和程式碼池；另一方面，圍繞一種領導方式——如託瓦茨那樣的方式——形成合作團隊的良好風氣，歡迎新人進入、鼓勵成員做出貢獻，同時儘可能增加合格成員。

開源運動的新集市模式在很多方面改變了計算世界，但說到能比大教堂模式更快地讓新產品面世，卻並無顯著建樹。

＂愉悅是金，“艾瑞克· 瑞蒙德寫道。“開源的成功告訴我們，對於創造性工作，玩耍是最經濟有效的模式。”

第2章 Agenda之魂

Chandler 專案並沒有真的“正在“改變世界（至少尚未開始）。但Chandler 專案正是為改變世界之夢所驅動。

卡普爾自己以及他的蓮花公司還有更多開發者對專案的執著與對災難的堅持。正是某種意義上的開發者的精神。

卡普爾（Mitchell Kapor）在接受戴維·甘斯的採訪時說過的一段話：

“在變成數字資本家之前，我曾教人超覺靜坐。，還在一家社群醫院的精神科做過心理諮詢師，這些經歷對我影響極深。我擁有心
理諮詢的碩士學位。所以，我另有志趣。我只是誤入計算機領域，無意成為比爾·蓋茨——只有比爾·蓋茨才能做比爾·蓋茨。我向來不求做大公司、賺大錢。我只是辦了家叫做蓮花的小公司， 做了個幾百萬人爭相購買的軟體產品，結果這家小公司陡然暴長，員工數千，每年收入數億美元。很不爽。至少對我個人來說，很不爽。所以我離開了。在某一天，我離開了。”

蓮花公司有個叫做Agenda 的專案，為了解決卡普爾的小紙片問題而設立。即採用計算機人工智慧來管理記錄資訊的小紙片——名片、隨手貼、筆記頁等。蓮花公司於1988 年釋出了Agenda 軟體。

Agenda的“自動分派”特性一一在意義模糊的短語裡面，如“ 下週五與約翰共進午餐"'找出“下週五”這個曰子——如同魔法一般，沒有其他軟體能與之媲美。它還引入了一種管理資料的新手段——介於傳統計算機資料庫的嚴格結構和字處理軟體的自由格式之間。

Agenda的建立者們認定這樣一些超乎常規的原則：使用者不用關心軟體的儲存結構，只管輸入資料就好，使用者應該能夠容易地擴充套件和修改資料結構、新增新分類， 且不會導致資料丟失，使用者應該能夠用自己建立的新方式檢視資料——也可以在自己建立的檢視中操作和修改資料。

在當時，程式或網站總是要你按它設定的方式而不是你自己的方式填空——社會保險號碼裡面不得包括連字元！信用卡號中不得包括空格！——而Agenda 早有獨門祕技讓使用者隨意輸入。

卡普爾離開蓮花公司後，投身於開創開放網路的工作。但他放不下Agenda。他珍視的並非Agenda 的“特性列表”——軟體的種種特殊功能一一而是動態適應性的程式精髓，即“先扔進去，延後處理”。於是，Chandler專案誕生了。

關於Chandler，米奇.卡普爾只知道三個要素：它應當開源，它應當撓到Exchange 的癢處，它應當承繼Agenda 之精髓。

滑鼠之父道格拉斯·恩格巴特( Douglas Engelhart ) 的"oNLine System (線上系統， NLS)" 就是—種PIM（personal information manager） 。NLS 的目標是讓使用者能夠“儲存並研究想法，使之相互關聯，並能交叉引用”。

現在的計算機使用者大概會把這叫做outliner (大綱工具）——以可摺疊和展開的節點對資訊行進行層級結構化組織的程式。但NLS 可以在網路上共享，而不僅限於單機使用。

在1962 年關於增進人類智慧研究計劃的論文中，恩格巴特闡述了程式設計師最有可能成為初期目標使用者的原因。“成果也可用千智慧增進研究專案自身，改進研究和開發智慧增進系統程式設計活動的效能。設計、實現和修改程式的能力，在衡量研究進展時頗為重要。”

若NLS 能幫助程式設計師更好地程式設計，則程式設計師就能更快地改進NLS。這就出現了正向迴圈。這就是“提靴帶(bootstrapping)" 。

在恩格巴特看來，提靴帶(bootstrapping)的意思是“讓改進的過程得到改進”。提靴帶(bootstrapping)並不改進過程——如讓人更快地解決問題。它改進的是改進過程的速率一一如怎樣才能快速教會他人更快地解決問題。

初次啟動計算機時，記憶體是空的。這就造成了雞與蛋的悖論：計算機硬體需要作業系統軟體來裝載程式——包括作業系統本身

計算機系統發明者們通過一個叫做"bootstrap loader (靴帶裝載者，載入程式）”的小程式讓機器具備剛好足夠把大作業系統裝入記憶體的能力，開始正常執行。

米奇· 卡普爾總把恩格巴特作為自己的靈感之源，而Agenda 在某種意義上則是NLS的傳承者。

之後，本章介紹了很多個失敗的專案，這些專案失敗的原因都是因為專案需求不斷地變化。用一句話來概括就是：標靶移來移去。目的忽上忽下。計劃不切實際。期限一拖再拖。預算膨脹超支。絕望已極。混亂不堪。

第3章 原型與Python

卡普爾的團隊開始問自己一個看似簡單的問題：我們如何組織資訊？如何對這種資訊組織法建模——需要怎樣的資料結構才能讓
計算機也能回答這個問題？

軟體沒有磁芯。它就像洋蔥般層層疊疊，每一層都辛辛苦苦地建立於前一層基礎之上。程式設計師把這種結構叫做“抽象層疊＂，每當新添一層時，就要把一些複雜而特殊的東西轉換為簡單而通用的東西。在抽象層疊的最底端， 正好在核心記憶體之上的部分就是組合語言。

語言的選擇可能都是一個專案在前期選擇時必須要經歷的痛苦抉擇。文中談到了彙編、Fortran、C、Perl，談到了編譯型語言和解釋型語言，最後專案用Python語言來實現。

Python 是一種“解釋型語言(interpreted language)" 。“編譯型語言(compiled language)" 通過編譯器先將程式設計師的原始碼翻譯為機器可讀的二進位制程式碼後再執行，而解釋型語言則是在執行時做類似的工作——直譯器逐行翻譯原始碼，再餵給處理器執行。解釋型語言效率較差，因為你要同時執行自己的程式和直譯器。但這也使得解釋型語言較為敏捷。

Python是解釋型語言，但是簡單易懂的語言，很明顯在修改錯誤和拓展程式上事半功倍。這恰恰說明了，解釋型語言這種往往被忽略的“指令碼語言”是至關重要的。很多語言都用括號或其他符號來劃分程式碼塊，而Python 卻只簡單地用縮排表示。它的另一個優點是變數型別設定寬鬆。

Python 的信條，範·羅薩姆說，是TOOWTDI: There's only way to do it. (僅此一途。)

Python和Java語言一樣提供了“垃圾回收(garbage collection)"機制。當程式不再需要先前申請的記憶體空間， Python 就會負責清理。

面向物件技術不是圍繞一系列命令列來組織程式，而是基於一些叫做物件的程式碼片段來組織程式。當接收到其他物件的呼叫時，物件就會做出操作。物件之間通過嚴格定義的輸入輸出彼此相關。軟體物件通過互相之間發“訊息(message)" 來觸發”事件(event)",達到互動的目的。共享特性物件可以組建為“類(class)", 還可以從“父類(parent)" 繼承特性。

語義網基於一種名為RDF(Resource Description Framework , 資源描述框架）的技術。RDF 以“ 三元組(triples)" ——包括三個部分的語句——儲存所有資訊，描述事物之間的關係。

電梯遊說：就是當你有幸在電梯間遇到某位權錢人士時，能脫口而出，在短時間內說服他。

第4章 樂高王國

這一章主要描述樂高積木式的軟體製作方式，如果這一塊塊積木是程式程式碼，則很難做到盡善盡美，完全適用且精簡的程式碼。最終這個方式是卡塞爾團隊在這方面的一個嘗試探索，值得我們欽佩和敬仰。

樂高假設指未來程式將由可複用的部件組合而成。部件將在全球範圍內提供。雖然實際上這種假設不太容易實現，甚至不能實現。做好專案的關鍵在於複用，而不是重複發明。把前人的成功經驗整合進來，少寫新程式碼。軟體複用的兩難選擇：建立還是借用？

可複用軟體之夢有一個悖論：幾乎總能找到一段滿足大部分需要的程式碼。但這些拿來的程式碼所不能做到的部分，恰恰是專案與眾不同的創新之處----也是建立這個專案的出發點。

模組化和元件化是軟體人員的夢想，誰都想把幾個模組插到一起就可以完美的執行並完成任務，但現實卻相當殘酷，可以執行的模組通常不能與自己想寫的程式配合工作。程式設計師們很久前就解決了“小複用”問題，即通過構建子程式庫來為自己減負。但一直懸而未決的間題則是“大複用”——創造並使用真正有用的軟體大型可複用元件。

書中提到一個叫考克斯的人，他創辦了一家叫做Stepstone的公司，致力於向C語言系統搭造者提供插入式晶片級軟體元件，最後的結論是：壞訊息是這次試驗顯示，即便採用最新的技術，要想設計和製造既有用又真能複用的元件、為元件寫文件以便於客戶理解、移植元件到潮水般不斷湧現的新硬體平臺上、確保最新的改進或釋出版本不與現存介面衝突、將元件銷售到類似威廉姆斯堡槍械行業那種鼓勵從頭做起的價值體系，都是極其困難的。

美國西海岸時間2003 年4月21 日下午3:07, 第一個公眾版Chandler0.1上載到OSAF 伺服器。24 小時內，就被下載15000 次。卡普爾在blog 上寫道“我把Chandler0.1叫做‘B超’版本：胎兒只能在母腹中存活，但如果仔細檢視，就能看到小小的手臂和腿腳在劃
動，你會相信最終它將誕生。”

接下來，團隊討論後認為Chandler資料模型的核心應該是“條目( item)”。什麼都可以是條目——對使用者來說，可能是一封電子郵件、一條隨筆記錄或者一次約會事件，但它也要體現程式自身的一些機制，例如某”類”條目的定義("電子郵件”或“隨筆記錄”或“約會事件")。條目採用的面向物件方式加以組織，構成一種繼承層級結構。如果一組中的每一條目都被定義為某一”類”——例如，都是電子郵件一一則它們將繼承“電子郵件類”條目的所有特性。所有條目都應該儲存在資料庫中。

這種方案讓Chandler 具有“以條目為中心”的特點，它還引申出幾個要點。其中之一是程式徹底從RDF 的世界中轉移出來，回到摩根·薩奇編寫第一個資料庫時Chandler 的出生地。在RDF 中，資料儲存的基本單位是“屬性(attribute)" ; Chandler 條目可以包含許多不同屬性（對於一封電子郵件，典型的屬性可能是“日期”、“發件人”、“ 主題”、“正文”等等）。

現在，Chandler 團隊終於回到有所進展的世界。

第5章 管束奇客和狗

從狗的需要管束引論到程式設計師需要管束。工程的質量、進度、成本也需要進行策劃決策。

質量三角，既好、又快、還便宜，同時滿足的事情不太可能發生。

軟體經理非常重要，他制定進度、推動程式設計師按進度工作、決定先幹什麼後幹什麼，需要溝通能力、決策能力、市場感知能力、粘合團隊能力、程式掌控能力等等。總的來說就是軟體專案的管理者和決策者是非常重要且任務艱鉅的。

用程式碼行數做判斷標準只會鼓勵程式設計師寫臃腫、蹩腳的程式碼。

閒逛式管理MBWA(Management by wandering around)：這種嚴密的方法要求經理們走出辦公室，遍訪坐在隔間裡的下屬，和他們談話。“做得怎樣了？”它鼓勵人們觀察和接觸他人。

但在軟體領域開發進度是閒逛的管理人員看不到的，因此不能移植到軟體領域中。

多數開發者都樂意告訴經理自己的進度，問題是，就目前的軟體實踐而言，開發者們對於自己的進度也不比經理知道得多。

奇客的2種定義：

以（計算機）程式缺陷為食----不善社交、身有惡臭、面色蒼白的偏執狂，具有乳酪刨絲器一般的人格特點。

專注於己事的人；追求技術（特別是專業技術）和夢想、不融入主流社會的人。

群件(Groupware)：即時通訊、聊天室、缺陷跟蹤、源藉故傳統的郵件列表等工具，個人感覺要慎用這些工具，否則你的工作時間會被這些工具吃得一乾二淨。

Wiki在chandler專案中也建立了起來，感覺這個chandler專案用到的工具太多，如果程式設計師不能合理地安排自己的時間，估計會被這些工具所淹沒。

對於程式設計師來說，確實有一種製造工具的衝動。磨刀不誤砍柴功本身沒錯，但程式設計師在磨刀的過程中會想弄到一塊最好的石頭，並花了大把的時間去把刀磨得吹毛斷髮，卻忘了還要砍柴。

第6章 搞掂設計方案

卡普爾認為， 軟體設計不僅只是在程式設計師程式碼之上覆蓋一層誘人的圖形。它是一種設想使用者需求並在軟體結構中滿足這些需求的創造性基礎工作。

良好設計的原則：堅固--良好的結構、沒有缺陷；適用--程式應符合其設定目標之所需；愉悅--使用程式的體驗應令人愉快。設計方案與實際過程沒有先後，而是相輔相成，同期發展。

在軟體世界中，整合(integration ) 的意思就是把一段執行正常的程式碼連線到某個程式中另一段執行正常的程式碼上。整合往往是軟體專案遇到大麻煩的環節。分開來執行相當正常的程式碼， 在合起來時就鬧罷工：不能正確掛接、傳送不可解釋的訊息、或者頑固地拒絕啟動或停止。

現今的多數專案都接納了“持續整合”的觀念：程式設計師不斷向主幹程式碼中籤入最新的程式碼，每個人負責確保自己加進去的程式碼不會導致問題發生。持續整合應該更利於產品的定期釋出。

戴維·艾倫是一位生產力教練，其著作《GettingThings Done》一書在程式設計師人群中近乎聖典。

GTD 的核心原則之一是建議有規律地安排定量時間處理收件箱：檢視胡亂塞進系統的每個位元填料並做出決定，“下一步怎麼處理這東西？＂艾倫建議，如果在兩分鐘之內就能處理好， 馬上就開始做。否則， 決定是存檔、丟棄、推遲， 或者分類到某個有下一步操作建議的具體專案中。

關於Linux的作者李納斯托瓦茨的話：

別做大專案。從小專案開始，而且永遠不要期望它變大。如果這麼想（指做大型軟體），就會做過度設計，把它想象行過於重要。更壞的情況是，你可能會被自己想象中的艱難工作所嚇倒。所以要從小處起步，著力考慮細節。別去想大圖景和好設計。如果專案沒解決某些需求，多半就是被過度設計了。

別指望在短時間內達到大成就，我致力於Linux達13年之久，我想後面還得花上好些時間。如果一早就妄想做個大東西，可能現在還沒動手呢。

第7章 細節檢視

程式設計師和機器、程式設計師和程式設計師、程式設計師和使用者之間往往達不到某種共識。

程式設計師們對於資訊的需求顯而易見。他們需要細節。他們需要藍圖。他們需要規格說明（specifications)。

規格說明是程式設計師的聖經，而且，通常程式設計師也會是忠誠信徒：規格說明就是法律。

需求搞錯的嚴重後果，18英尺的巨石拱門變成了18英寸的石樁子。

最著名也最聲名狼藉的匈牙利命名法：在匈牙利語標記法中，程式設計師給每個變數名加上字首， 好讓程式碼閱讀者瞭解變數的型別。

匈牙利命名法可能在用C++寫Windows程式的時代是需要，因為各種型別、結構、列舉、控制元件等等讓人眼花繚亂，讓人容易出錯，而在Java和C#等這種強型別的語言中，這類命名法完全是對程式設計師審美觀的踐踏。

第8章 白板上的即時貼

獲得更好進展的關鍵是將軟體改進到程式設計師自己可以使用的程度。

白板上的即時貼：用貼紙，每張紙表示大致同等的工作量。每張即時貼代表但各開發者一個月或兩個月的工作時間。先在牆上循“點號版本”的順序貼上，然後就能對每一輪計劃的工作和自己是否脫離顯示一目瞭然。用貼紙法來討論專案各個小版本應該具有的功能特性，也是敏捷開發裡重點推廣的。

“吃你自己的狗食”的意思是開發者必須使用自己正在做的產品。在傳奇般的施樂帕羅· 阿爾託研究中心(20 世紀70 年代發明了現代個人計算技術），研究隊伍領導人鮑勃· 泰勒提出了這種說法：“吃狗食則是迫使開發者把鼻子伸到產品的問題中、加速發現和修正缺陷的低調且實用的方法。”

WebDAV 的工作機制是擴充套件HTTP——Web 伺服器和瀏覽器之間賴以互相通訊的協議——增加了讓使用者在遠端伺服器上編輯檔案的新命令。

Chandler一直具有兩面性——一方面，它是使用者管理資訊的軟體應用；另一方面，它是—種“應用框架”或“平臺”一開發者可在上面新增新酷特性的一種基礎。由於卡普爾和OSAF 團隊逐漸勉強接受了不能兩者得兼的事實，他們首先選擇做應用程式。

第9章 方法

從Chandler 專案的最早期開始，卡普爾就堅持要做誠實、現實的計劃和進度安排。但專案在滿足進度方面卻擁有不佳的記錄：平均6個月能釋出一個版本，但計劃卻總假設應在3 、4 個月內完成一個版本。部分原因或許是在軟體開發和其他領域中計劃總是超出了能預見的範圍。
Chandler專案的軟體開發者很少成組地共同開發一系列專案：他們不太像運動隊或是軍隊單位，也不太像合唱團，而更像是專才們為製作一部電影而臨時組合然後解散，再重新為下一部電影組合起來。每次到新團隊中開始做新專案時，他們大概還是會按下”重置”按鈕， 根據某些首要原則設計出一套新的工作流程。

結構化程式設計的主要規則：“程式的每一層都該自成一體。”

為了擺脫軟體製作的焦油坑，無數軟體實行者在不斷探索。只有個體開發者為個人工作制定計劃並遵循，專案才有控制和管理的基礎。想法是好的，但往往很少有人將之付諸於行動。軟體的速度和質量造成人月神話的惡性迴圈，但是質量是保證軟體繼續發展的前提。

漢弗裡在IBM 執行強制進度紀律的成功基於兩條原則：

計劃是強制性的；

計劃必須符合現實情況——“從底向上”，依據那些負責按計劃執行的程式設計師的經驗和知識而來，而不是“從頂至下”，靠管理者拍腦袋或對市場的期望而來。

漢弗裡後來加入了卡耐基·梅隆大學軟體工程學院(Software Engineering Institute, SEI)。 在SEI，漢弗裡和同事們建立了軟體成熟度模型(Capability Maturity Model, CMM ), 作為一種衡量軟體開發組織品質的準繩。

CMM 原則的簡單的概述：

“位於第一級的組織基本上什麼都沒做。第二級組織做一些計劃、跟蹤、配置管理工作，也討論質量保證之類的話題。第三級
組織開始定義過程——如何工作、如何完成任務、可訓練的事項等。在第四級，他們採用衡量準繩。他們有一套真正跟蹤和管理自己所做工作的框架， 一種可統計跟蹤的系統。第五級組織擁有持續改進的過程。”

CMM主要目的是幫助規模龐大的組織改進軟體進度和質量。

模式運動讓個體程式設計師有了一條解決問題的新路子，並且提煉經驗、供同事所用。但它並不太有助於找到在更大專案中協調工作的方法。

瀑布模型：

將專案切分為依序進行的多個獨立階段，比如需求定義、設計、實現、整合、測試和釋出。每個階段需在下一階段開始前完成。

這套做法在紙上看似合乎邏輯，但實踐起來卻總是導致延誤、混亂和災難。每個階段都耗時無算，但沒一個工作正常的。“大設計優先”引發大延誤，“大爆炸式整合“一一單獨編寫程式碼的各個主要部分，在專案將近結束時拼到一起——導致系統崩潰。

螺旋模型：

將開發切割為六個月到兩年的“迭代週期”——更快生產出可工作程式碼的小瀑布，從部分完成的產品使用中得到反饋、指導下一步迭代。

快速應用開發(Rapid Application Development)：

RAD承諾通過快速原型設計和更緊迫的迭代週期，依靠新工具讓計算機處理一些繁重的程式設計工作，加速完成軟體的交付。RAD 幫助軟體公司更敏捷地工作。

敏捷軟體開發(Agile Software Development)：

我們正通過實踐和幫助他人來揭示開發軟體的更好方法。經由這項工作，我們估量：

個體和互動勝於過程和工具

可工作的軟體勝於面面俱到的文件

客戶協作勝於合同談判

響應需求勝於遵循計劃

即，儘管右欄條目有其價值，但我們更看重左欄條目。

爭球式開發(Scrum)：將專案分解為30 天一輪的“競跑"'強調每天開例會、維持專案在正軌上運轉。

極限程式設計：採用了一系列廣為接受的方法，並將這些方法的使用推至極限。

索伯斯基提出了祖爾測試( Joel Test)，基於他自己的經驗和“集體智慧＂，給出一套快餐式原則， 判斷開發組織是否符合這條原則—— “不會叫人頭疼的CMM”。

祖爾測試詢問以下十二個問題：

1）Do you use source control?      你們使用原始碼控制嗎？

2）Can you make a build in one step?     你們一步就能完成構建嗎？

3）Do you make daily builds?    你們做每日構建嗎？

4）Do you have a bug database?     你們有缺陷資料庫嗎？

5）Do you fix bugs before writing new code?     你們會在寫新程式碼之前修復缺陷嗎？

6）Do you have an up-to-date schedule?     你們有與當前工作吻合的進度安排嗎？

7）Do you have a spec?    你們有規約嗎？

8）Do programmers have quiet working conditions?    程式設計師工作環境安靜嗎？

9）Do you use the best tools money can buy?    你們採用了市面上最好工具嗎？

10）Do you have testers?   你們有測試人員嗎？

11）Do new candidates write code during their interview?    你們會要求應聘者在面試時寫程式碼嗎？

12）Do you do hallway usability testing?    你們做走廊可用性測試嗎？

“得12分為最佳，“索伯斯基寫道， "11分還可以接受，得10分或更低就說明你們問題大了。其實多數軟體組織只能得2、3分，他們迫切需要幫助，因為微軟等公司一直都得12 分。"

第10章 工程師和藝術家

軟體設計有兩個意思：“其一是我們要打造的產品。其二是讓產品得以實現的軟體工程。我相信有兩種不同的角色一一主題專家和軟體工程師。”

延後繫結是電腦科學中的—個術語，表示程式語言提供給程式設計師以更多靈活性的能力。

興趣決定了程式設計是工程師的工作還是藝術家熱愛的作品，為之創新和廢寢忘食的魔力。培養興趣對學習者很重要，而堅持興趣對工程師很重要。

在計算領域中，變化不可避免，我們設計的系統應該讓我們從變化中學習、並且反過來影響變化。在PARC 時，我們的理念就是，既然你永遠不會踏入同一條河流，使用者介面的第一要素是一種學習環境——可以從不同途徑探索，隨使用者使用該環境的時間程序不斷改變。“換言之，使用者從計算機處學到新東西后，就能自己修改系統，以期發揮所學。

高德納寫的書名叫《計算機程式設計藝術》，他在1984年獲得圖靈獎時發表感言說，“計算機程式設計是門藝術”。寫《計算機程式設計藝術》這本書他花了十年，寫TeX和metafont程式沒想到也花了近10年。他宣稱，寫軟體要比寫書“難多了”。

第11章 通往狗食版之路

“吃你自己的狗食”的意思是開發者必須使用自己正在做的產品。在傳奇般的施樂帕羅· 阿爾託研究中心(20 世紀70 年代發明了現代個人計算技術），研究隊伍領導人鮑勃· 泰勒提出了這種說法：“吃狗食則是迫使開發者把鼻子伸到產品的問題中、加速發現和修正缺陷的低調且實用的方法。”

吃自己的狗糧，這種思路確實有助於提升軟體質量和使用者體驗，想想連自己都不屑一用的軟體憑什麼去折磨使用者呢？

軟體中的遞迴很危險，因為它必須要有出口。否則，奇異迴圈就會變作無限迴圈，而計算機就會堆疊溢位。終結條件是遞迴定義中最重要的部分。