我的作品的常客讀者可能知道，我對於使用其他專業的隱喻來推論軟體開發非常懷疑。特別是，我相信工程隱喻對我們這個專業造成傷害 - 因為它鼓勵了將設計與建構分開的概念。

當我在倫敦辦公室閒晃時，這個問題在精實製造的脈絡中出現，精實製造是一個在敏捷圈中經常使用的隱喻 - 特別是Poppendiecks。如果我不喜歡土木工程的隱喻式推論，我是否會更喜歡精實製造的隱喻式推論？

大多數版本控制系統仰賴使用和理解人工製品不同版本之間的變更 - 通常稱為 Unix 中可以產生這些變更的指令中的差異。對於文字和二進位檔案，都有不錯的差異（和合併）演算法。這些差異的問題在於它們相當愚蠢。它們所做的就是查看兩個人工製品版本，並產生從一個版本到另一個版本的簡單方法。

我們最近進行了年度潛水假期。每當我們這麼做時，我們都會面臨一個兩難：我們要去我們非常喜愛的薩巴，還是嘗試新的地方？我們對此的答案是去薩巴和一個新地方，這導致了一個較長的假期，彌補了從寒冷的東北出發的漫長旅程。我們的新地方是多米尼克。

作為一個一直使用版本控制的人，我認為它可以擴展到更多電腦使用領域。除了軟體開發人員之外，很少有電腦使用者使用版本控制。然而，正如軟體開發人員所知，版本控制是一個很棒的協作工作機制，允許多人共同作業於單一軟體系統。版本控制更廣泛使用的優點是什麼？

Sergey Dmitriev 是 JetBrains 的領導人之一，他們提供給我們 IntelliJ Idea 和 ReSharper 等許多很棒的工具。他最近發表了一篇 文章，說明他所進行的探索性開發，稱為元程式設計系統。他將此系統視為一個更廣泛運動的範例，他稱之為面向語言程式設計。

我參加 OOPSLA 已超過十年。它已成為我與許多朋友見面並了解他們最近在做什麼的地方，並試著了解 OO 社群的發展方向。

我的分散式物件設計第一定律：不要分散你的物件（來自 P of EAA）。

清楚的程式碼很好，但你應該為了可測試性而犧牲清楚嗎？

敏捷開發的基本原則之一是，需求變更不僅是預期，而且是受歡迎的。當外部公司（例如 Thoughtworks）為客戶工作時，這會帶來特別的挑戰。許多客戶想要一個 固定價格 安排，這實際上是固定範圍，因為他們看到 固定範圍迷思。但是固定範圍合約與敏捷開發完全相悖，那麼像我們這樣的公司該怎麼辦？

如果你一直在關注我的同事 ThoughtBloggers，你就會知道似乎 我的其中一個機器人燒毀了保險絲，澳洲的陽光顯然讓這些瑞典模型變得很脆弱。

Jon 對 資料傳輸物件 感到厭煩，但這並不是因為 DTO 是壞東西，就像任何模式一樣，它們在特定情況下是有用的。模式總是包含兩個部分：如何和何時。你不僅需要知道如何實作它們，還必須知道何時使用它們以及何時讓它們保持原狀。

當我聆聽我們的開發團隊討論他們的作業時，一個常見的主題是他們不喜歡靜態中所保存的事物。我們通常看到常見的服務或元件保存在具有靜態初始化項目的靜態變數中。靜態（在大部分語言中）的一項重大問題是您無法使用多型來以一個實作替換另一個實作。這對我們來說很麻煩，因為我們是測試的忠實愛好者，而要進行良好的測試，能夠以 服務 Stub 替換服務非常重要。

在 Debian 上安裝大部分事物都非常容易：apt-get install package-name。遺憾的是，Java 是個例外，因為它不在基本的 Debian 系統中。我最近在我的 Debian Sid 桌面上下載並安裝了 Java 1.5（或 5，或他們現在稱呼它的任何名稱）。簡而言之，程序如下。

許多公司喜歡撰寫固定範圍和價格的合約，因為他們認為這樣可以降低風險。幻覺表示他們的財務義務固定在交易價格上。如果他們沒有獲得令人滿意的軟體，那麼他們就不會花費成本。

由於對動態語言的興趣日益增加，越來越多的人接觸到一個稱為 Lambda（也稱為閉包、匿名函數或區塊）的程式設計概念。具有 C/C++/Java/C# 語言背景的人員沒有 Lambda，因此不確定它們是什麼。以下是一個簡短的說明，對於已經在具有 Lambda 的語言中進行大量程式設計的人員來說，不會覺得有趣。

