低耦合高內聚不是口號：真正難的是在速度、技術債與可接手性之間做取捨
Threads 用四種工程結果與 Coupling × Cohesion 四象限說明架構設計：最快但散、集中但黑盒、過度拆分、以及低耦合高內聚的理想狀態。本文補上真正進階的判斷：低耦合高內聚是長期維護最佳，但不是任何情境下唯一最佳；關鍵是知道何時寫好、何時留債，以及債是否能被重構。
這則 Threads 講的是架構設計裡很常被簡化的口號：低耦合、高內聚。原文真正有價值的地方，不是說「第四種最好」而已，而是補了一句更成熟的判斷：低耦合、高內聚是長期維護最佳，但不是任何情境下的唯一最佳。工程師的進階能力，是能在時程、風險、團隊、生命週期之間做取捨。
原文把同一個功能交給不同人做，最後會出現四種結果。
四種常見結果
第一種：最快，但散。
不想太多直接開幹，短期最快上線。但一個月後需求變動，邏輯散落在很多地方，沒有人知道全貌，連原作者也很難追。最後不是修，是重寫。
這通常是高耦合、低內聚：功能沒有清楚邊界，變更會到處牽動。
第二種：最穩，但在一個人腦袋裡。
所有邏輯放在同一個地方，改得到、找得到；前提是原作者還在。他一離職，功能就變成黑盒子，其他人不敢動，只敢疊。
這是高內聚但也高耦合，常見形式是 God Object / 巨型模組。不是「集中」本身有錯，而是知識集中在單一模組與單一人身上，導致團隊不可維護。
第三種：最有原則，但過度拆分。
讀很多書，模組拆得很乾淨，每個職責分明，看起來符合設計模式。但改一個需求要動很多地方，接手者要先看好幾小時。Code review 過了，QA 還是回報漏改。
這是低耦合但低內聚，也就是破壞性解耦。表面上很乾淨，實際上業務流程被拆得太碎，認知成本過高。
第四種：最沒存在感，但最容易接手。
動手前多問了幾個問題，中途重構幾次，比預期多花幾天。PM 不一定理解為什麼慢。但一段時間後，其他人接手當天就能改；新需求進來調整幾個地方就能發 PR；code 簡單到 junior 也看得懂，原作者不在也沒差。
這才是低耦合、高內聚的理想狀態：相關邏輯放在合理切片裡，不相關邊界彼此隔離，團隊可以接手與演進。
圖片四象限補充
原文附圖用 Coupling × Cohesion 畫出四象限：
- 高耦合 / 低內聚：Poorly Chosen Boundaries。模組依賴混亂，功能分散，改一處引發連鎖反應。
- 高耦合 / 高內聚：God Object。所有功能集中在單一巨大模組，難拆、難測、難重用。
- 低耦合 / 低內聚：Destructive Decoupling。為拆而拆，功能過度分散，開發一個小功能要在無數地方跳轉。
- 低耦合 / 高內聚：Ideal Situation。相關功能組織成清楚的 Slice，彼此依賴少，易維護、易擴展、可獨立開發。
圖中底部也點出設計重點：以 Feature 為單位建立清晰邊界，讓每個 Slice 都能獨立演進。
留言區的高價值補充
留言裡有人提到前端狀態管理很有感：很多 store 或 API query 單看功能很像，直覺會想集中放同一個地方；但如果它其實跟 domain data 與商業邏輯互動很深，最後反而會選擇放到各自 page / feature 底下，方便開發者就近查找。
這個補充很關鍵。很多架構爭論不是「集中 vs 分散」，而是「這個東西的變更原因跟誰一起變」。
如果兩段 code 經常因為同一個需求一起改，它們應該靠近。若只是技術形狀相似，但業務生命週期不同，硬放一起只會讓未來變更互相污染。
作者也補一句：「而且未來重構改得動、測得了。」這是技術債能不能留下的分水嶺。
更成熟的判斷：不是永遠追求第四象限
原文第二則補充非常重要：低耦合、高內聚是長期維護最佳，但不是任何情境最佳。
情境不同，合理選擇也不同：
- 一次性 prototype：可以接受第一種快速但粗糙，只要清楚它會被丟掉。
- 需求還在探索：可以先留一些債，但要讓債能被重構，不要變成永久黑盒。
- 核心業務流程：應該逐步往第四種靠攏，因為維護期會遠長於開發期。
- 團隊多人協作：比起個人聰明，接手容易、測得動、改得動更重要。
- 高風險模組：寧可多花時間切清楚邊界與測試，不要追求第一天速度。
好的工程師不是永遠寫最漂亮的架構，而是知道什麼時候該寫好、什麼時候可以留債、什麼債可以安全留下、什麼債一留下就會害死人。
對 BigIntTech / 工多多的判斷
這篇很適合放進工程管理與 code review 的判斷框架。
我們在工多多、Silver Spoon、SoulMate 這類長期專案裡，最怕的不是單一功能寫慢一點，而是：