本文摘自《演進式架構》推薦序
長久以來，軟件行業都奉行這樣一個理念：在開始編寫第一行代碼前就應該完成架構開發。受到建築行業的影響，人們認爲成功的軟件架構在開發過程中不需要修改，而且重新架構往往會導致高成本的報廢和返工。
隨着敏捷軟件開發方法的興起，這樣的架構願景受到了很大的挑戰。預先規劃的架構要求在編碼前就確定需求，因而催生了分階段（即瀑布式）的開發方法——在完成需求分析後纔開始設計架構，然後再進入構建（編碼）階段。然而，敏捷軟件開發方法並不認同“需求是確定的”這樣的觀點。它發現現代商業中需求不斷變化是必然的，並進一步提供了項目規劃技術來擁抱受控的變化。
在這個新的敏捷世界裏，很多人質疑架構的作用。當然，預先規劃的架構無法適應動態的現代業務，但是，還是會有另外一種架構，它以敏捷的方式擁抱變化。如此看來，架構是不斷努力的結果，是一個與開發工作緊密結合的過程，這樣它才能同時響應不斷變化的需求和開發人員的反饋。我們稱之爲“演進式架構”，正是要強調當無法預測變化時，該架構仍然可以朝着正確的方向發展。
在 ThoughtWorks，我們無時無刻不秉持演進式架構的理念。Rebecca 在 21 世紀初領導了多個重要項目，作爲 CTO，她提升了 ThoughtWorks 的技術領導力。Neal 一直密切關注着我們的工作，將我們學到的經驗彙總並傳播開來。Pat 在開展項目工作的同時也加強了我們的技術領導力。我們始終認爲架構是極其重要的，不容忽視。我們雖然也犯過錯誤，但我們從錯誤中學習，更好地理解了如何構建出能正確應對各種變化的系統。
構建演進式架構的核心是採取小步變更，然後通過反饋環讓團隊的每個成員不斷地從系統的發展過程中學習。持續交付的興起使得演進式架構變得切實可行。三位作者通過適應度函數監控架構的狀態。他們探索了架構演進的不同方式，並且重視那些通常被別人所忽視的長存數據。在討論中也理所當然地會經常提及康威定律。
關於構建演進式軟件架構，雖然我們還需要了解很多東西，但本書基於當前的理解給出了基本線路圖。隨着越來越多的人意識到軟件系統在 21 世紀人類社會中的核心地位，每個軟件領導者都應該知道如何在發展中以最好的姿態應對變化。
Martin Fowler