Subversion 是開放原始碼版本控制系統，基本上是 CVS 的後繼者。它修正了 CVS 中最大的問題，引入了原子提交和支援檔案及目錄重新命名等功能。我已經使用它好幾年了，發現它非常穩定。

最近我聽說有人提出幾個問題，關於如何為使用極限程式規劃方法的多個團隊制定標準故事點數機制。希望所有團隊都能使用等效的故事點數，這樣一個團隊的三個故事點數的努力程度與另一個團隊相同。

我認為，盡力想出這個方法價值有限，而且最糟糕的是很危險。

幾個聖誕節前，辛蒂送我一個 麥哲倫 Meridian Gold GPS 裝置。由於我的導航能力比一般人好，所以我沒有把它視為真正需要，而把它當作玩具來玩。從那以後，我發現它更像是一個有趣的玩具，而不是我經常使用的東西。

以下是 Przemyslaw Pokrywka 提出的一個有趣的難題。在 書中 的重構之一是 引入 Null 物件 - 一個非常有用的重構（也在 Josh 的新書 中討論過。）Przemyslaw 的觀點是，這個重構可能會改變行為。如果你有一個方法傳回 null，而且你呼叫那個 null 上的方法，你會得到一個 null 指標例外。如果你使用 Null 物件，你會得到一些預設行為。

如果你做出一個變更來改善程式效能，這是否為重構？

變更宣告的順序是否為重構，例如 Java 程式中的方法和欄位？

最近在 重構郵件清單 上有一些討論，關於什麼是重構，什麼不是。與這些討論一樣，總是有爭論多少天使可以站在針尖上的危險，但思考邊界確實有一些有用的目的。

在我的 重構書 中，我給了重構幾個定義。

如果軟體要往南走，吉姆在這篇文章中解釋了為什麼它應該盡快崩潰。

我常收到問題，這些問題圍繞著 JUnit 測試架構中的一個設計選擇，也就是為每個測試方法執行建立一個新物件。足夠保證一個快速的 bliki 條目。（不過我幾乎不得不指出，我寫關於 JUnit 的文章並不表示我不認為其他形式的測試很重要。有很多有用的測試活動，儘管 JUnit 及其相關程式對許多活動來說很有價值，但它並非萬靈丹。對於更多關於測試的部落格，我建議你看看 Brett Pettichord、Brian Marick 和 James Bach 的部落格。你也不應該假設我寫關於 xUnit 測試的文章暗示重構、用例或使用牙線不重要。）

Cindy 非常注重木工中的精良做工。她會注意到我所忽略的各種精細細節。她特別欣賞那些看起來不起眼，但實際上做起來相當棘手的東西。

當你撰寫一個類別時，你主要努力確保該類別的功能對該類別有意義。但有時為類別新增一個功能是有意義的，以使類別符合它自然應該具備的更豐富介面。

我正在翻閱一些舊筆記，並發現 Rich Garzaniti 給我的簡單但有用的提示。

此頁面現已棄用，因為我不再認為它是有用的資訊來源。請前往 ActivityOriented 以獲得關於此主題的更佳說明

此頁面現已棄用，因為我不再認為它是有用的資訊來源。請前往 OutcomeOriented 以獲得關於此主題的更佳說明

此頁面現已棄用，因為我不再認為它是有用的資訊來源。請前往 BusinessCapabilityCentric 以獲得關於此主題的更佳說明

有很多原因讓我安心在 Thoughtworks 工作，其中很大一部分原因是因為這裡的大多數人都與我分享一套廣泛的原則。多年來引起一些爭論的一項原則是我們對自己智慧財產的態度，基本上我們將它放棄。

（滑鼠、Belkin KVM 切換器與 Linux 的問題）

這些現在稱為 Squeezebox。

時常有人詢問如何讓一本書進入我的簽名系列。市面上有很多書系，每個書系都有自己的一套決定標準。以下是我決定標準

大多數人透過關聯資料庫和 SQL 語言最了解關聯資料模型。通俗地說，我們將資料庫視為一組表格，每一列都包含資料。我們可以用各種方式操作這些表格來執行查詢，每個查詢都會產生另一個表格。與 NetworkDataModel 相比，表格之間沒有明確的指標，連結是透過共用值在連結表格中建立（儘管使用替代鍵表示您實際上有指標）。

