Ward Cunningham 的前言：模式的力量#
Ward Cunningham 在前言中回憶了二十五年前與 Kent Beck 在 Tektronix 技術中心的一段對話。他問 Kent：如果不考慮現實，我們會用 Smalltalk-80 的知識做什麼？ Kent 回答：「我想改變人們思考程式設計的方式。」而他們最終真的做到了。
這個「不考慮現實」的思維裝置（thought device），本身就是一個模式（Pattern）——它解決了一個常見的問題：我們習慣自我審查自己的雄心壯志。透過這個模式，Kent 和 Ward 得以大膽想像遠大的目標，而一旦想像出來，目標就變得更可實現。
模式不需要是全新的才有用。事實上，不新反而更好。光是知道既有模式的名稱就已經很有幫助了——命名一個模式讓你能討論它，而不必每次都重述整個故事。
書中模式的兩大價值#
即使某個模式的解法你早已知道，本書的書寫形式仍能帶來兩層幫助：
- 更完整的描述：每個模式都經過研究、分類、解釋，你會在其中發現意想不到的洞見（nuggets），讓你原有的模式變得更強大
- 模式之間的連結：每個模式都會通往更多模式。從你已知的模式出發，可以沿著連結發現未知的模式，或從未想過可以搭配使用的組合
精通不只是知道#
Ward 最後提到：這本書充滿了精通（Mastery） 我們複雜領域的模式。精通不僅僅是「知道」，而是以一種減輕負擔的方式來知道。當你運用這些模式、始終保持開放改進的態度，你會發現自己寫出截然不同的程式碼——遠遠超越查閱函式參數順序的層次。
軟體工藝運動（Software Craftsmanship Movement）認識到，要讓所有好的建議成為第二天性（second nature），本身並非第二天性。這些模式正是朝這個方向邁進的重要貢獻。
本書目標#
作者撰寫本書，是為了分享軟體開發新手常面臨的困境的解方。這些困境不是技術性的——書中沒有 Java 設計模式或 Ruby on Rails 的技巧。作者聚焦的是更個人層面的問題：你的動機（motivation）與士氣（morale）。
本書旨在幫助你度過作為軟體開發領域新人時所面對的艱難抉擇。
目標讀者#
本書為嘗試過軟體開發、並渴望成為優秀開發者的人而寫。無論你是網頁開發者、醫療設備程式設計師、金融交易系統工程師，或者剛從學校畢業、知道軟體是自己的未來，這本書都適合你。
雖然主要為新手而寫，但不同經驗層級的讀者也能從中受益：
- 數年經驗的開發者：會對書中描述的困境點頭認同，並獲得新的見解或至少一套新的詞彙來描述想採用的解法
- 十年以上經驗的人：特別是那些在職涯導航上感到掙扎的人，能找到靈感與視角，抵抗「晉升為管理層」這個誘人但未必正確的召喚
寫作過程#
起源#
2005 年初，Stickyminds.com 邀請 Dave 撰寫軟體工藝專欄。當時 Dave 自認是一名（有經驗的）學徒，唯一有自信寫的主題就是學徒精神。同一時期，他讀到開發者 Chris Morris 引述吉他手 Pat Metheny 的一篇部落格文章，Be the Worst（成為最差的那個）這個概念播下了模式語言的種子。
初始模式源自 Dave 在 2000 至 2005 年間的職涯經歷。
驗證與擴展#
為了確認這些「模式」確實是常見問題的常見解法，Dave 透過三種方式蒐集回饋：
- 公開發表：在網站上公開模式，附上留言表單徵求回饋
- 訪談業界領袖：透過電子郵件訪問軟體開發領域的思想領袖，取得他們對初始模式的看法
- 訪談資淺實踐者：最重要的一環——訪問經驗較少的從業者，用他們的近期經歷驗證模式。這些訪談也引入了 Dave 未曾遇到或未曾察覺的新模式
正是在這些學徒訪談中，Dave 訪問了 Ade，隨後 Ade 加入成為共同作者。兩人訪談了來自澳洲、印度、瑞典等地的從業者，訪談場景從 LiveJournal 留言到倫敦金融區一座美麗的受損教堂，跨度極大。
PLoP 工作坊#
2005 年底，他們在 Pattern Languages of Programs（PLoP） 工作坊上進行焦點小組討論。在 PLoP，資深模式作者（又稱 shepherds）從模式格式和自身程式設計經驗兩方面給予回饋。
本書最終成果根植於數十場從業者訪談，以及對學習理論、最佳表現心理學（psychology of optimal performance）和精通（mastery）主題的廣泛研究。書中引用了外科醫生、編舞家、哲學家，以及常見的軟體名人——作者相信，研究各領域的高績效者能帶來豐富的啟發。
本書結構#
本書由數個大章節組成，每章包含一組相關的模式。模式名稱以大寫表示（如 Breakable Toys），相關模式之間頻繁交叉引用。每章都有主題導言和小結，全書的 Introduction 為模式語言奠定基礎，Conclusion 則從全局角度審視技能、學徒精神與精通。
模式格式#
本書的模式格式較為獨特，與大多數模式語言相比，段落更少、對抽象力量與約束的討論也更簡潔。這個格式是根據大量審稿人回饋和 PLoP 工作坊的意見而選定的，目的是讓目標讀者更容易理解。
每個模式由四個部分組成：
- Context（情境）：設定場景氛圍
- Problem（問題）：點出整個模式要解決的問題
- Solution（解法）：通常以一句話概括解答，再深入探討應用細節、與其他模式的關係、相關故事與文獻
- Action（行動）：描述你可以立即採取的具體行動，作為模式的範例實踐。即使你不確定模式是否適用於當前狀況，也可以直接動手嘗試
任何模式都是針對特定情境中一族問題的一族解法。模式的設計是開放修改的，應依你的處境調整，而非機械式地套用。如果某個模式不完全符合你的情況，試著從提供的素材中推導出對你有用的東西。
大多數模式結尾有 See Also 段落，指向相關模式，引導你跳脫線性閱讀，沿著模式間的關係進行探索。
使用方式#
A pattern language gives each person who uses it the power to create an infinite variety of new and unique buildings, just as his ordinary language gives him the power to create an infinite variety of sentences.
— The Timeless Way of Building, p. 167
作者的目標是創建一套模式語言，幫助你定義屬於自己的學徒之旅。由於無法預知每個人的處境，請務必根據每個模式的 Context 和 Problem 來判斷是否適用於你。
模式的組合使用#
模式之間相互關聯，組合使用能產生更強大的效果：
- Find Mentors 本身已是經典模式，但若搭配 Rubbing Elbows 則威力倍增
- Expose Your Ignorance 較依賴支撐模式如 Confront Your Ignorance 和 Retreat Into Competence，需要更細膩地運用
與所有模式語言一樣，切勿過度使用。不要為了使用模式而找藉口套用每一個模式，而是挑選最適合你處境的組合。
閱讀建議#
本書不必從頭讀到尾。作者建議的閱讀方式包括：
- 跳躍式閱讀：掃描每個模式的 Context 和 Problem，找出與你當前處境相關的模式
- 連結式閱讀：從書中任一處開始，沿著模式間的連結漫遊，就像瀏覽網站一樣
- 兩遍式閱讀：第一遍快速瀏覽掌握全貌，第二遍深入連結所有關係
本書最初以 wiki 形式撰寫，因此從未設計為線性閱讀——前面的模式會引用後面的模式，反之亦然。它更像是一本藝術家的靈感集，你可以隨時翻閱汲取靈感，每次回來都會發現新的東西。
軟體工藝精神宣言#
2009 年 3 月，經過 software_craftsmanship 郵件列表的長期討論後，以下宣言被起草：
身為有志的軟體工匠（Software Craftsmen），我們透過實踐並幫助他人學習這門手藝，來提高專業軟體開發的標準。透過這項工作，我們體認到以下價值：
- 不僅要有可運作的軟體，更要有精心打造的軟體
- 不僅要能回應變化，更要能持續增加價值
- 不僅要有個人與互動，更要有專業人士的社群
- 不僅要有客戶協作，更要有高效的夥伴關係
也就是說，在追求左側項目的過程中，我們發現右側的項目不可或缺。
這份宣言是對 Agile Manifesto 的延伸與補充，將焦點從「如何做軟體」提升到「如何做好軟體」，強調工匠精神中對品質、持續進步和社群的承諾。