經濟驅動力#

三十年前，Yourdon 和 Constantine 在《Structured Design》中指出：經濟性是軟體設計的根本驅動力。軟體設計的目標應該是降低整體成本。

軟體的成本分為初始成本和維護成本：

cost_total = cost_develop + cost_maintain

業界累積經驗後的一大意外發現：維護成本遠高於初始開發成本。

幾乎不需要維護的專案應該使用一套與本書截然不同的實作模式。

維護為何昂貴#

維護昂貴的原因在於理解既有程式碼既耗時又容易出錯：

• 當你知道該改什麼時，修改本身通常很容易
• 學習現有程式碼在做什麼才是昂貴的部分
• 修改完成後，還需要測試和部署

維護成本可以分解為：

cost_maintain = cost_understand + cost_change + cost_test + cost_deploy

為何「預先投資」策略往往失敗#

一種降低整體成本的策略是在初始開發時多投資，希望減少或消除維護需求。但這種策略通常未能降低整體成本：

• 當程式碼需要以未預期的方式變更時，再多的預見也無法完美地為變更做好準備
• 過早嘗試讓程式碼足夠通用的努力，常常干擾後來真正需要的修改

大幅增加前期投資還違反兩個重要的經濟原則：

• 金錢的時間價值：今天的一塊錢比明天的一塊錢更有價值，因此實作策略通常應該鼓勵延遲成本
• 未來的不確定性：實作策略通常應該選擇即時利益而非可能的長期利益

這聽起來像是可以不顧未來地亂寫程式的許可證，但實作模式聚焦的是在獲得即時利益的同時，為未來的開發保持乾淨的程式碼。

作者的策略：透過溝通降低成本#

作者降低整體成本的策略是：要求所有程式設計師在維護階段聚焦於程式設計師對程式設計師的溝通，來處理理解程式碼的成本。

清晰程式碼的即時利益：

• 更少的缺陷
• 更容易分享程式碼
• 更順暢的開發流程

模式成為習慣後的效果#

當一組實作模式成為習慣後，編程更快，且更少分心的念頭：

• 作者在撰寫第一套實作模式（《The Smalltalk Best Practice Patterns》，1996 年）時，強迫自己在輸入任何程式碼之前先寫下正在遵循的模式
• 第一週很沮喪——每一分鐘的編程之前都有一小時的寫作，彷彿手指被黏在一起
• 第二週發現大多數基本模式已經到位，大部分時間都在遵循既有的模式
• 第三週編程速度比以前快了許多——因為他仔細審視了自己的風格，不再被疑慮所困擾

他寫下的實作模式只有一部分是自己發明的。大多數風格是從前幾代程式設計師那裡學來的——那些讓程式碼更易讀、更易理解、更易修改的習慣。透過將這些習慣編碼化（Codify），他能比以前更快速、更流暢地編程。他可以同時為未來做準備，又更快完成今天的程式碼。

本書模式的來源#

本書的實作模式來自既有程式碼和作者自身的習慣：

• 閱讀並比較了 JDK、Eclipse 和個人開發經驗中的程式碼
• 所得的模式旨在呈現一個關於如何撰寫人們能理解的程式碼的連貫觀點
• 不同的觀點或價值觀集合會產生不同的模式——例如「Evolving Frameworks」章節基於不同的優先順序，與基本實作風格有所不同

人性需求#

實作模式不只服務經濟需求，也服務人性需求：

• 程式碼是由人撰寫、為人而寫的
• 程式設計師可以運用實作模式來滿足人性需求，例如：
  • 對工作成果感到自豪
  • 成為社群中值得信賴的成員

作者將在後續章節中進一步討論模式的人性與經濟影響。