WORK STORY / 01
用 AST 計算多白牌系統的修改影響範圍
情境
同一份程式會依不同品牌覆寫、組合與動態載入；修改一個共用檔案後，真正受到影響的可能不只是某個 Component，而是散落在不同品牌設定、Router 與 Runtime Config 背後的一組實際 URL。當時這類影響範圍主要依賴工程師人工判斷，QA 也需要根據既有經驗決定回歸測試範圍。我認為真正的問題不是「誰 import 了這個檔案」，而是 Code Dependency 與使用者實際進入的 Route 之間存在資訊斷層。
我的判斷與做法
我把問題重新拆成一個 Dependency Tracing 問題。先以 ts-morph 解析 Import、Alias 與 Router，建立靜態依賴關係；再透過 vite-node Sandbox 載入各品牌 Runtime Config，補上單靠 AST 無法得知的白牌組合資訊。最後從 Target File 向上追蹤引用鏈，將程式碼依賴一路還原成：哪些品牌、哪些 Route、哪些實際 URL 會受到這次修改影響。
形成的結果
工具可以從指定檔案輸出各品牌實際受到影響的 URL，讓 Frontend 與 QA 能以相同資訊判斷測試範圍，而不再完全依賴人工盤點與個人記憶。對我而言，這不只是省下查找時間，而是把原本存在工程師腦中的系統知識，轉成可以被程式重複計算的結果。
留下的思考
這件事讓我開始對「只能靠資深工程師記得」的系統知識保持警覺。當一個專案複雜到「修改這個檔案到底會影響哪裡」需要靠經驗回答時，問題不只是文件不足，而是有一段重要的系統關係還沒有被模型化。能由程式推導的資訊，我傾向讓工具去計算，而不是長期要求人把整套系統記在腦中。