這是某種我遇過好幾次的應用程式樣式。此應用程式主要是一個報表應用程式，可提供使用者關於某事物狀態的即時資訊。這是一個主動式應用程式，因為使用者可以高度控制他們正在檢視的內容類型，他們可以在特定區域深入探討，並一般性地操作其顯示方式；然而，它仍然至少主要是一個唯讀應用程式。

RIAA 可能會說世界末日到了，但儘管我擁抱數位音樂，並使用我的 Slimp3，我並不認為我的音樂預算會減少。我確實認為我需要更多東西來滿足我 iPod 的渴望。

也許我有點天真，但我從未預期過我在 HumaneInterface 上發表的文章會引起這麼多討論。遺憾的是，大部分討論最後都變成關於 Ruby 的陣列和 Java 的清單的相對優點，而不是我試圖提出的基本觀點，但儘管如此，我認為出現了一些不錯的對話支流。

其中一個對話串指出，除了人道主義/極簡主義的哲學理念之外，還有其他原因造成陣列和清單之間的差異。其中一個原因與類似功能在兩種語言中扮演不同角色的方式有關。

就像大多數的極客一樣，我對時尚或本季流行趨勢沒有太大興趣。我的哲學是，如果內容本身沒有吸引力，那麼擔心包裝沒有什麼意義。但我跟極客朋友聊過幾次關於服裝的話題，足夠激發我寫這篇文章。

幾個月前，我參加了 Eric Evans 的工作坊，他談到一種特定的介面風格，我們決定將其命名為流暢介面。這是一種不常見的風格，但我們認為應該更廣為人知。描述它的最佳方式可能是舉例說明。

Eric Evans 在他傑出的著作 領域驅動設計 中，對您可能會遇到的不同種類的領域物件進行了分類。

在 90 年代對極端程式設計有過良好的體驗後，我開始對類似的敏捷方法感到好奇，例如 Scrum、Crystal 和 DSDM。深入研究後，我提煉出這些新方法的共同特徵：偏好適應性規劃而非預測性規劃，並將人視為比所使用的流程更重要的成功因素。隨著時間的推移，這些方法逐漸歸類於敏捷軟體開發（我也修改了這篇文章），但我仍然認為本文中的觀點是了解敏捷本質的良好方式。

將每個類別與介面配對的做法。因此，您會看到成對的事物 - 可能為 ICustomer 和 Customer 或 Customer 和 CustomerImpl。在許多方面，它呼應了 C/C++ 中每個類別的標頭檔習慣，儘管在這種情況下，介面和實作實際上是不同的類型。

在我的寫作工作中，我早就打算撰寫一段有關驗證的材料。這是一個容易造成許多混淆的領域，對於一些運作良好的技術，提供一些明確的說明會很好。然而，生活中有許多事情可以寫，遠遠超過時間允許的範圍。

在 Ruby 社群中待了一段時間後，我經常遇到「人性化介面」這個術語。它描述了 Rubyist 對撰寫類別介面的態度的一部分，我認為它也建立了設計 API 的兩個思想流派之間有趣的對比（另一個是 最小介面）。

「命令查詢分離」一詞是由 Bertrand Meyer 在他的著作「物件導向軟體建構」中創造的 - 這本書是 OO 早期最具影響力的 OO 書籍之一。（第一版是最有影響力的，第二版很好，但您需要在健身房待幾個月才能舉起它。）

極簡介面是一種 API 設計風格，我將其與 人性化介面 做對比。極簡介面的概念是設計一個 API，讓客戶端能執行所有他們需要執行的動作，但將功能簡化到最小的合理方法集，以完成工作。（請參閱 人性化介面，了解兩者之間的差異。）

延遲初始化是一種技術，它會在變數（在物件導向的環境中，通常是類別的欄位）第一次存取時初始化該變數。其標準形式如下

這個週末，我聽聞了令人悲傷的消息，約翰·弗利西迪斯在與癌症長期抗戰後去世。約翰最為人所知的是「四人幫」之一，他們寫出了可能是 最棒的軟體設計書籍。

記憶體中資料庫是一個完全在主記憶體中執行的資料庫，不會觸及磁碟。它們通常以嵌入式資料庫的形式執行：在程序啟動時建立，嵌入在該程序中執行，並在程序結束時銷毀。

我偶爾會遇到一些想接觸 Smalltalk 並試用看看的人，想了解它為何如此受歡迎。我以前 最喜歡的 Smalltalk 入門書籍 已經絕版了，但我剛發現現在可以 從這裡下載，還有許多其他與 Smalltalk 相關的資料。這些資料是由史蒂芬·杜卡斯所提供，他是 重構模式 一書的共同作者，這本書非常優秀。

