如果您閱讀許多標準文件，除了需要大量的咖啡之外，您還需要提防某些字詞的過度使用。

角色介面是透過觀察供應商和消費者之間的特定互動來定義的。供應商元件通常會實作多個角色介面，每個介面對應一種互動模式。這與標頭介面形成對比，其中供應商只會有一個介面。

標頭介面是一種明確的介面，模擬類別的隱含公開介面。基本上，您會取得類別的所有公開方法，並在介面中宣告它們。然後，您可以為類別提供替代實作。這與角色介面相反，我在那裡討論了更多詳細資訊和優缺點。

現在JRuby越來越成熟，許多人開始思考要採取行動，用rake取代 ant，進而改善建置指令碼的世界。

如何提升軟體開發人員的生產力？

在過去幾年，關於 Web 2.0 的討論很多，不論是關於概念或其作為一個新詞的價值。我參與其中是有限的，我讀過和聽過 Tim O'Reilly 關於這個主題的論述，並參加他組織的一個工作坊。然而，那裡有很多混淆，所以我猜是時候讓我做一個徒勞的嘗試來減少混淆了。（由於我對其中的大部分內容都是根據 Tim 的說法來詮釋的，如果我們對任何事情有不同意見，你應該相信他。）

我習慣創造新詞來描述我在軟體開發中看到的事物。在這個領域的作家中，這是一個常見的習慣，因為軟體開發仍然缺乏許多有用的術語。建立術語的一個問題在於，術語容易失去其意義，這是一個語義擴散的過程 - 使用我們術語中另一個潛在的補充。

新詞

1：一個新的單字、用法或表達。
2：一個由精神病患者創造的無意義的單字。

-- Merriam-Webster

如果你讀過我很多文章，你很快就會注意到我是一個強迫性的新詞創造者。我總是想提出新的單字和短語，事實上，這個 bliki 就是圍繞這個習慣設計的。

敏捷方法的一個常見，也許是主要的實務，是為正在建構的軟體開發一個功能清單（通常稱為故事）。這些功能會透過索引卡、工作佇列、燃盡圖、待辦事項或任何你選擇的工具來追蹤。

普遍語言是 Eric Evans 在 領域驅動設計 中用來描述開發人員和使用者之間建立共同嚴謹語言的實務。此語言應基於軟體中使用的 領域模型，因此需要嚴謹，因為軟體無法很好地應對歧義。

關於 結對程式設計 的一些常見迷思。

Ruby 最受歡迎的功能之一是它支援 元程式設計，也就是說，這些功能就像改變語言本身一樣，引入了新關鍵字等內容。

物件母親是一種在測試中使用的類別，用於協助建立範例物件，供您用於測試。

內部 DSL（通常稱為內嵌 DSL）是一種 特定領域語言，它寫在現有的主機語言中。這是許多程式語言社群中常見的思考方式，特別是 Lisp 社群。由於 DSL 是快速成長的 Ruby 社群中常見的思考方式，因此現在備受關注。

如果您關心自己的工作，就會關心如何做得更好。這包括思考您如何做事，並嘗試新的技術，看看它們是否能讓您做得更好。即使其他人推薦新技術，您唯一知道它們是否對您有效的方法就是自己嘗試，看看它們是否能提升您的表現。

在物件導向圈中爭論最久的論點之一是 開放繼承 和設計繼承之間的辯論。設計繼承的原則可能由 Josh Bloch 最佳總結：「設計和文件繼承，否則禁止繼承」。使用此方法，您會仔細決定哪些方法可以繼承，並 密封 其他方法以阻止它們被覆寫。

根據敏捷聯盟的現任董事會，敏捷方法「已跨越鴻溝」，我想這表示它們正變得更加廣泛。雖然這有其優點，但也帶來問題。當一種方法論或設計方法變得時髦時，我們會看到許多人使用它或教授它，他們專注於時尚，而不是真正的細節。這可能會導致以敏捷的名義所做的行為報告，與運動創始人的原則截然相反。

