我的朋友都是極客，所以他們許多人都期待 2003 年 11 月雙城奇謀的加長版 DVD 上市那天（而對我的朋友來說，只有加長版 DVD 才值得擁有）。但對我來說，那天標誌著另一項同樣重要的發行，Sergio Leone 的偉大西部片終於發行 DVD 了。

已發布介面是我用來（首先在 重構 中）指稱在定義它的程式碼庫之外使用的類別介面的術語。因此，在 Java 中，它的意義大於 public，甚至大於 C# 中的非內部 public。我在 IEEE Software 的專欄中論證，已發布和 public 之間的區別實際上比 public 和 private 之間的區別更重要。

您如何在 UML 中表示衍生資訊？

鑰匙圈上的筆電，在許多方面來說，這只能算是誇飾，但這個想法最近一直讓我著迷。催化劑是接觸到 Knoppix。

縮寫為：Plain Old Java Object（純粹的舊 Java 物件）。

專案時間軸是在 專案回顧 期間製作的一項有價值的東西。時間軸應顯示專案期間發生的各種事件，以及它們如何影響專案。

對於任何為面向服務架構建置服務的人來說，這是一個重要的想法。當您建置服務時，也建置一個服務存根，您的客戶端可以使用它來進行測試。此類存根應提供對固定請求集的罐頭回應，模擬錯誤狀況，並可以在客戶端機器上執行。您需要確保存根正確模擬真實系統行為。透過為您的客戶端提供存根，您可以讓您的客戶端更容易使用您的服務；這當然表示您的服務更有可能被使用。

我目前正在XP day的一個會議中，Owen Rogers 和 Rob Styles 正在討論 XP 的單元測試和驗收測試之間的差異。這觸發了我的一個想法 - 什麼應該是撰寫驗收測試的語言？

這是已經存在很長一段時間的反模式之一，但似乎在目前特別流行。我與 Eric Evans 聊過這個問題，我們都注意到它們似乎越來越受歡迎。作為適當領域模型的強力推動者，這不是一件好事。

模組最常見的介面樣式是使用程序或物件方法。因此，如果您希望模組計算合約的一堆費用，您可能會有一個具有計算方法的 BillingService 類別，像這樣呼叫它

aBillingService.calculateCharges(aContract)

命令導向介面會為每個作業有一個命令類別，並使用類似這樣的東西呼叫

CalculateChargeCommand.new(aContract).run()

我遇到的大多數客戶都沒有聽過反覆開發，或認為它是一種新的且相對未經嘗試的現象。相反，反覆開發已經存在很長一段時間，並有各種不同的名稱。Craig Larman 和 Vic Basili 最近在 IEEE Software 上發表的一篇文章總結了捕捉這段歷史的努力，並讓您對使用反覆開發方法的成功專案的悠久歷史有一個很好的了解。

UML 對不同的人來說有不同的意義，這就是我發現人們使用不同的UmlMode的概念很有用的原因。我交談過的大多數人對UmlAsSketch感興趣，而這群人對 UML 2 沒有留下深刻印象。

封裝的常見部分，特別是面向物件的系統，是隱藏資料結構。然而，將大部分資料顯示在資料存取常式後面也很常見。在本文中，我將介紹一些撰寫資料存取常式的準則。不過，請別忘記，如果可以讓資料保持隱藏，通常會更好。

到目前為止，重構工具已經出現在許多語言中。在 Smalltalk 的帶領下，我們已經看到許多 Java 工具和幾個 C# 工具。儘管有呼籲，但 C++ 卻是顯著缺席的語言。儘管第一個重構論文是由Bill Opdyke所撰寫，而他的背景是 C++。

我發現並遵循的最有用的設計原則之一，就是讓程式（使用者介面）的簡報面向與其他功能保持良好的分離。在過去我看到此做法的這些年中，我已經看到許多好處

最近我在 Amazon 上看到一些關於P of EAA的負面評論，因為書中沒有關於企業架構的內容。當然，這是有充分理由的 - 這本書是關於企業應用程式架構，也就是如何設計企業應用程式。企業架構是一個不同的主題，是如何將企業中的多個應用程式組織成一個有條理的整體。

如何在 UML 類別圖上顯示局部變數（參數、暫存器等）？

