許多現代網路伺服器程式碼會與上游服務通訊，後者會傳回 JSON 資料，對該 JSON 資料進行一些整理，並使用時髦的單一頁面應用程式架構將其傳送到豐富的客戶端網頁。與使用此類系統的人員交談時，我聽聞許多人對於處理這些 JSON 文件時需要做的工作量感到相當沮喪。透過封裝載入策略組合，可以避免許多此類沮喪。

在許多程式設計環境中，現在慣用清單和雜湊映射的複合體來表示資料結構。大多數主要語言現在都提供這些資料結構的標準版本，以及豐富的運算範圍，特別是 集合管線，用於處理它們。這些資料結構非常靈活，讓我們能夠以易於處理和操作的方式表示大多數形式的階層。

在我開始我的寫作生涯時，我從為技術雜誌撰寫文章開始。現在，當我撰寫文章長度的作品時，它們都是為網路撰寫的。紙本雜誌仍然存在，但它們是一個正在萎縮的少數，可能註定滅絕。然而，儘管紙本雜誌日漸式微，但許多紙本雜誌的假設仍然對作家和出版商產生影響。這特別出現在最近與在我想在我的網站上發表的文章上工作的幾個人進行的對話中。

當一個組織採用敏捷思維時，企業架構並不會消失，但企業架構師的角色會改變。企業架構師不再做出選擇，而是幫助他人做出正確的選擇，然後傳播該資訊。企業架構師仍然需要形成願景，但接著需要在團隊之間建立橋樑，以建立學習社群。這將允許團隊探索新的方法並相互學習，而企業架構師則是該成長過程中的合作夥伴。

我們的軟體邏輯大部分都是用我們的程式語言寫的，這些程式語言提供我們最佳的環境來撰寫和演化此類邏輯。但在某些情況下，將該邏輯移到我們的命令式程式碼可以詮釋的資料結構中會很有用，也就是我所稱的適應性模型。在這裡，我將展示 JavaScript 中的一些產品選擇邏輯，並展示如何將其重構為編碼在 JSON 中的簡單產生式規則系統。這個 JSON 資料讓我們可以在使用不同程式語言的裝置之間分享這個選擇邏輯，並在不更新這些裝置上的程式碼的情況下更新這個邏輯。

遠距與共置工作並非簡單的二分法，而是有幾種團隊分佈模式，每種模式都有不同的取捨和適合它們的有效技術。雖然無法確定明確的證據，但我認為大多數團隊以共置方式工作會更有生產力。但你可以透過使用分散式工作模式來建立一個更有生產力的團隊，因為這能讓你接觸到更廣泛的人才庫。

隨著程式規模越來越大，將其拆分為模組非常重要，這樣你就不需要了解所有內容就能進行小修改。通常這些模組可以由不同的團隊提供，並動態地組合在一起。在這篇重構文章中，我使用表示層-領域層-資料層分層法拆分一個小型程式。然後我重構這些模組之間的相依性，以引入服務定位器和依賴性注入模式。這些模式適用於不同的語言，但看起來卻不同，所以我同時在 Java 和無類別 JavaScript 樣式中展示這些重構。

必要的介面是由互動的客戶端定義的介面，它指定供應元件需要做什麼才能在該互動中使用。

從費力地撰寫程式碼轉變為透過簡單地組裝元件來建構強大的系統，一直是我進入這個專業領域以來的目標。這個目標有時會若隱若現，但從未真正達成，儘管許多技術都曾拋出工業化再利用的誘餌。

將資訊豐富的程式模組化的最常見方法之一，就是將其分為三個廣泛的層級：簡報 (UI)、領域邏輯 (又稱商業邏輯) 和資料存取。因此，您經常會看到網路應用程式分為知道如何處理 HTTP 要求和呈現 HTML 的網路層、包含驗證和計算的商業邏輯層，以及整理出如何在資料庫或遠端服務中管理持續性資料的資料存取層。

Andrew Koenig 最早於 JOOP 中的一篇文章中創造了「反模式」一詞，很遺憾的是，該文章並未在網路上提供。基本概念 (依我所記得的) 是，反模式是某個在您開始時看起來像是個好點子的東西，但會讓您陷入困境。從那之後，這個詞彙經常被用來表示任何壞點子，但我認為最初的重點更有用。

對齊地圖是組織資訊散熱器，有助於將正在進行的工作與業務成果視覺化對齊。這項工作可能是例行的功能新增，或是技術工作，例如重新架構或償還技術債務，或改善建置和部署管道。團隊成員使用對齊地圖來了解他們的日常工作旨在改善哪些業務成果。業務和 IT 贊助者使用它們來了解正在進行的工作與他們關心的業務成果之間的關係。

迴圈是處理集合的經典方式，但隨著程式語言中一級函式的採用率越來越高，集合管線成為一種有吸引力的替代方案。在本文中，我將透過一系列小範例，探討如何將迴圈重構成集合管線。