我之前說過（在此頁面的早期版本中），我不明白為什麼沒有明確、可稽核紙本記錄的投票機可以被認為可以接受投票。對此觀點的進一步支持是普林斯頓大學的一項近期研究，顯示破壞常見投票機有多麼容易。（透過Glenn Vanderburg）

Apple 最近宣布了Time Machine，它能夠回到過去並查看對檔案的所有變更，包括尋找已刪除的檔案。對我們這些極度狂熱的怪咖來說，這並不是一項新功能。像其他人一樣，我將我的整個工作目錄置於版本控制之下，最初是 CVS，現在是Subversion，因此我能夠輕鬆查看我所處理的所有變更。這是一個非常有用的功能，我以前曾想過擁有更多版本控制會是什麼樣子，也許 Time Machine 就是朝這個方向邁出的一步。

這與設計繼承的態度相反。開放繼承的支持者不會透過封閉類別或採取其他措施來阻止人們繼承類別，來禁止繼承。

一段時間前，Jon Udell 描述了兩種公開演講模式：

• 腳本：你寫下你將要說的內容，然後朗讀或背誦它。
• 投影片驅動：你製作詳細的投影片，並使用它們來驅動你所說的話。

我現在的大部分公開演講都使用第三種模式 - 即興演講。這種風格一開始我只有一個簡略的演講大綱，然後在進行的過程中構思其他所有內容。

當提到 DomainSpecificLanguage 主題時，一個常見的謎題就是什麼是或不是 DSL。問題在於 DSL 沒有精確的定義，而且 DSL 與其他事物之間存在一大片灰色地帶。

我花費許多寫作精力撰寫模式。時常有人問我為何這麼做，以及什麼才構成一個好的模式。這是一篇簡短的文章，說明我如何看待模式，並提供給有興趣撰寫模式的人一些建議。

當有人在探討構成頂尖企業軟體開發人員的要素時，對框架和語言的了解，或理解複雜演算法和資料結構的能力，通常會成為話題。對我而言，程式設計人員或開發團隊最重要的特質之一，就是我所謂的「客戶親和力」。這是開發人員對軟體所要解決的商業問題，以及生活在該商業世界中的人們的興趣和親近程度。

過去四年來，Thoughtworks 在印度班加羅爾營運一個實驗室，以支援我們在北美和歐洲的軟體開發專案。傳統的離岸開發方法基於計畫驅動的方法論，但我們堅定地站在敏捷陣營。在此，我將討論我們在進行離岸敏捷開發時獲得的經驗和學到的教訓。到目前為止，我們發現我們可以讓它發揮作用，儘管其好處仍有待商榷。（儘管本文最後一次更新於 2006 年，但我於 2011 年拜訪了我們的離岸工作，發現這些教訓仍然相關，因此本文不需要進一步的重大修訂。）

GUI 架構演進的歷史概觀，特別關注模型-檢視-控制器多年來不同群體的看法。從歷史角度連結到我的簡報模式。

在最近成立的 Rails 社群中，「企業」一詞正成為一個負面詞彙。對許多人來說，Rails 框架及其激進的簡潔性，與過於複雜的 「企業」 框架背道而馳。

使用者介面的模式之敘述性概觀。討論如何以及為何將網域邏輯與簡報分開，以及如何分開和同步資料層。

2001 年 2 月，一群十七位軟體專家齊聚猶他州雪鳥鎮，討論過去稱為輕量化方法的領域之成長。我們決定使用敏捷一詞來描述這類新一代的敏捷方法。我們也撰寫了敏捷軟體開發宣言，說明這些敏捷程序的價值觀和原則。我便是這些自封的先見之一，從那時起，我便遇到許多關於這個團體起源和敏捷聯盟後續成立的問題。以下是我對那些事件的回憶。

