經過近一個月與博碩技術編輯的協同校稿，總算完成初與二校了！編輯說下月10號左右就可以交付打印了，看來總算可以趕在農曆年前實體出版了。（相當感謝技術編輯的用心，她幫我找出許多用語上的問題。）
我光是構思要如何撰寫序文就花了好幾天時間，內容著重在個人的學習歷程與經驗談、出版本書的動機、應用AI輔助開發的互補等。（至於本書的內容導讀則於第二章節詳述）
以下就是序文完整內容：
去年底（2024），好容易還能開設完整的「設計模式應用開發實務」課程，這恰好趕在今年的 AI 輔助開發的大爆發前，可說是實屬難得。然後我就想說利用這個機會，將原來已教授十餘年所累積的教材內容，重新作個整理，打算出版成書，也算是圓了自己的期望。
當即寫信聯繫好多年以前曾協助我們團隊成員出版 UML 著作的博碩總編輯錦輝，他曾經參加過當時我們顧問團隊舉辦的「Clean Code 讀書研討會」。事實上，該書（無暇的程式碼）就是他的翻譯大作，翻譯品質極佳，整本書當年我是逐句細讀看完的，對我後續軟體設計與程式撰寫的思維受益匪淺，所以有好幾年的時間我在課堂上都會強烈推薦給學員，是必讀的軟體巨著。
當年還與團隊 Partner 拜訪博碩位於汐止的出版社，也與錦輝還有博碩古總經理一同吃飯聚餐，也會聊聊一些軟體界的軼聞，好多年以前的事了，回想仍猶然在目。然後這次寫信才知道錦輝早已榮升出版社總經理，雖不直接負責編輯審閱，但馬上請了總編輯 Abby 與我電話聯繫，初步先了解下我寫這本書籍的動機與主要內容方向等。當時與 Abby 第一次的通話時聊了大概有四、五個小時之久吧，天南地北都聊，Abby 說是創下她職涯最久的聊天紀錄，哈哈。
其實我早知道寫一本書著實不容易，要考量的地方太多太多了，這也是為什麼10餘年來我仍卻步不前，並未進一步將我教授累積有10多門不同類型的課程教材整理成書出版。尤其第一次著書就挑戰了最為抽象深奧的「設計模式」，所以整個撰稿過程考量的環節更是謹慎。此外我還很冒昧地請錦輝審閱我的初稿，他在公司事務繁忙之餘，仍舊答應我的請求，甚至還親自為本書擬定書名，完全契合本書的核心精神，在此謹致上誠摯由衷的感謝！
錦輝曾任資深的軟體技術編輯，並未干涉我所規劃的目錄架構與章節編排等，而是相當尊重作者的自由發揮。僅提出一個建議（且並未特別要求），書中所有軟體案例能使用同一個應用領域，讓讀者在閱讀時能有較一致的觀感。這個建議對我助益良多，因此我將所有 23 個設計模式的程式碼範例，全面改以最為通用的電子商務領域重新撰寫。
此外，對於原先交付的書稿章節架構，感覺整體連貫性仍有不足，於是重新加以編排整理，甚至連內容也幾乎全部改寫（但核心思維並沒有改變）。這樣的調整使得出版時程又延宕了數個月，直到最後才得以確定整本書稿可以交付出版。也因為不斷補充與深化內容，最終 Word 書稿頁數竟超過 700 頁。
除了力求保持每一個設計模式章節的一致性外，我也為看似僅能適用在軟體領域、具高度抽象的設計模式，提供一種更貼近直覺、也更具想像力的理解方式。所以我從古典文學四大名著的經典故事與人物關係中，擷取與各種設計模式相呼應的情境，並輔以 UML 結構進行對照說明。這樣的編排是希望讀者能先從熟悉的敘事脈絡中理解設計意圖，再來對應到軟體系統的結構設計，讓抽象的模式概念變得更為立體而生動。
本書最終得以在出版社的通融與支持下，並未裁減內容，而是改以上下兩冊（共 900 餘頁）的形式出版，使每一個設計模式的思考脈絡，無論是在理論、實務，或跨領域的比喻層次上，都能被完整地呈現。
關於設計模式的發展背景、GoF 著作的歷史脈絡、傳統的分類方式，以及本書所採用的篇章結構與閱讀建議，我已詳述整理於第二章〈設計模式導論〉之中。該章節的目的，是協助讀者建立一個較為清晰的學習地圖，理解為何本書並未依循傳統分類，而是重新以主題與問題導向來組織全書內容。這裡我只想再特別強調讀者需要確實認清**設計模式的本質：它是一門關於軟體如何應對變化的『組織設計技藝』。**若僅從實作的角度切入，往往只能學到表面的形式，反而使軟體設計趨於複雜，卻難以真正理解設計模式所試圖回應的核心問題。
而要能逐步掌握這門設計技藝，勢必需要回到物件導向的基礎思維與設計原則之上。這正是本書第一章所扮演的角色：協助讀者重新理解「抽象、封裝、多型與介面」等核心觀念，以及必要的設計原則（如 SOLID）。這些並非額外的知識，而是學習設計模式之前，必須先練就的紮實「基本功」。
回顧自己學習設計模式的歷程，其實並不順遂。最初接觸 GoF 的《Design Patterns》時，即使採取最笨的方法，一頁一頁、逐句閱讀，仍舊完全看不懂書中究竟在談些什麼。那樣的挫折感相當大，甚至有一段長達一、兩年的時間，我刻意不再碰觸任何與軟體相關的書籍。然而，也正是在那之後的某個時刻，理解卻開始一點一滴地浮現，彷彿過往累積的思考終於逐漸產生連結。
因此，我也常將自身經驗分享給後進學習軟體設計的開發人員，看不懂其實是常態，只是時候未到而已。不必急著理解或套用，只要願意持續學習、反思，並在可能的情況下與同好或導師討論，這些看似零散的理解，終究會累積成某種「漸悟」，並在某個時刻轉化為真正的「領悟」。
如同《金剛經》中所言：「因無所住，而生其心」，六祖慧能因而頓悟。對我影響最深刻的一句話，則是軟體巨擘 Martin Fowler 所提出的 「Keeping Software Soft」。這句話彷彿為我打開了另一個「心世界」，也讓我在多年反覆思索與實務體會之中，逐漸（資質有限，無法一蹴而就地頓悟）對軟體設計有了更為深刻的理解。
我將這句話翻譯為 「把軟體作軟」，並視其為貫穿本書的核心精神。所謂「作軟」，並非隨意或缺乏紀律，而是指能夠真正落實 Design for Change（為變化而設計） 的設計態度。設計者必須時時提醒自己：變動是必然的，而設計的目的，正是要讓這些變動被侷限在可控制的範圍內，而非任其擴散，最終導致系統僵化難以維護。
正是因為懂得如何控制變動，而不至於牽一髮而動全身，軟體系統在開發與維護階段，才能有效降低所需投入的人力資源。這樣的道理，並不因技術浪潮的更迭而有所改變，即使進入今日 AI 輔助開發盛行的時代，依然完全適用。
在 AI 算力即成本（Tokens）的時代，越是不懂得控制變動，所付出的代價就越高昂；無論是反覆生成、頻繁修補，或是不斷推倒重來，本質上都只是將設計上的混亂，轉化為算力與資源的浪費。AI 可以加速程式碼的產出，卻無法替人類做出真正的設計判斷。
也因此，掌握設計模式背後的設計思維，並非為了背誦模式名稱或套用既有結構，而是在 AI 浪潮之中，仍能清楚判斷系統架構的優劣，並引導 AI 產出具備彈性、可演進的程式碼。真正不會被取代的，從來不是寫程式的速度，而是設計與組織軟體的能力。
本書旨在引導讀者可以逐步建立一種看待軟體設計的角度：懂得分辨哪些變動是不可避免的，哪些核心結構是值得被保護的根基，以及在面對需求演進時，如何不再侷限於追求眼前可行的短暫權宜之計，而是能做出更具延展性、經得起時間考驗的長遠設計架構。無論是與團隊成員合作或與 AI 的協作開發過程中，能更清楚如何聚焦、如何引導，更能懂得如何控制變動，從而真正駕馭工具，而非被工具所淹沒。
這本書期望能讓讀者在現實的開發工作上，找回屬於開發者的那份專業尊嚴與成就感，從此在軟體設計的世界裡，真正做到「從從容容，游刃有餘」，而不再是「匆匆忙忙，連滾帶爬」！