敏捷軟體開發打破了需求分析、測試和開發之間的一些隔閡。部署、運作和維護是其他活動，與軟體開發流程的其他部分遭受類似的分離。DevOps 運動旨在消除這些隔閡，並鼓勵開發和運作之間的協作。

許多開發團隊發現微服務架構風格優於單體架構。但其他團隊發現它們會拖累生產力。與任何架構風格一樣，微服務帶來成本和好處。要做出明智的選擇，您必須了解這些成本和好處，並將它們應用於您的特定環境。

集合管線是一種程式設計模式，您可以在其中將一些運算組織成一系列運算，這些運算透過將集合作為一個運算的輸出，並將其輸入到下一個運算來組合。（常見的運算有篩選、對應和簡化。）這種模式在函式程式設計中很常見，在具有 lambda 的物件導向語言中也很常見。本文透過幾個範例說明如何形成管線，以向不熟悉管線的人介紹這種模式，並幫助人們了解核心概念，以便他們可以更輕鬆地將想法從一種語言轉換到另一種語言。

《神秘博士》是一部長期播出的電視劇，但您不必花太多時間就能開始享受它。挑選出色的獨立劇集很容易。

Tor 運作方式和使用方式的摘要。它也涵蓋 Tor 瀏覽器套件、隱藏服務、Tails，並探討 Tor 周圍的一些爭議。

在過去幾個月，我反覆聽聞，要獲得成功的微服務架構，唯一的途徑就是從一個整體開始。用 Simon Brown 的話來說：如果你無法建立一個結構良好的整體，你憑什麼認為你可以建立一個結構良好的微服務組？這個論點最近一次——而且一如往常地非常有說服力——的闡述來自 Martin Fowler，就在這個網站上。由於我有機會評論較早的草稿，所以我有一些時間思考這個問題。我確實思考了，特別是因為我通常發現自己同意他的觀點，而且一些我通常認同其觀點的其他人士似乎也同意他的觀點。

我堅信，從一個整體開始通常完全是錯誤的做法。

在我聽聞團隊使用微服務架構的故事時，我注意到一個常見的模式。

1. 幾乎所有成功的微服務故事都從一個變得過於龐大而被拆分的整體開始
2. 在我聽聞從頭開始建置為微服務系統的系統的案例中，幾乎所有都遇到了嚴重的問題。

這個模式讓我的許多同事主張：即使你確定你的應用程式夠大，值得這麼做，你也不應該從微服務開始一個新專案。。

Yagni 最初是一個縮寫，代表「你不需要它」。它是一個來自極限編程的咒語，通常在敏捷軟體團隊中普遍使用。它是一個聲明，我們假設我們的軟體在未來需要的一些功能不應該現在就建置，因為「你不需要它」。

微服務架構風格是去年最熱門的話題。在最近的O'Reilly 軟體架構大會中，似乎每個場次都在討論微服務。這足以讓每個人的過度炒作胡說八道偵測器啟動並閃爍。這其中一個後果是我們看到團隊過於急於採用微服務，卻沒有意識到微服務本身會帶來複雜性。這會增加專案的成本和風險，而這通常會讓專案陷入嚴重困境。

Kent Beck 在 1990 年代後期開發極限編程時，提出了四個簡單設計規則。我這樣表達它們。

當我撰寫處理外部服務的程式碼時，我發現將該存取程式碼分隔成獨立的物件很有價值。在這裡，我將展示如何將一些凝結的程式碼重構成這種分離的常見模式。

資料湖是本十年出現的一個術語，用來描述大數據世界中資料分析管線的重要組成部分。這個想法是為組織中任何可能需要分析的人員提供所有原始資料的單一儲存庫。一般來說，人們使用 Hadoop 來處理資料湖中的資料，但這個概念比 Hadoop 更廣泛。

經營 martinfowler.com 網站是我在 Thoughtworks 工作的很大一部分。傳統上，它的流量比我們的主要網站多，儘管隨著我們的主要網站改進，這將會很樂意地改變。我的網站是我們影響產業的工具，這是我們支柱 2 工作的一部分。

與任何新的架構術語一樣，很難對微服務是什麼有一個明確的定義，因此這場演講從 James 和我幫助激發興趣的文章開始，著手解決這個問題。然後，我將微服務與 SOA 進行比較，將架構與更單體的方法進行比較，並概述在部署微服務應用程式之前必須做對的重要事項。

我經常參與關於刻意增加一群人多元化的討論。軟體中最常見的情況是增加女性的比例。兩個例子是招聘和會議講者名單，我們討論嘗試讓女性的比例高於通常的水平。反對推動更大多元化的常見論點是它會降低標準，引發一個多元化但平庸的群體的幽靈。

一個簡單的範例說明如何先重構程式碼以簡化變更，讓變更更容易進行。