每個 XP 愛好者都知道 4 個價值觀和 12 個實務，但有多少人知道 15 個原則？我承認，當 Kent 上週在JAOO談論它們時，我並不知道。在演講後，我問 Kent 關於它們：「它們在白皮書中嗎？」「是的」，他回答說，「巧妙地隱藏在名為『基本原則』的章節中」。

此網站的所有內容皆以簡單的 XML 文件撰寫，並轉換成 HTML。我發現這方法十分有效，表示我永遠不用擔心處理 HTML 格式。（如你所見，花俏的版面並非我的風格。）我甚至用這種方式寫了一整本書。

相依性和關聯性之間有何不同？

關於模型驅動架構（MDA）的一項重大主張是，它允許你在平台無關模型（PIM）中開發系統，然後可以將其轉換為技術（例如 .NET 或 Java）的平台特定模型（PSM）。一位警覺的讀者應該會這樣說：「等一下，Java 的重點不就在於平台無關嗎？那為什麼我需要一種平台無關技術來產生另一種平台無關技術？」

在物件導向的早期，像我這樣的 OO 倡導者非常重視爭論重用的好處。早期，我們討論類別的重用。然後我們發現，重用個別類別雖然在某些情況下有效，但在其他情況下卻不盡然。因此，我們進入可重用的架構，這讓我們獲得部分建構的功能應用程式。

軟體開發中一個尚未解決的問題是決定軟體的邊界為何。（瀏覽器是否為作業系統的一部分？）許多服務導向架構的支持者認為應用程式即將消失，因此未來的企業軟體開發將與組合服務有關。

我認為應用程式不會消失，原因與應用程式邊界如此難以界定的原因相同。基本上，應用程式是社會建構

重構一詞從何而來？

我們看到許多關於軟體流程、設計實務等充滿情緒的討論。其中許多論點無法解決，因為軟體產業缺乏衡量軟體開發效率某些基本要素的能力。特別是，我們沒有合理衡量生產力的方法。

有許多 ValueObject 的常見範例，我最喜歡的是 貨幣，而與貨幣密切相關的是貨幣。

用例 和 XP 的 使用者故事 有什麼不同？

所有敏捷方法都強調系統開發人員與最終受益者的客戶之間直接互動的重要性。敏捷宣言說「業務人員和開發人員必須在整個專案中每天合作」，這強調互動的高頻率。極限編程透過 現場客戶 的實務來強調這一點。

當人們使用「軟體架構師」這個詞時，他們使用建築施工的隱喻來幫助人們了解架構師的角色。具有諷刺意味的是，在這樣做的過程中，他們誤解了建築架構師的實際角色。

當資料建模方法討論關係時，它們使用術語基數來表示可以連結在一起的實體數量。因此，您可能在訂單和客戶之間建立關係，並表示該關係的基數是一對多。或者，您可能會聽到訂單的客戶基數為 0 到多。

看看大多數在應用程式語言和關聯式資料庫之間溝通的函式庫，你會注意到它們將資料庫中的字串類型（字元或變長字元）對應到程式語言中的字串類型。簡單、顯而易見，但或許是錯的。

關於模式書籍的常見抱怨是，它們對經驗豐富的開發人員來說沒有什麼新東西可說。（我最近在亞馬遜評論和 The Server Side 上收到一些這樣的評論，所以或許我現在有點敏感。）這不僅是真的，而且是模式的重點所在。

歌唱神探是英國廣播公司在 1980 年代製作的電視影集（6 集，每集一小時）。包括我在內，許多人認為它是他們看過最棒的電視作品。這是一部複雜的作品，可能是電視史上最原創的藝術作品之一。因此，它並非每個人的菜，但我已經看過很多次了。它最明顯地與編劇丹尼斯·波特有關，他製作過許多具有挑戰性的電視節目。它最近在 DVD 上架。

許多人相信你無法在敏捷專案中進行固定價格合約。由於敏捷流程的重點在於你無法預測未來，這並非不合理的假設。然而，這並不表示你無法提出一個固定價格的敏捷合約，它的真正意思是，你無法提出一個固定範圍的合約。