我已經多次談論持續整合的優點。要讓這樣的環境運作，你需要一個持續整合伺服器和一個原始碼控制系統。為了讓專案順利執行，你也可以使用一個問題追蹤器來追蹤錯誤等問題，以及一個 wiki 來協助擷取各種專案知識。

2001 年在猶他州雪鳥鎮舉行的會議，決定使用「敏捷」一詞，並開始制定「敏捷軟體開發宣言」。

與我大多數的主題演講一樣，這是一場即席演講。考量到這場會議，這場演講的主題是 Rails 如何影響軟體開發。

在我最近一篇關於EvaluatingRuby的文章中，我提到一位同事已經將一個網路應用程式與一些精美的數值圖表組合在一起。有人寄電子郵來詢問他是如何做到的。我在原始的 wiki 條目中加入了我的簡短回答 ploticus，但這引發了一個問題，他如何將 ruby 與 ploticus 介接起來？

最近部落格圈的爭議是由尼古拉斯·卡爾的一篇文章引起的，他宣稱「維基百科的死亡」（是的，我知道我的回應很慢，但我沒有時間在旅途中寫作）。他的第一篇文章給我的感覺很奇怪，他說維基百科正在消亡，因為 0.01% 的文章受到相當溫和的保護。這就像當一個城鎮雇用一名警察時，有人說民主已經結束了。

本文討論了在服務提供者和消費者社群中演進時遇到的一些挑戰。它描述了當服務提供者變更其合約的部分內容（特別是文件結構）時所產生的某些耦合問題，並找出兩個廣為人知的策略，即增加結構延伸點和執行接收訊息的「剛好足夠」驗證，以減輕此類問題。這兩個策略都有助於保護消費者不受提供者合約變更的影響，但它們都沒有讓提供者了解其使用方式，以及它在演進時必須維持的義務。本文利用這些緩解策略之一（「剛好足夠」驗證策略）的基於斷言的語言，描述了「消費者驅動合約」模式，它讓提供者了解其消費者義務，並將服務演進集中在提供消費者所要求的主要業務功能上。

今年年初我經常旅行，所以我的寫作完全停擺。幾週前我回到家，希望可以寫很多東西。嗯，我寫了一些，但總有一些事情讓我分心：動手術移除事故中留下的鋼釘、淹水。但最大的生產力殺手是我自己造成的，那就是買了一台新電腦。

過去幾年來，我們最喜歡的玩具之一是 Squeezebox。它是一款非常簡單的裝置，大小約等於一個路由器，具有電源、乙太網路、擴大器和無線區域網路天線埠。它的工作是接收從伺服器串流的 mp3 檔案，並透過擴大器播放。

在我最近的 CodeOwnership 文章中，我描述了我思考程式碼擁有權問題的方式。我的許多軟體開發朋友都是極端程式設計師，並且傾向於支持集體程式碼擁有權。然而，這些類型的做法並非絕對，且應始終根據當地考量進行調整。我的其中一位同事寄了一則訊息給我，內容是以下故事，我認為這是一個很好的指標，說明即使你是 XP 的忠實粉絲，也必須調整你的做法。（由於他談論的是他的團隊，所以他希望保持匿名。）

有在關注新聞的人可能會注意到，新英格蘭地區遭到一場大規模的春季暴風雨侵襲，造成許多淹水。我住在梅爾羅斯，正好位於暴風雨中心，週末降雨量將近十英寸。人們表示，自 1938 年的颶風以來，從未發生過這種情況，儘管與過去幾年世界其他地區遭受的災情相比，這只是小事一樁。

我曾接觸過各種程式碼擁有權制度。我將它們分為三大類

如果你正在閱讀這篇文章，我假設你已經知道 Ruby 程式語言，特別是 Rails 網路應用程式開發架構，引起了廣泛的討論。有些人認為它是程式設計的未來，而另一些人則認為它是一種危險的轉移。

