前言

這些年來，在設計和架構方面一直存在不少的疑惑。到底什麼是設計(design)? 什麼是架構(architecture)? 兩者有何區別?

本書的目的之一就是要消除這些困惑，並一勞永逸地定義架構和設計。

• 架構： 更高層次的概念，它涉及到系統的整體結構和組件之間的關係。架構關注於系統的組織方式，確保系統能夠滿足非功能性需求，如可擴展性、可維護性和安全性。
• 設計： 較低層次的概念，它涉及軟體開發的具體細節，例如: 類別的定義、方法的實現、變數的使用等。

舉個例子，以一個設計的新家來舉例，這個家有一個架構嗎? 當然有的。那麼架構是什麼呢? 就是家的形狀(Shape)、外觀、挑高、和空間以及房間的佈局。但當我們去看設計師製作的設計圖時，你會看到大量的低層次細節，例如: 插座、燈的開關和燈被放置在哪裡。

因此，這就是軟體設計。低層次的細節和高層次的結構都是同一個整體的一部分。他們形成了一個連續的結構，定義了系統的形狀(Shape)。你不能只有一個而沒有另外一個; 實際上，這兩者沒有很明確的分界線。只有從最高層到最低層的一系列決策。

目標

這些決策的目標是什麼? 好的軟體設計的目標是什麼?

設計品質的度量標準。在系統的整個生命週期中，花費的精力都是保持少的，那麼這個設計就是好的，如果每次花費的精力都會隨著每個新版本的增長而增長的話，那麼這個設計就是不好的。

案例研究

下面是採用真實的案例研究來進行展示, 主要是透過幾個觀點來進行比較

• 工程人員的增加
• 工程人員的生產力
• 程式碼花費的成本

爛攤子的記號

你看到上面的案例研究就是所謂的爛攤子記號。當對程式碼的整潔程度和設計架構沒有規劃好的情況下，會導致你的 Release 越大時，花費的成本也跟著提高。

從開發人員的觀點來看，投入了大量的時間，但他們產出非常的低，是因為他們需要努力來管理這些爛攤子，而導致沒有任何的產能。

高層管理的觀點

• 第一個版本的每月花費是數十萬美元。
• 第二個版本的每月花費比第一個版本多了數十萬美元。
• 第八個版本的每月花費是 2000 萬美元，這個金額持續上升

我們比較圖 1.5 和圖 1.2 中每個版本的程式碼行數。你會發現最初只花每個月十幾萬美元換得了許多功能，但最後的 2000 萬美元幾乎沒有得到任何的東西! 如果你是公司的主管看到這兩張圖表，就可以知道避免災難並立即採取行動是必要的。

高層管理人員必須思考下列的事情，嘗試找出問題點

• 該怎麼採取行動?
• 哪裡出了問題?
• 什麼問題導致生產力如此驚人地下降?

什麼地方出了錯？

在兩千六百年前，伊索告訴我們「龜兔賽跑」的故事。這個故事的寓意已經被陳述很多次了:

• 踏實和穩定持續是贏得比賽的關鍵
• 這場比賽不是比迅速，也不是比誰較為強壯
• 越快的，反而速度慢

這個故事本身說明了過度自信的愚蠢。兔子對於自己的速度如此自信，又不認真對待比賽，所以烏龜穿越終點時還在睡午覺。

現代開發者也處於類似的競賽狀態，表現出類似的過度自信。大多數的現代開發者工作得很努力，但他們的大腦一部分確實在睡覺的，這邊是指好的、整潔的、精心設計的程式碼很重要的部分仍然正在睡覺。

這些開發人員常陷入一個熟悉的謊言：「我們晚點整理程式碼，我們先把產品上市先」，當然，你知我也知，這些骯髒的程式碼在之後也永遠不可能被重構，因為市場壓力永遠不會減少，你沒有額外的時間去進行整理的。而且進入市場就意味著你後面有一大堆的競爭對手，你必須盡可能快點跑到最前面。

所以開發人員絕不可能回頭清理或重構這些程式碼，因為他們必須持續不斷地完成下一個功能。而這時爛攤子就此產生了，生產力繼續朝著0的方向趨近。

就像兔子對於牠的速度過於自信那樣，開發者對於自己的生產力也過於自信。但程式碼的髒亂使得他們工作效率不彰，這種情況從未停止也不會減緩。如果按照這樣的方式，在幾個月內生產力就會降低到0。

開發人員陷入一個更大的謊言是，撰寫髒亂的程式碼可以使他們在短期內走得更遠更快，只有長期下來才會變慢。接受這種謊言的開發人員表現出兔子過分自信的能力，認為他在未來將有機會可以處理這些髒亂的程式碼，這樣犯了一個是低級的錯誤。事實上，製造髒亂的開發速度總是比保持整潔的開發速度還要慢。

下圖中，Jason Gorman進行了一項測試實驗，他採用了測試驅動開發(TDD，test-driven development)開發了三天，另外三天他並沒有遵守這個原則來開發，這邊比較了兩者之間的成果。

我們可以發現圖1.6的學習曲線。後一天的工作比之前得更快完成。值得注意的是採用TDD的工作日比非TDD日的工作快了近10%，即便是最慢的TDD日也比最快的非TDD日還要快。

有些人可能會這為這樣的分析是一個了不起的結果，但對那些沒有被兔子過度自信迷惑的人來說，這樣的結果是可以預料到的，因為他們知道這是軟體開發的基本道理:

💡 想要走得快，唯一的方式就是要走得好。

這就是高層人員困境的解答。扭轉生產力下降和成本增加的唯一方法是，讓開發人員停止過度自信的兔子那樣思考，並替他們那骯髒的程式碼進行負責。

而開發人員可能會認為，從頭開始再次重新設計整個系統就好，但這只不過是兔子再次發言。因為就算重新開發了，但程式碼並沒有品質，到頭來還是會重蹈覆轍的。

💡 他們的過度自信將驅使進行重新設計，就像原本的專案那樣髒亂。

總結

要避免這種情況發生，最好的選擇就是讓開發部門認識和避免自己的過度自信，並認真對待軟體架構的品質。

要認真對待軟體架構，你需要知道什麼是好的軟體架構。為了建置一個能「滿足付出精力最小化及生產力最大化」的系統設計和架構。

這就是本書的內容: 他描述了什麼是好的整潔架構和設計(clean architecture and designs)，這樣開發人員可以建置出對於生命週期長期有利的系統。