這是我最喜歡的會議，但這份報告簡短得令人尷尬。很遺憾地，因為與其他業務衝突，我只能在奧胡斯待一天。儘管我說不出原因，但 JAOO 仍然是一場很棒的會議。不知為何，它設法保留了小型會議的感覺，同時保持新鮮和廣泛。

OOPSLA 再度舉行，有許多會議和各種想法。不可能對這場會議進行適當的總結，因為任何人都無法參加所有會議，更別提吸收所有內容了。因此，以下是一些零散的想法。

James Noble 和 Robert Biddle 提出的一種程式設計思考方式。它的精髓（至少對我而言）在於，軟體開發長久以來一直抱持著現代主義觀點，認為令人讚賞的軟體系統是由統一的元件組成，並以統一且簡單的方式組成。（Smalltalk 和 Lisp 就是這種思考方式的範例。）後現代觀點認為，軟體是各種截然不同的東西，以各種不同的方式黏合在一起（想想 Perl 和 Unix），而這種軟體風格（一大桶膠水）並非壞事。

你無法將十磅的糞便塞進五磅的袋子裡

-- 任何嘗試過的人

當 Kent 和我撰寫《規劃極限程式設計》時，我們加入了這句異想天開的引言，以幫助了解規劃的精髓。

軟體開發領域令人沮喪的一點是，很難在不同的技術和工具之間做出選擇。通常，當有人談論這個問題時，他們會被要求提供「具體數據」，證明該技術或工具優於其他替代方案。這是一個可以理解的要求，但最終會失敗。首先，我們無法衡量生產力。

Thoughtworks 已來到中國。許多人早就渴望開設中國分公司。Roy 一直將其視為RoysSocialExperiment的一部分。此外，在軟體開發方面給我許多美好經驗和想法的 Xiao Guo，也一直希望在中國成立 Thoughtworks。

在 2005 年的JAOO，我主持了特定領域語言的專題。我以半小時的簡介開場，由InfoQ錄製並在其網站上提供。該演講反映了我關於語言工作台論文的第一部分。

如我任何一位固定讀者應當知道的，我已熱衷於 Ruby 數年。我喜歡 Ruby 語言，因為它豐富但簡潔的語法，以及隨附的設計精良架構。它已成為我個人專案的常規主力語言，包括本網站的大部分內容。

企業架構群組通常與日常開發分開。這可能會導致他們對開發工作的知識過時，而開發團隊無法採取廣泛的公司觀點。由於經常看到這種情況發生，我的同事（Thoughtworks CTO）Rebecca 主張企業架構師可以透過加入開發團隊來發揮更大的效用。

Thoughtworks 的一大主題是鼓勵公司所有部門中的人員多元化。（在此脈絡中，我們所謂的多元性是指性別、種族、性取向等事項。）我們希望成為一個讓歷史上處於弱勢的群體（例如女性和非白人）感到自在，並能獲得與傳統白人盎格魯-撒克遜新教領導人一樣多機會的公司。Roy 作為一個著名的混血兒，顯然關心這種多元性。

開放空間是一種幫助您舉辦自組織會議的方法。我最初是在 1997 年由 Norm Kerth 介紹給我的，從那以後，我已看過它被使用，並多次自己使用它。它似乎很適合小規模（十幾或二十人組成的群組）和一兩百人的較大規模。我已看過它用於一到三天的時段。我將說明我所見過的變化：Crested Butte 是一個約有 20 人參加的小型年度工作坊，Agile Universe 2002 在一個軌道上舉辦開放空間會議，約有 100 人參加（他們從那以後持續這麼做，但我無法參加），foocamp 以這種方式接待了幾百人。此技術是由 Harrison Owen 開發的，並在他的 書中 有詳細說明。

看起來 UIUC 的那些狡猾的人準備重構 Fortran。Brian Foote 以他無與倫比的風格撰寫關於這個專案。（他是軟體界最有趣的作家之一，但要讓他寫任何東西通常就像在戴著新鮮殺死的羊排項鍊時試圖從活生生的劍齒虎身上拔牙一樣。）（是的，我知道這是舊聞，但我先在他的部落格上看到其他東西，然後才找到這個。）

封閉方法或類別可防止子類別覆寫它。

程式元素（通常是類別、方法或欄位）上的註解是新增到該程式元素的元資料，可用於使用額外的程式碼來修飾該元素。

呼叫父類別是一個小問題（或如果你喜歡的話，反模式），時不時會在 OO 架構中出現。它的症狀很容易發現。你繼承自父類別，以便插入某些架構。文件說明類似「要執行自己的操作，只要建立處理方法的子類別即可。但重要的是要記得以呼叫父類別來開始你的方法」。範例可能類似這樣。

隨著公司成長，你必須更擔心如何領導公司，以及誰負責選擇領導者。大多數公司都有所有者（股東），他們最終會選擇執行管理階層。然後，執行長會為公司做出大多數決策（或至少他們喜歡認為自己有這麼做）。