過去一個月左右，我一直在我們的英國辦公室閒晃，與英國的 ThoughtWorkers 們見面。我原本打算拜訪一些客戶專案，但光是與辦公室裡裡外外的人見面就讓我忙得不可開交（也中斷了所有寫書進度，不過這可以等到我回到家再說）。

當他們看到 getter 方法時，你可以從他們嘴角左邊的抽搐看出，他們迅速拔出戰斧，並在另一個 getter 從一個隨即在感激的 Getter 撲滅者腳下昏厥的類別中被無情地砍下時發出滿足的歡呼聲。

使用 setter 初始化，你可以建構一個空物件，然後使用 setter 方法在進行時設定各種屬性。（ConstructorInitialization 的替代方案。）

程式碼異味是一種表面現象，通常對應於系統中更深層的問題。這個術語最初是由肯特·貝克在我協助撰寫我的重構一書時創造的。

建構函式初始化是一種方法，您可以在物件的建立方法中傳入物件所需的所有協作者。這是 SetterInitialization 的替代方案。

作為一名作家，我的成功之一就是我已成為一位小眾怪咖名人。這非常小眾，通常只在怪咖會議中發生作用（儘管我有幾次在舊金山的一家餐廳裡有人走過來找我）。在發生這件事之前，我並沒有想太多，除了對名聲的渴望之外。現在它發生了，我更意識到了它——總而言之，我討厭它。

思考企業應用程式最長久的方法之一是將其視為對外部世界事件做出反應的系統。這是一種思考方式，在 80 年代後半期在結構化設計社群中確立。您現在在「事件驅動架構」的標語下聽到了它。在 2000 年代中期，我開始為這些類型的系統收集一些模式，但從那以後一直無法將它們轉化為更實質的東西。儘管它們的性質粗糙且準備就緒，但我確實認為它們提供了圍繞事件協作的性質的一些有用的想法，引入了「事件溯源」一詞，使用平行模型來表示世界的假設狀態，以及如何使用協定調度器組織網域邏輯。

一個模式敘述，探討如何使用事件作為系統運作和與同儕協作的焦點。總結了如何表示事件、如何使用事件在系統之間整合以及在系統架構中使用事件溯源。

對會計有用的模式敘述。包含帳戶、分錄和交易的基本表示，以及會計調整模式的概觀。

Gerard Meszaros 正在撰寫一本書，以擷取使用各種Xunit架構的模式。他遇到的尷尬情況之一是，人們用於測試系統部分的存根、模擬、假設、虛擬和其他事項的各種名稱。為了處理這個問題，他想出了自己的詞彙，我覺得值得進一步推廣。

XUnit 是給予廣為軟體開發人員所知的測試架構群的家族名稱。這個名稱源自JUnit，這是第一個廣為人知的測試架構。

契約設計 (DbC) 和測試驅動開發 (TDD) 的倡導者之間長期存在一場低調的爭論。我現在不會深入探討，但我會傳達一個合併兩者的想法，這個想法是在我與Daniel Jackson交談時提出的。

當人們說某個方法不會改變物件的可觀察狀態時，他們是什麼意思？

每當兩個或三個值聚集在一起時，將它們轉換成 $%#$%^ 物件。

-- 我（用聲音說會更有趣）

這是重構書籍中我最喜歡的程式碼異味之一。當你持續看到相同的幾個資料項目一起傳遞時，你就會發現它。開始和結束是一個資料群組想要成為範圍的良好範例。資料群組通常是沒有人會想到轉換成物件的基本值。

Java 和 C# 都共用純介面類型的相同模型。你可以透過轉到 interface Mailable 來宣告一個純介面，然後你可以宣告你使用 class Customer implements Mailable（在 Java 中）來實作它。一個類別可以實作任意數量的純介面。這個模型忽略的事項之一是，每當你有一個類別時，你就會有隱式介面。