建立進化架構前言

很長一段時間以來，軟體產業遵循著一個觀念，認為架構是應該在撰寫第一行程式碼之前開發並完成的。受到建築產業的啟發，人們認為成功的軟體架構特徵是不需要在開發過程中進行變更，這通常是為了避免重新架構事件所造成的高昂廢棄和返工成本。

敏捷軟體方法的興起對這種架構願景提出了嚴厲的挑戰。預先規劃的架構方法建立在一個觀念上，即需求也應該在開始編碼之前確定，這導致了分階段（或瀑布式）方法，其中需求緊接著架構，而架構本身緊接著建構（程式設計）。然而，敏捷世界挑戰了固定需求的觀念，並觀察到需求的定期變更在現代世界中是商業上的必要性，並提供了專案規劃技術來接受受控變更。

在這個新的敏捷世界中，許多人質疑架構的角色。當然，預先規劃的架構願景無法適應現代的動態性。但是，還有一種架構方法，它以敏捷的方式接受變更。在這種觀點中，架構是一種持續的努力，它與程式設計緊密合作，以便架構可以對變更的需求以及來自程式設計的回饋做出反應。我們稱之為進化架構，以強調雖然變更是不可預測的，但架構仍然可以朝著好的方向前進。

在 Thoughtworks，我們沉浸在這個架構的世界觀中。Rebecca 在這個千禧年的早期帶領了我們許多最重要的專案，並在擔任我們的 CTO 期間發展了我們的技術領導力。Neal 一直是我們工作的仔細觀察者，綜合並傳達我們學到的教訓。Pat 結合了他的專案工作來發展我們的技術領導。我們一直認為架構至關重要，不能任其自生自滅。我們犯過錯誤，但從中吸取了教訓，對如何建立一個能優雅地回應其目的的許多變化的程式碼庫有了更好的理解。

進行演化架構的核心是進行小的變更，並建立回饋迴路，讓每個人都能從系統的開發方式中學習。持續交付 的興起已成為使演化架構實用的關鍵促成因素。作者三人組使用適應度函數的概念來監控架構的狀態。他們探討了架構的不同可演化風格，並強調了長期資料周圍的問題 - 這通常是一個被忽視的主題。康威定律 應該高於大部分的討論。

雖然我確信我們還有很多關於以演化風格進行軟體架構的知識要學習，但本書標誌著對當前理解狀態的重要路線圖。隨著越來越多的人意識到軟體系統在我們二十一世紀人類世界中的核心作用，在保持穩健的同時了解如何最佳回應變更將成為任何軟體領導者的基本技能。

---