可維護性訊號：耦合、命名與測試空洞

可維護性很難一次量化，但審查時有幾個穩定訊號：業務規則是否散落在 UI 層、網路層是否直接依賴畫面狀態、以及「工具類」檔案是否變成無所不包的雜物間。

命名也是線索。若同一概念在不同模組有三種叫法，後續改需求時幾乎必然漏改一處。我們會抽樣追蹤一個核心實體（例如訂單或會話）在程式中的流轉，記錄斷點與重複定義。

測試空洞不一定代表零測試，而是關鍵路徑沒有自動化保護。登入、付款相關狀態、離線同步與權限拒絕路徑，往往是最該有回歸網的地方，卻最常只靠手動。

報告裡我們用嚴重度與「改動半徑」描述問題：修一處會牽動多少檔案、是否需要產品決策。這樣工程主管才能把重構排程與業務節奏對齊，而不是收到一長串風格建議。