磚一圈一圈砌了五天，布魯內雷斯基會做一件事
走到教堂外面，退到廣場另一頭，抬頭看整座圓頂的輪廓對不對稱

近看，每一圈磚都合格；但只有退遠一點，才看得出比例有沒有跑掉

今天不學新的警訊，練習的是另一件事：五個警訊擠在同一段程式碼裡的時候，先修哪一個

過去五天，同一個 OrderProcessor 挨了幾刀

Day 01 那段「能跑」的 Process 方法，一開始長這樣：

public decimal Process(int customerId, int productId, int qty,
    string customerType, string couponCode, bool sendEmail, bool sendSms)
{
    // 五件事擠在一個方法裡：驗證、算價、扣庫存、寫 log、發通知
    // customerType == "VIP" 這種字串比對，到處都是
}

同一段邏輯，五天裡被動了五次刀：

如果這五刀的順序倒過來，會發生什麼事？

順序不是隨機的：結構先於內容

試著先做 Day 05（把 customerType 換型別），再做 Day 03（拆方法），會發現一件事：

在方法還沒拆開之前，你根本看不清楚 customerType 這個字串，總共在幾個地方被比對過、被用來做幾種不同的判斷

一個 60 行的方法，把驗證邏輯、算價邏輯、通知邏輯全部揉在一起時，原始型別執念、過長參數列表、資料泥團，全部藏在同一團迷霧裡，很難看清楚各自的邊界在哪

先拆方法（Day 03）、先拆類別（Day 04），是在替其他警訊「清出視野」
不是因為它們比較嚴重，是因為它們決定了你看不看得見剩下的問題

退遠一點看整座圓頂，才會發現
磚頭的比例問題，永遠比某一塊磚的顏色問題，更早需要處理

一個簡單的判斷順序

多個警訊同時出現時，可以先問這句話：

「拆開這一個，會不會讓其他警訊變得更容易看清楚、更容易單獨處理？」

答案通常指向結構性的警訊「過長方法」、「巨大類別」，因為它們決定了程式碼的「視野邊界」
等結構清楚了，字串該不該換型別、參數該不該打包，會變得一目瞭然，甚至不需要額外討論

回頭對照 Day 02 的規矩表

五個警訊，回頭問一句「它踩到哪一條規矩」，答案幾乎都指向同一個地方
S，單一職責（Single Responsibility Principle）

• 過長方法（Long Method），一個方法扛了五個不相干的理由
• 巨大類別（Large Class），一個類別扛了五個不相干的理由
• 原始型別執念（Primitive Obsession），一個字串被迫代表一個本該有自己職責的概念
• 過長參數列表（Long Parameter List）、資料泥團（Data Clumps），一組鬆散的資料，沒有被賦予一個該有的、屬於自己的職責邊界

模組一的五個警訊，其實是同一條規矩，在不同粒度上重複失守的樣子
方法沒守住、類別沒守住、值本身也沒守住

如果時間有限，只能修一個

實務上很少有「五件事一次改完」的餘裕，通常得排優先順序
兩個問題，比「哪個警訊最嚴重」更有用：

• 這段程式碼，多久會被改一次？
  • 天天有人碰的訂單流程，跟一年動一次的批次腳本，值得投入的力氣不一樣
• 改錯了，代價有多大？
  • 牽涉金流計算的邏輯，跟純顯示用的欄位，容錯空間天差地遠

改動頻率高、改錯代價大的地方，優先拆
其他地方，先留著，標記起來，不用急著在這個週期解決

自我檢查清單

1. 這段程式碼裡，如果同時看到好幾個警訊，我是不是本能地想從「最好改」的那個下手，而不是從「結構最亂」的那個下手？
2. 如果先拆開方法或類別，剩下的警訊會不會突然變得更好判斷？
3. 這段程式碼，多久會被團隊碰一次？改錯的代價有多大？
4. 回頭對照 Day 02 的規矩表，這幾個警訊，是不是都指向同一條被打破的規矩？
5. 如果今天只能修一個，我選的是不是那個「拆開後，能連帶讓其他問題變簡單」的警訊？

明日預告

明天我們進入模組二 「中世紀的畫」
人物大小靠感覺決定，達文西的畫，靠一套一致的透視規則

物件導向的濫用者，正式開工