「微服務架構」一詞在過去幾年間突然出現，用來描述一種特定的軟體應用程式設計方式，將其視為可獨立部署服務的套件。雖然這種架構風格沒有明確的定義，但有一些共同特徵圍繞在業務功能的組織、自動化部署、端點中的智能，以及語言和資料的分散控制。

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

無伺服器架構是應用程式設計，結合了第三方「後端即服務」(BaaS) 服務，和/或包含在「功能即服務」(FaaS) 平台上管理的臨時容器中執行的自訂程式碼。透過使用這些想法，以及單頁應用程式等相關想法，此類架構消除了對傳統永遠開啟的伺服器元件的大部分需求。無伺服器架構可以大幅降低營運成本、複雜性和工程前期作業時間，但代價是更依賴於供應商依賴關係和相對不成熟的支援服務。

對於許多與極限程式設計接觸不深的人來說，極限程式設計似乎宣告了軟體設計的死亡。不僅許多設計活動被嘲笑為「龐大的前期設計」，而且 UML、彈性架構，甚至模式等設計技術都被淡化或徹底忽略。事實上，極限程式設計包含了大量的設計，但其設計方式與既定的軟體流程不同。極限程式設計透過允許演化成為可行設計策略的做法，讓演化設計的概念重獲新生。它也為設計人員帶來了新的挑戰和技能，因為設計人員需要學習如何進行簡單的設計、如何使用重構來保持設計的簡潔，以及如何以演化的方式使用模式。

一個模型（由 Leonard Richardson 開發），將 REST 方法的主要元素分解為三個步驟。這些步驟引入了資源、HTTP 動詞和超媒體控制。

功能切換（通常也稱為功能標記）是一種強大的技術，允許團隊在不變更程式碼的情況下修改系統行為。它們屬於各種使用類別，在實作和管理切換時，考慮此類別非常重要。切換會帶來複雜性。透過使用智慧切換實作做法和適當的工具來管理我們的切換組態，我們可以控制此複雜性，但我們也應該限制系統中切換的數量。

「模擬物件」一詞已成為一個流行的詞彙，用來描述模仿真實物件以進行測試的特殊情況物件。現在大多數語言環境都有架構，可以輕鬆建立模擬物件。然而，人們常常沒有意識到，模擬物件只是特殊情況測試物件的一種形式，它能啟用不同的測試風格。在本文中，我將說明模擬物件如何運作、它們如何鼓勵基於行為驗證的測試，以及它們周圍的社群如何使用它們來開發不同的測試風格。

持續整合是一種軟體開發實務，團隊中的每位成員至少每天將其變更合併到程式碼庫中，與同事的變更合併在一起。每次整合都會透過自動化建置（包括測試）進行驗證，以盡快偵測整合錯誤。團隊發現這種方法可以降低交付延遲的風險、減少整合工作，並能促進實務，讓程式碼庫更健全，並能快速使用新功能進行強化。

在過去幾年中，服務基礎架構已轉向較小、更專注的「微」服務。這種方法有許多好處，例如能夠獨立部署、擴充和維護每個元件，並在多個團隊間平行開發。然而，一旦引入這些額外的網路分割，就需要重新考量用於單一處理程序應用程式的測試策略。在此，我們計畫討論許多方法，用於管理多個可獨立部署元件的額外測試複雜性，以及如何讓測試和應用程式保持正確，儘管有多個團隊各自擔任不同服務的守護者。