有一次，我們在跑整合測試的時候，發現三個測試檔案都報錯：一個是參數不對，另外兩個是直接引用了不存在的事件類別。第一直覺是：參數那個比較簡單，先修了再說，然後再來處理缺失的事件。

這個「先做簡單的」念頭，幾乎讓我們陷入一個耗費兩倍時間的窘境。

仔細看才發現，那個「簡單的參數問題」和另外兩個缺失事件，根本出自同一個根因：事件系統在早期規劃時就設計好了，但後來的實作只完成了一部分。如果我們先去修參數，等到補完缺失事件之後，那個測試可能還要再動一次。

更糟的情況是：如果我們在過程中發現了架構問題，才意識到不能這樣修，那前面所有的工作都白費了。

從那次之後，我們開始認真思考一件事：發現問題的當下，應該先做什麼？

分批思維的陷阱

「分階段處理」聽起來很有道理。把大問題切小，每個階段有進展，感覺有效率。但有一種分批方式是有害的——那就是在沒有做完整分析之前，就開始決定「先做哪個、後做哪個」。

這種模式的問題在於決策的依據是「哪個快」而非「哪個對」。

我們把這種思維方式稱為分批思維，它的表現形式通常是：

• 先修復簡單的，再處理複雜的
• 立即解決眼前問題，其他的之後再說
• 邊做邊看，問題浮現了再應對

這是一種短視的合理化。在壓力下，任何能「讓情況立刻改善一點」的選項都很誘人。但它的代價是：你可能一次又一次回到同一個地方修修改改，最終花了更多時間，卻在系統裡留下更多裂縫。

全局分析優先

我們現在的做法是：發現問題，先停下來分析，再決定怎麼做。

重點是在選擇修復路徑之前，先弄清楚幾件事：

這個問題影響了哪些檔案和模組？根本原因是什麼——設計就有缺陷，還是實作沒有完成？有沒有連鎖問題藏在後面現在看不到、之後才會浮現？

影響範圍不明、根因不清楚、發現多個相關問題——只要符合任何一條，就必須做完全局分析再動。影響範圍明確且確定是局部問題，才可以直接修。

策略規劃先行

全局分析之後，下一步是先把策略規劃完。

策略規劃的核心是：把全局分析中識別出的所有問題，都設計進解決方案裡，拆成可追蹤的任務，標清楚依賴關係，排好執行順序。

這裡有一個關鍵區分：

• 正確的分批執行：有完整策略，所有任務都設計好了，按優先順序一個個做。
• 錯誤的分批思維：沒有完整策略，邊做邊規劃，哪個容易先做哪個。

前者是系統性執行，後者是隨機應對。看起來相似，結果差很多。

策略規劃的品質可以用幾個問題來檢驗：這份策略涵蓋了全局分析識別出的所有問題嗎？每個任務的目標和範圍是明確的嗎？任務之間的依賴關係是清晰的嗎？有沒有哪個任務完成了，反而會讓另一個任務需要重做？

如果這些問題都能肯定地回答，策略才算完整。

設計問題和實作問題要分清楚

在判斷如何處理問題之前，有一個分類特別重要：這個問題是設計問題，還是實作問題？

設計問題指的是架構層面的缺陷，例如違反了分層原則、依賴方向錯誤、模組職責不清。這類問題的共同特徵是：就算把當下的錯誤「修掉」，根本的架構隱患還在，之後還是會以另一種形式冒出來。

實作問題指的是設計本身是對的，但程式碼還沒寫完，或者寫錯了某些地方，例如功能規劃完整但程式碼缺失、測試引用的事件類別還沒被建立、某個參數傳錯了。

這兩種問題的處理方式截然不同：

遇到設計問題，必須立刻停止功能開發，修正架構，然後再繼續。繞過去的代價是系統性的架構債務。

遇到實作問題，不需要停止，按照全局分析的結果規劃任務，依序補完就好。

混淆這兩類問題是一種常見的失誤。把設計問題當成實作問題來修，是最危險的一種——表面上解決了，實際上問題變得更隱蔽。

判斷的方法很直接：這個問題是違反了架構原則？影響了多個層級？如果是，優先考慮設計問題。如果問題是「功能設計完整但程式碼不在」，那是實作問題，按計劃處理即可。

用一個真實案例來看

回到我們開頭那個例子。三個整合測試出錯，表面看是測試引用問題，但全局分析之後的結論是：根因是事件系統在早期規劃了完整的事件，但後來只實作了其中一部分。這是實作問題，不是設計問題。

所以我們沒有立刻去修那個「簡單的」測試，而是先規劃完整策略：

第一階段，補全所有缺失的事件類別。這是架構基礎，必須先做，而且這些任務彼此獨立，可以並行處理。

第二階段，等事件類別都建好之後，統一修復三個測試檔案。這時候每個測試的修改都有完整的依賴可以對齊。

第三階段，執行所有整合測試，確認百分百通過，更新文件。

這個順序保證了每一步的修改只需要做一次，不會因為後來又發現新問題而需要回頭重改。

相比之下，如果我們走了「先修簡單的」路線，第一個測試會改兩次——一次修參數，一次等其他事件建好之後再調整引用。效率反而更低。

另一個例子是架構問題的處理。如果我們發現一個 UseCase 直接引用了 Widget，這是明確的設計問題——違反了 Clean Architecture 的分層原則。遇到這種情況，我們的做法是立刻停止其他功能的開發，重新設計 UseCase 的輸入輸出，用 DTO 來替代直接引用，修正依賴方向，然後才繼續之前的工作。

不處理，問題不會消失，只會越埋越深。

在實踐中保持這個習慣

這套方法論的難處在於在壓力下堅持。當測試出錯、當時間緊，「先修了再說」的衝動非常強。

我們找到的一個有效做法是：在決定怎麼修之前，強迫自己回答這幾個問題——影響範圍確定了嗎？根因清楚嗎？這是設計問題還是實作問題？策略有沒有涵蓋所有識別出的問題？

全部能回答，才開始動。有任何一個無法確定，繼續分析。

這個過程一開始會感覺很慢，但隨著熟練度提升，全局分析本身的時間會縮短，而且避免的重複修改和架構返工，帶來的時間節省遠超過分析的成本。

結語

這套習慣的核心只有一句話：速度不是決策依據，正確才是。

發現問題先全局分析，分析完先做策略規劃，遇到設計問題立刻停下修正，然後才開始執行。慢下來，才能真的快。