深入了解任何大型企業，你通常會發現某種類型的群組專注於全企業概念建模。最常見的是資料管理群組，偶爾他們可能會參與定義全企業服務。它們之所以是全企業的，是因為它們專注於整合多個應用程式，而不是專注於單一應用程式的努力。

歷史或多或少是垃圾

-- 亨利·福特

我最近收到一封不開心的電子郵件，來自 UML Distilled 的讀者。當一位憤怒的讀者後悔購買，更不用說閱讀我偶爾的智慧之言時，這對我來說從來都不是美好的一天開始。但這位讀者的抱怨特別有趣。他具體的抱怨是我的「不必要的歷史」。

當我們想到軟體架構時，我們通常會想到它的技術架構。但還有一個重要的架構 - 我們用來與軟體客戶溝通的架構：市場架構。忽視這種「市場架構」及其與「技術架構」的關係，可能會讓開發專案陷入很多麻煩。

什麼是架構，誰才是真正的架構師？這些問題似乎讓所有人都很激動。因此，在這個 IEEE 軟體專欄中，我讓 Ralph Johnson 解釋一下架構：用一個定義來匹配所有其他定義，但沒有人同意。我也談到了架構師的兩個亞種：Architectus Reloadus 和 Architectus Oryzus。

這個月是審查 IEEE 的軟體工程知識體系的月份。這是一種嘗試定義我們專業的知識體系，以便為持照專業奠定基礎。

我的同事 Joe Walnes 指出我們的同事 Chris Stevenson 開發了一個非常簡單的工具。TextDox（AgileDox 的一部分）是一個從 JUnit 測試案例自動產生文件檔的工具。聽起來很荒謬，但這就是 Wardish 想法的樣子。

當人們開始使用物件時，特別是在強類型語言中，一個常見的問題是他們是否應該為不同的網域類型擁有特定的集合類別。因此，如果你有一個儲存員工集合的 company 類別，你應該使用程式庫中的常規集合類別，還是應該建立一個特定的 EmployeeList 類別 - 一個類型化集合。

上週，我有幸在佛羅里達州四處走動，在幾場 Microsoft 架構委員會中與 Dan Sandlin 和 David LeBlanc 交談。對於那些不知道的人來說，David LeBlanc 與 Michael Howard 合著了非常受歡迎的書籍 撰寫安全程式碼。在每一場會議中，我都會針對 P of EAA 進行演講/問答（本週獲得 JavaWorld 獎項），而 David 則會接著討論安全性。

測試增強設計中常見的問題，是如何在測試模式中建立服務 Stub，同時讓實際的服務在生產環境（以及某些測試）中存在。我的幾位同事分享了他們的想法。

上週，OMG 通過 UML 2 的上層結構文件。實際上，這表示 UML 2 已達成共識。UML 2 中對 UML 進行了許多變更，這是自 UML 最初達成共識以來對 UML 進行的最大規模的修改。對於一般使用者而言，最明顯的變更可能是

UML 使用案例圖定義了一組使用案例之間的關係。最知名的兩個關係是包含和延伸。這兩個關係似乎比使用案例的任何其他部分，甚至 UML 中的任何部分都更受質疑。

要透過收割來建立平台，您一開始不要嘗試建立平台，而是建立應用程式。在建立應用程式時，您不要嘗試開發通用程式碼，但您確實努力建立一個結構良好且設計良好的應用程式。

基礎平台是在任何建立在其上的應用程式之前所建構的。這個概念是，您分析需要該平台的各種應用程式的需求，然後建立平台。平台一旦完成，您便可在其上建立應用程式。重點在於，在您開始處理應用程式之前，平台確實需要有一個穩定的 API，否則平台的變更將難以管理，因為它們會對應用程式產生連鎖效應。

最近一篇由Robert Cringely撰寫的文章最近在重構社群中引起了一陣騷動，因為他批評了重構。Phlip 在重構郵件清單上總結了回應，以異常克制的「...他聽起來像是一位『懷疑論者』，寫了書評，卻無意閱讀這些書。」

在此UML 模式中，開發人員使用 UML 來協助傳達系統的某些面向。與藍圖一樣，您可以使用草圖進行前向工程或反向工程。前向工程會在您撰寫程式碼之前繪製 UML 圖表，而反向工程則會從現有程式碼建構 UML 以協助理解程式碼。