如果您學習物件導向設計，您很快就會了解封裝資料的重要性。最簡單的封裝形式是使用存取器（取得和設定方法）或屬性，如果您的語言支援的話。（有些甚至在類別中執行此操作 - SelfEncapsulation

現場客戶是極端程式設計的實務之一，是 白皮書 中提到的十二項之一。它表示客戶應與開發人員坐在開放的工作區域中，以便回答問題並與開發團隊互動。事實上，他們是開發團隊的一份子，並認知到團隊的成功與他們和開發人員一樣重要。他們不必放棄定期工作來執行此操作，但他們必須親自到場。

這是朋友的朋友的一個故事。我確定這一定是真實的，至少在某個地方。

我使用應用程式資料庫這個術語來表示由單一應用程式控制和存取的資料庫（與整合資料庫相反）。由於只有單一應用程式會存取資料庫，因此資料庫可以特別定義為容易滿足該應用程式的需求。這會產生一個更具體的架構，通常比整合資料庫更容易理解，而且通常較不複雜。

網路資料模型將資料結構化為記錄類型，並使用指標連結允許在一個記錄和另一個記錄之間導覽。因此，要查詢網路資料模型，您從一個記錄開始，並在指標參考之間移動。

幾年前，我改變了工作生活中的重要面向。在那之前，我嘗試只在一台電腦上工作（或更嚴格地說，只使用一個硬碟）。我所有的工作檔案都保存在我的筆電硬碟中。如果我使用桌上型電腦，我會透過檔案分享功能使用那些檔案。

使用案例是一種組織和引出需求的技術。它們最初由艾瓦·雅各布森在 80 年代後期和 90 年代初期推廣。

形容詞：一種技術、工具或設計概念，明顯簡單到荒謬的地步，以至於不可能有任何好處，但當你開始使用它時，它卻具有一種與其簡單性不相符的力量。

Knoppix 是一個具有許多有趣特性的 Linux 發行版。

在我看來，四人幫 是有史以來關於物件導向設計寫得最好的書，可能是任何設計風格的書。這本書對軟體產業影響深遠，只要看看 Java 和 .NET 函式庫，它們充斥著 GOF 模式。

經過漫長的期待，JetBrains 的人已經為他們的 C# 工具啟動了早期存取計畫。遺憾的是，他們忽略了我的命名建議，反而稱它為ReSharper。我同事們的早期反應很熱烈，但仍希望有更多功能。

C3 是 Chrysler Comprehensive Compensation 專案的簡稱，這是 Chrysler 的薪資專案，後來以 極限程式設計 的「發源專案」而聞名。

階層資料模型以階層或樹狀結構組織。早期的資料庫和程式設計資料結構通常使用階層模型，但這些模型後來不受歡迎。在資料庫領域，關係資料模型 成為主流，而在大多數記憶體內程式設計中，網路資料模型 佔據主導地位。這是因為階層雖然是一種簡單的組織工具，但隨著資料變得更複雜，階層就會失效。

最近幾個月，我瘋狂地安裝 Debian Linux。在過去幾個月中，我的設定中出現許多新的環境。我買了一台新的桌上型電腦，並在上面安裝 Windows XP，一台裝有 MacOS X 的 Powerbook 筆記型電腦，以及一台裝有 Windows XP 的新工作用筆記型電腦。所有這些都需要花費大量時間，即使是我的工作用筆記型電腦，上面已經預先安裝了 Thoughtworks 設定的 Windows XP，仍需要花時間安裝我在工作中使用的各種應用程式。

每個人都有自己的一份重要設計準則清單。Scott 專注於介面，以及如何設計介面，讓它們易於正確使用，且難以錯誤使用。

資產擷取是開發 StranglerFigApplication 的策略。你可以將許多應用程式視為管理一組關鍵資產。薪資系統負責員工，交易系統負責交易，租賃系統負責租賃。要逐步轉換到新系統，你可以先找出你將從新系統開始的一組資產。通常，最適合從中開始的資產是簡單的資產（因為它們可以快速啟動），或那些使用舊系統特別難以處理的需求。

當 Cindy 和我前往澳洲時，我們在昆士蘭海岸的熱帶雨林中度過一段時光。這個地區的自然奇觀之一是巨大的 絞殺無花果。它們在樹的上方枝幹上結籽，並逐漸沿著樹幹向下生長，直到它們在土壤中生根。經過多年，它們長成奇特而美麗的形狀，同時絞殺並殺死作為它們寄主的樹。

如果你使用 XP 風格規劃，你需要從開發人員那裡取得快速共識估計。拋出估計能讓你快速得知開發人員對估計是否有相同的看法（這樣你就可以記錄下來並繼續進行），或是有分歧（你需要更詳細地討論使用者故事）。