每當 Thoughtworks 冒然讓我出現在客戶面前時，我一定會被問到一個問題：「你對 SOA（服務導向架構）有什麼看法？」這是一個幾乎不可能回答的問題，因為 SOA 對不同的人來說有許多不同的意義。

可測試性是一個非常重要的優點，您應該做出架構決策來改善系統的可測試性。

控制反轉是您在擴充套件架構時會遇到的常見現象。事實上，它通常被視為架構的定義特徵。

同義詞為 InversionOfControl。

當我撰寫最近一篇關於 語言工作台 的文章時，我決定將進一步閱讀的部分分開到我的 bliki 中，以便在出現新內容時更容易回報更新。

使用語言工作台與使用傳統的特定領域語言非常不同。這是使用 JetBrains 元程式設計系統 (MPS) 建構一個小型但有趣的 DSL 的範例。您可以使用它來感受使用語言工作台會是什麼樣子。

最近出現一股開發工具的熱潮，這些工具允許您在多個特定領域語言 (DSL) 之間進行整合，我將這些工具稱為語言工作台。許多關於語言工作台的討論都與物件管理小組的模型驅動架構 (MDA) 討論非常類似。在我看來，MDA 對不同的人來說意義不同，這會影響我們如何看待 MDA 與語言工作台之間的關係。當然，有許多 MDA 從業人員使用 MDA 概念來建構語言工作台。然而，我的感覺是 MDA 提供的幫助充其量只是部分。更廣泛的模型驅動開發 (MDD) 學派呼應了許多這些概念，但沒有與 MDA 標準連結，這與語言工作台的概念非常一致。

軟體開發中的大多數新概念實際上都是舊概念的新變種。本文描述了其中之一，也就是我稱之為語言工作台的一類工具，其範例包括 Intentional Software、JetBrains 的 Meta Programming System 和 Microsoft 的 Software Factories。這些工具採用一種舊式的開發風格，我稱之為面向語言的程式設計，並使用 IDE 工具試圖讓面向語言的程式設計成為一種可行的途徑。雖然我還不足以預測他們是否會成功實現他們的雄心壯志，但我確實認為這些工具是軟體開發領域中最有趣的事物之一。有趣到足以撰寫這篇文章，試圖至少概略說明它們如何運作，以及它們未來效用的主要問題。

當您建構特定領域語言 (DSL) 時，您如何讓它可執行。對於內部 DSL 來說，這個問題很容易回答，因為它們會嵌入到真實語言中。外部 DSL 需要更多工作。在這裡，我舉一個簡單的 DSL 範例，並展示一些從中產生程式碼的簡單方法。

我常常遇到一個抱怨，那就是敏捷方法沒有嚴謹的定義。抱怨者可能會談論這表示您無法判斷某個特定團隊是否使用敏捷方法。他們也可能會說這使得很難教導人們如何執行敏捷方法，課程是什麼？

在某種程度上，我確實感受到這種抱怨的痛苦，但我接受沒有治癒方法。這種不嚴謹是敏捷方法定義本質的一部分，也是其核心哲學的一部分。

我收到很多提供免費新軟體開發工具副本的人。很遺憾，我沒有時間查看它們，坦白說，我通常不感興趣。我很少對某個工具感到熱情。

表格驅動技術，讓系統可以在不進行重大程式碼變更的情況下進行變更。

當我們談論 Thoughtworks 時，我們大多談論我們是一家軟體應用程式開發公司。我們也稍微談論我們的價值觀，以及我們如何嘗試成為與大多數公司不同的公司。但這一切都是繞著重點打轉，從根本上來說，Thoughtworks 並不是一家公司。

前幾天我在處理一些書中範例程式碼。我做了一些變更，讓所有東西都正常運作，執行測試，並將其提交到我的個人儲存庫。然後我轉到另一個區域並做了一些變更，結果前一個區域中一些意外的測試中斷了。執行自動化測試的一部分重點是找出意外的中斷，但這段書中程式碼有完全獨立的區域。這很奇怪。

如果你需要在程式碼中取得目前日期或時間，請不要直接存取系統常式來取得該資料。在它周圍放置某種形式的包裝器，讓你可以透過將「目前日期/時間」設定為特定值來覆寫它。這對於簡化測試很重要。

敏捷方法的共同元素之一是它們將程式設計提升到軟體開發中的核心角色，比軟體工程社群通常所做的還要重要。其中一部分是將程式碼分類為軟體系統的主要文件，如果不是主要文件的話。