如果您能詳細說明 UML，並為軟體中所需的一切提供語意，則可以讓 UML 成為您的程式語言。工具可以取得您繪製的 UML 圖表，並將它們編譯成可執行程式碼。

這項承諾是，UML 是一種較高層級的語言，因此比目前的程式語言更具生產力。

長久以來，受工程影響的軟體流程一直在尋找一種方式來表達軟體設計，以便可以將設計移交給另一個小組來撰寫程式碼，就像在建造橋樑時使用藍圖一樣。這將允許稀有且昂貴的軟體設計人員專注於藍圖，而許多較便宜的編碼人員則專注於建構。

在我瀏覽 UML 2 時，我發現人們對於 UML 應該包含哪些內容有不同的看法，因為對於 UML 應該是什麼，存在著不同的基本觀點。在思考這個問題時，我提出了三個思考 UML 的主要分類：UmlAsSketch、UmlAsBlueprint 和 UmlAsProgrammingLanguage。（有趣的是，Steve Mellor 獨立提出了相同的分類。）

我已經觀察部落格場景發展了一段時間，而且不可能不想加入。但是，有些事情我對部落格不太熱衷。首先，正如我的同事 Mike Two 所說，這個名稱「部落格聽起來像是某種我應該付錢給醫生移除的東西」。然而，除了名稱之外，還有部落格文章非常短暫的本質。短篇寫作在閱讀時可能很有趣，但很快就會過時。我發現寫作太難，不想把它花在會消失的事物上。

如果我想教人們物件導向，我應該使用哪種語言？

你能使用重構來建置平台嗎？

UML 中很少有事情比聚合和組合更令人驚訝，特別是它們與一般關聯的不同之處。

CHAOS 報告指出，只有 34% 的專案成功。

Standish Group 的 CHAOS 報告 多年來一直談論 IT 專案浪費了數十億美元。34% 的成功率實際上比 2001 年的 28% 有所改善。但我們真正指的是什麼「失敗」？

在具有 受保護 AccessModifier 的類別中儲存資料，是否是一種良好的 OO 設計？

物件導向語言會將程式區分為稱為類別的模組。每個類別都包含特徵，由資料（欄位）和方法組成。（並非所有語言都使用這些術語，但它們適用於此。）語言有各種規則，說明哪些其他類別可以存取類別的特徵，這些規則通常基於套用於類別的存取修飾詞。

假設您有一個包含曲目陣列清單的專輯類別。您如何在 UML 類別圖中顯示這個類別？

一個常見的問題是大型專案是否可以使用敏捷技術來完成。畢竟，許多敏捷方法都是為較小的專案設計的，而他們所抗拒的重量級想法在較大的專案中更為需要。

混沌理論為何暗示元件組裝可能不如想像中那麼容易。

《軟體開發》雜誌將我著作《企業應用程式架構模式》的第 7 章（分佈策略）改編成一篇雜誌文章。我猜測他們喜歡它的語氣，以及包含了「分散式物件設計的第一定律」。

我在 IEEE 專欄中論述模式對理解軟體設計的寶貴貢獻。

隨著 XP 和其他敏捷方法越來越受歡迎，開始出現有關如何將 XP 擴展到 10-12 人團隊之外的問題。2003 年 2 月中旬，在加拿大艾伯塔省班夫舉辦了一場專門探討此主題的工作坊。在本文中，我們將報導 Ken Schwaber 和 Martin Fowler 的主題演講，以及其他領先實務者的演講。

在過去的幾十年中，我們看到資料庫導向軟體開發人員和記憶體中應用程式軟體開發人員之間的差距越來越大。這導致許多關於如何使用 SQL 和儲存程序等資料庫功能的爭議。在本文中，我探討了是否將業務邏輯放在 SQL 查詢或記憶體中程式碼中的問題，主要考慮一個簡單但豐富的 SQL 查詢範例的效能和可維護性。

到目前為止，我已經使用 XML 進行大部分的寫作，甚至寫了最後一本 XML 書籍。當我向人們提到這一點時，他們問了我許多關於我經驗的問題，這足以促使我寫下這篇關於這整件事的小文章。

關於何時為值建立新的使用者定義類型 (或類別) 的準則。