我畫了很多 UML 圖，但我沒有使用 CASE 工具。原因是我對UmlAsSketch有興趣，而不是所有儲存庫的東西。到目前為止，我的常規選擇一直是 Visio。雖然 Visio 附帶 UML 範本，但我沒有使用內建範本 - 我比較喜歡Pavel Hruby的範本。

我發現這是一種很常見的架構風格。你的公司購買了一些非常昂貴的基礎設施軟體。然後你被告知你必須在專案中使用它，即使它不適合該專案，而且會讓你付出額外的努力。在為它支付了所有費用之後，你不想讓它浪費，對吧？

我看到關於敏捷專案最常見的問題之一是如何處理移交給另一個團隊。如果你有一個開發團隊離開並將支援移交給支援團隊，當敏捷專案往往產生比計畫驅動流程少得多的文件時，他們該如何應對？

整合資料庫是一個資料庫，充當多個應用程式的資料儲存，因此整合了這些應用程式中的資料（與應用程式資料庫相反）。

當我談論資料庫以及它們如何與應用程式相關時，我發現區分兩種資料庫樣式很有用：應用程式資料庫和整合資料庫。兩者之間的區別在於資料庫是否在單一應用程式邊界內控制和封裝。

作為軟體開發的作家和演講者，我對我們的職業提出了大量的普遍建議。無論是像說明DecoratedCommand如何運作那樣具體，還是像如何思考你的軟體開發態度那樣富有哲理，我所製造的噪音都是無止境的。此外，我僅是廣大一般建議提供者社群中的一員：作者、分析公司、記者，這些建議比任何人都能讀到的還要多。

這項原則表示，你今天完成的工作量將與昨天完成的工作量相同。在重複的專案中，表示你應計畫在這次重複中完成與上次重複相同的工作量。此術語來自極限程式設計社群。

我參加過許多會議小組，也自己組織過幾次。當我組織小組時，我喜歡使用一種特定格式，這種格式是根據英國電視時事小組「問題時間」而來。我做過幾次，而且非常喜歡這種格式，比傳統小組好多了。

處理有維度的數字，例如：12 英尺和 9.99 美元

將一系列值（例如 10 月 22-25 日）視為單一物件。

每隔一段時間，就會有人不只不同意我說的話，還會對我說的話感到驚慌。「像你這樣的專家說了什麼，很多人就會盲目地照你說的做」。

對於許多與極限程式設計接觸過的人來說，極限程式設計似乎要求軟體設計走向死亡。不僅許多設計活動被嘲笑為「大規模前期設計」，而且 UML、彈性架構，甚至模式等設計技術都被淡化或完全忽略。事實上，極限程式設計涉及許多設計，但以不同於既有軟體流程的方式進行。極限程式設計透過允許演化成為可行的設計策略的實務，讓演化設計的概念重獲新生。它也提供新的挑戰和技能，因為設計師需要學習如何進行簡單的設計，如何使用重構來保持設計的簡潔，以及如何以演化的方式使用模式。

在 2003 年的 OOPSLA 中，Dave Thomas（OTI 的創辦人）對模型驅動架構提出了深思熟慮且有力的批評。在這篇文章中，他解釋了他認為為什麼通用的模型驅動方法可能會失敗，並指出 UML 和特定領域語言仍然有價值。

敏捷方法是否應該有認證計畫？

我現在已經結束我的旅程，為了回報我透過電子郵件收到的所有建議，以下是我們為期三週的日本之旅的一些感想。

一般的開發人員可以使用敏捷方法嗎？

2002 年在 XP/敏捷宇宙中參加研討會時，「範例規格」這個詞句讓我想到了描述 XP 中測試角色的方法。

我寫關於設計的文章，我的觀點是，即使你在討論有點抽象的設計模式，提供原始碼範例也是有用的。當然，這可能會導致人們認為程式碼範例就是模式，但我認為程式碼提供的精確性大於這種風險。有幾次我不太確定一個想法，但程式碼範例有助於我釐清它。因此，在我關於設計的文章中，我總是試著提供程式碼範例。

軟體開發中的許多辯論都以發言者具有 指導態度 或 啟發態度 為基礎。這些不同的態度會影響對語言、設計、工具、流程等方面的選擇。

