米開朗基羅畫西斯汀天頂時，不是每一塊 giornata，發現問題都會當場處理

灰泥還沒乾的那幾個小時，是真正能修改的好時機
過了這個好時機，這塊區域的設計就定案了
想改，得等下一層灰泥，或者接受它就是這樣了

每一塊灰泥，都要做同一個判斷
這個問題，值得現在停下來修，還是先記一筆，留到下一輪再處理？

期限前兩天，發現一個霰彈式修改

團隊在 sprint 收尾前兩天，發現一個 Day 16 那種霰彈式修改
新增一種折扣類型，得同時改 5 個檔案才能生效

這時候擺在眼前的，是一個很real的選擇：

• 現在重構：抽出一個 IDiscountPolicy 介面，把散落的判斷收攏（但重構本身需要時間，還可能引入新的 bug，而發布日期，兩天後就到了）
• 先記一筆技術債：這次新增，先照著舊模式，在 5 個檔案裡各補一筆，但同時開一張技術債票，寫清楚「下次再新增折扣類型，一樣要改 5 個地方，根治方法是抽出 IDiscountPolicy」

兩個選擇都不是「錯的」，錯的是不假思索地選，或者選了卻沒有留下任何紀錄

三個問題，幫忙做這個判斷

• 這個問題，會不會馬上引發 bug？
  • 如果不修，系統照樣正確運作，只是改動比較貴，這種情況通常可以先緩一緩
  • 如果不修，某個邊界條件就會出錯，這種情況要優先處理，跟時間壓力無關
• 接下來多久，還會再摸到這個地方？
  • 一個月內就要再加第二種折扣類型的話，現在的重構成本，很快就能透過下一次省下的時間打平
  • 如果是一年才會再碰一次的角落，先記著，實際上更划算
• 這次的改動範圍，可控嗎？
  • 兩天內能review完、能寫測試驗證的重構，值得冒險。牽動核心金流、需要跨團隊協調的重構，兩天內硬上，風險通常比留著不改更高

三題只要有一題明確指向「現在修」，就不要猶豫；三題都指向「先緩」，那就該把技術債好好記下來，而不是假裝這個問題不存在

一筆合格的技術債紀錄，該寫什麼

「之後再處理」最容易失敗的地方，是那筆債從來沒有被真正記下來
沒有人記得它、也沒有人知道它多急迫

一筆能真正被追蹤的技術債，至少要包含：

• 具體位置：哪幾個檔案、哪個方法，不是「折扣邏輯有點亂」這種模糊描述
• 根治方案的方向：例如「抽出 IDiscountPolicy，讓新增折扣類型變成新增一個實作」，不用寫到能直接動工的細節，但要讓下一個接手的人，看得懂要怎麼改
• 觸發下次處理的條件：例如「下次再新增第三種折扣類型時，先做這筆重構，再動手加新類型」

沒有觸發條件的技術債，會永遠排在待辦清單最後一項

回頭對照 Day 02 的規矩表

模組三的三個警訊，追根究底，都是 開放封閉原則在提醒我們的事
新增一種行為，不該逼你回頭修改一段已經在運作的舊程式碼

每一次「先記一筆技術債」，本質上都是在承認
「這個地方目前還沒做到開放封閉，而且，現在不是修正它的最佳時機」

承認這件事，本身不丟人
不承認，才會讓同一塊灰泥，一次又一次地被迫在時間壓力下修改

自我檢查清單

1. 這個問題不修，會不會馬上導致錯誤的結果？還是只是讓改動變貴？
2. 接下來一個月、三個月，這個地方還會不會再被摸到？
3. 現在動手重構，改動範圍是不是能在期限內完成並驗證？
4. 如果決定先緩，我有沒有把具體位置、根治方向、觸發條件都寫進技術債紀錄？
5. 這個決定，是團隊一起評估過的，還是我一個人在deadline前臨時決定的？

明日預告

明天我們進入模組四「阿伯提說」
美是多一分則累贅、少一分則缺憾

可有可無者，正式開工