我認為有幾件事是我對軟體開發的基本看法。如果我必須挑選一個作為我軟體開發的關鍵，那就是軟體開發工作中最重要的元素是從事這項工作的人。最佳開發人員的生產力遠遠超過平均水準，遠遠超過薪資差異。因此，獲得具有成本效益的軟體開發最重要的部分是聘請你能找到的最佳團隊，即使開發人員的個別成本遠高於平均水準。少數高能力（且昂貴）的人員的生產力將遠高於許多低能力（便宜）的開發人員。這種生產力差異表示，少數高能力的人員即使每日費用較高，也能以更低的成本製作軟體。

對我們而言，開源世界的其中一個有趣面向在於它如何證明自己是一個引人入勝的研究社群。開源專案有許多形式，但其中相當多數專案是採用一個想法並圍繞它進行程式設計，以了解它會如何發展以及是否有價值。如果你相信設計和程式設計是分開的，那麼這個概念聽起來很奇怪，但如果你接受它們是相輔相成的，那麼這個概念就很有道理。

（以下是你的字典新增的內容。）

令人厭惡（形容詞）：無法測試的軟體。

我長期以來一直不願意在程式語言中的靜態和動態型別辯論中做出任何貢獻。這是那些情緒化議題之一，人們似乎傾向於辯論而不是傾聽。但由於我被問過幾次，我將貢獻我的個人經驗。我並非試圖說服任何人，但我希望有人能從中找到一些思考的材料。

對於喜歡使用 RSS Feed 的人，我有一些 Feed。雖然我這裡使用了 RSS Feed 一詞，但它們實際上是 Atom Feed。

對各種嘗試編目企業軟體開發模式的個人調查。

在 UML Distilled 中，我哀嘆沒有關於教授 UML 活動圖的書籍。現在仍然沒有，但我最近遇到了 Conrad Bock 關於 UML 2.0 的文章。其中有一系列關於活動圖的文章，比我在 Distilled 中涵蓋的內容更深入。（對於那些不知道的人來說，Conrad Bock 是 UML 2 中活動圖工作的領導者之一。）

現代應用程式伺服器經常宣傳的功能之一是它們在叢集中提供故障轉移。叢集化可以提高應用程式的可靠性，如果您的其中一個伺服器發生故障，您還有其他伺服器可以為您的客戶提供服務。故障轉移可以增加更多可靠性，如果伺服器在互動過程中發生故障，叢集可以將該互動移至另一台伺服器。

然而這可能會是一個問題。

咖啡師不進行同步處理 - 他們的理由可能是您也進行非同步處理的理由。

總結了您可以用來回答有關過去資訊狀態的各種模式。這些問題包括「1999 年 7 月 1 日 Martin 的地址是什麼」和「1999 年 7 月 1 日我們認為 Martin 的地址是什麼，當時我們在 1999 年 8 月 12 日寄送帳單給他」。

任何讀過我的文章的讀者都知道，我是 演化設計 的忠實支持者。儘管我對這種方法充滿熱情，但沒有哪種技術是完美的，我樂於報告它的問題，就像我樂於報告它的成功一樣。

Microsoft 發布了一個名為 PatternShare 的新社群資源。這個想法是彙集許多模式作者的模式摘要，並提供一個平台來討論和進一步探討它們之間的相互關聯。大部分工作是由 Ward Cunningham 領導的，他的模式傳承無人能及。您會在那裡找到我、GOF、POSA、Hohpe/Woolf、Evans 和 Microsoft 的模式。

UML 2 中出現的新標記之一是插座標記，用於顯示類別所需的介面。其起源是 Microsoft 推廣的「棒棒糖」標記，用於顯示實作多個介面的類別。因此，我可以這樣顯示陣列類別實作多個介面。

過去一年，我花了很多時間在 Thoughtworks 四處遊走，與許多專案中的許多人交談。一個讓我深切體會到的訊息是輪替的價值。

在會議或工作坊期間，不時需要對許多事物進行投票，以對子集進行排名或選擇。點狀投票是一種快速且不錯的方式。

我傾向於避免在我的部落格中撰寫有關 Thoughtworks 的文章。在很大程度上，這是因為我不喜歡任何看起來像為我的雇主做廣告的事物 - 每頁上的標誌就已經夠多了。但我的腦海中越來越充滿了我們所做的事情，不僅在我們的交付工作中（這是我的寫作中許多想法的來源），還在我們組織自己的方式中。我放棄成功獨立顧問生活的原因，是因為我認為 Thoughtworks 是一家特別且不尋常的公司。在過去的一年中，我對雇主的社會面向越來越感興趣，因此我決定開始撰寫部落格，介紹其中一些面向。

在過去幾天中，我參加了由 Jimmy Nilsson 主持的挪威企業軟體工作坊。在工作坊期間，我們進行了一場會議，在會中我們提出並投票表決了一堆設計原則。

人們時常質疑特定專業領域是否能以增量方式使用：「你不能用敏捷專案來做（安全性 | 使用者介面設計 | 資料庫 | 國際化 | * ），因為這些面向必須事先完成。」