兩種 軟體開發態度 之一。指導態度認為，由於大多數開發人員並不好（據說幾乎 50% 低於平均水平），我們需要指導他們做事的方式。這種指導是為了防止他們對他們正在處理的系統造成傷害。通常，這種態度會表現在設計和工具中，這些設計和工具可以防止開發人員執行某些事情，限制他們可以做的事情，以使他們遠離複雜的領域。

兩個 軟體開發態度 之一。啟用態度認為開發人員是負責任的專業人員，因此應該給予他們自由，讓他們可以做任何需要做的事情。遵循此態度的設計應該讓事情易於使用，但應假設開發人員知道自己在做什麼，因此不必努力防止錯誤使用。因此，這些工具可能會被濫用，但採取的態度是使用者應該更了解，如果他們不了解，他們就應得他們所得到的。

模組化程式設計不只是針對介面進行程式設計，它還包括在各種模組不知道它們正在與哪些具體模組對話的情況下將模組組裝在一起。

我早期最喜歡的書之一是 Tsichritzis 和 Lochovsky 關於資料模型的書。這本書討論了思考資料的不同模型，特別是當時討論最多的三個模型：關聯資料模型、階層資料模型 和 網路資料模型。

當我第一次接觸 C# 時，我就喜歡屬性的概念。C++/Java 的 getX 和 setX 約定對我來說總是顯得相當愚蠢，寫成 obj.X = other.X 自然多了。提供具有 get 和 set 方法的屬性會將常見約定轉換為語言的自然支援功能。

有些人認為 模型驅動架構 (MDA) 將會是自從從組譯器轉移到第一批高級語言以來軟體開發最大的轉變。其他人則認為它不過是活死人案例工具之夜。我屬於後者陣營，但覺得需要的不只是一個巧妙的說法。

這是一個非常常見的模式，也很簡單，它實際上只是應用於命令的裝飾器模式。我看到它經常與 CommandOrientedInterface 一起使用。您還聽說這稱為攔截器，並作為面向方面程式設計的一種形式。

當人們談論 極限程式設計 時，他們通常會專注於其適應性規劃風格，或其演化方法設計等事項。一個小但成長中的趨勢特別引起我的興趣，即極限程式設計專案的數量雖小但成長中，且缺陷率非常低，我的意思是每月低於一個生產錯誤。

在 Java 社群中，出現了一波輕量級容器，有助於將不同專案的元件組裝成一個有凝聚力的應用程式。這些容器的基礎是一個常見的模式，說明它們如何執行配線，一個他們在非常通用的「控制反轉」名稱下引用的概念。在本文中，我深入探討此模式如何運作，在更具體的「依賴性注入」名稱下，並將其與服務定位器替代方案進行對比。它們之間的選擇不如將組態與使用分開的原則重要。

Bruce Eckel 的 最近文章 關於 ant 和 make 觸發我分享一些我對建置語言的想法。ant 和 make 都指定建置如何發生，它們是描述建置的語言。兩者都廣泛使用且已成功。然而，兩者都遇到限制，對於較大的系統，人們通常會發現從其他程式產生他們的 ant/make 檔案。

以下是最近發現的一個有趣的對比。兩個規模相似的企業應用程式專案（~100 KLOC），環境類似（Java 和 .NET）。一個可以在一小時內完成完整的建置和測試，另一個則需要 2-3 分鐘。

對於許多人來說，最難理解敏捷方法的事情之一是敏捷的人員導向。那些對敏捷流程感興趣的人們都同意，流程是專案成功的次要影響。 敏捷宣言 的第一個價值是，個人和互動比流程和工具更有價值。

XML 已經存在一段時間了，而且被廣泛使用 - 確實比它應該被使用的還要多。與大多數工具一樣，XML 對於某些事情是有用的，但對於其他事情則不然

曾經只被少數人知道的術語「重構」現在在電腦產業中被廣泛使用。我喜歡認為我對此負有部分責任，並希望它改善了一些程式設計師的生活和一些企業的底線。（重點是，我不是重構的父親或發明者 - 只是個記錄者。）

重構、JUnit 等工具以及極限程式設計 (XP) 等敏捷方法日益普及，已經帶來了一種新的設計風格。持續設計是使用重構持續改善程式設計的過程。吉姆在本文中討論了他對持續設計的經驗，特別是國際化和交易等看似棘手的設計問題。

從物件導向開發的初期開始，OO 設計就與反覆和增量開發連結在一起。但是，正如許多人指出的，這兩者之間沒有固有的連結。你可以在瀑布中進行 OO，你可以在沒有物件的情況下進行 IID。那麼，為什麼這兩者如此緊密地連結在一起呢？