2026-06-03
有限狀態機改變了我閱讀程式碼的方式
有限狀態機（Finite State Machine，FSM）是我學過最有用的概念之一，它幫助我理解軟體架構。
乍看之下，FSM 像是一個學術概念：
- 一個系統有一組狀態。
- 事件會觸發狀態之間的轉換。
- 系統會根據目前的狀態有不同的行為。
聽起來很簡單。
但隨著時間過去，我開始發現，很多軟體系統都可以用同樣的角度來理解。
狀態與狀態變化
閱讀一個 codebase 的時候，我常常問兩個問題：
- 狀態存在什麼地方？
- 狀態是怎麼改變的？
就這樣。
用程式的語言來說：
- 狀態：變數、資料庫紀錄、application store、檔案
- 狀態轉換：function、method、action、API call、使用者互動
幾乎每一段程式碼，都是為了儲存狀態，或改變狀態。
使用者按下一個按鈕。
狀態改變。
API request 進來。
狀態改變。
機械手臂移動到某個位置。
狀態改變。
資料庫紀錄被更新。
狀態改變。
細節可能不同，但背後的模式其實很一致。
透過狀態理解架構
遇到一個不熟悉的 codebase 時，我現在不會從每個檔案開始讀。
我會先找狀態。
source of truth 在哪裡？
它存在 React state 嗎？
Redux？
資料庫？
PLC？
robot controller？
一旦知道狀態存在什麼地方，我就會追蹤它如何改變。
誰可以修改它？
哪些 action 會觸發這些改變？
改變之後會產生哪些 side effect？
沿著狀態的流動看下去，架構就會慢慢浮現出來。
AI Coding 的時代
我覺得在 AI-assisted programming 的時代，這件事會變得更重要。
寫程式正在變得更便宜。
讀程式正在變得更有價值。
AI 可以在幾秒鐘內產生幾百行程式碼。
但仍然需要有人理解：
- 這段程式碼應該放在哪裡？
- 它會影響哪個狀態？
- 應該由哪個 action 觸發？
- 它屬於現有架構的哪一部分？
瓶頸不再是打字寫程式。
瓶頸是理解系統。
一個實用規則
每次打開一個新的 codebase，我都會先做一個簡單的練習：
找到狀態。
找到改變狀態的東西。
接下來的其他部分，通常就會變得比較容易理解。
這不是一個完整的軟體架構模型。
但它常常是理解一個架構最快的路。