[2019 COSCUP 精彩時刻之三] 前端開發的再次典範轉移 – 如何走出混亂並讓複雜變的可掌控

作者：林冠廷｜編輯：OCF Lab | Photo by COSCUP

2020 COSCUP 開源人年會即將在 8月第一個周末登場，在這之前，先來看看特派記者筆下， 2019 COSCUP 有哪些精彩時刻。

年會議程共分入門、中階、進階三種等級，此場議程即以入門程度解釋狀態管理方案 (State management)。

「人們使用的狀態管理手法有重大缺陷！」

2019 年 1 月 28 日，世界首屈一指的軟體開發商蘋果公司被指控：如果 iPhone 使用者利用 FaceTime 撥打電話給另一個人，對方都還沒有接起電話，就可直接聽到聲音。雖然其肇因可能僅是工程師漏了一行程式碼，好讓手機在接聽電話後才開啟麥克風；但做為一個龍頭企業的電話服務，FaceTime 的核心功能出了大包。

短短一行程式碼，就讓蘋果聲譽重挫——客戶抱怨、股價大跌，更不用說事件隔天就是蘋果高層向華爾街投資人進行投資會報的日子。出身台灣，在美國工作的呂維德，一邊講著這個故事，一邊笑著要大家想像蘋果在投資會報時，執行長 Tim Cook 的臉色有多難看；但他也認為，傳統的軟體開發流程，無論工程師再強，這種問題都無法避免。面對滿座的軟體工程師，呂維德提出了最殘酷的問題：「你的命運會比那一缸子的菁英好嗎？你會不會有一天也忘記　if、else？」他說，軟體開發流程再好，但目前的流程本質就是會帶我們下地獄，因為我們「無法根絕自己不能預見的問題」。

COSCUP 入門議程之一：要避免程式出錯？旅美工程師分享好解法。

● 議程說明、投影片、錄影

這次呂維德來到 COSCUP 2019 分享，就是因為他已經找出一套「完美解法」，讓程式的狀態管理不再出錯－－這個解法就是他口中「你以為你懂」的「狀態機」(FSM, finite state machine)。在呂維德實際測試的狀態機「Statecharts」中，它不僅可以描述程式中的狀態，更包括每個狀態所允許的後續操作。

曾經，Redux 前端狀態管理紅極一時，可惜隨著時間，其函式庫的問題也不斷暴露。「從一包狀態轉換到下一包狀態，我無法控管轉出來的這包狀態，裡面到底是對的還是錯的」，呂維德說，很多人能寫不同 reducer，所以若菜鳥寫錯了，後面接續的新進程就會整個跟著出錯。但只要從 Redux 換成狀態機，能將狀態分開（切片）處理，就可以減少一大包裡面有錯不知怎麼辦的問題。

狀態機的概念在 1943 年發表，放眼航太、醫療、金融等領域，早就不是新技術，幾十年來，狀態機在各個領域的應用中證明了自己相當可靠。雖然前端開發晚了一甲子才遇到狀態機，但呂維德表示，晚來也有晚來的好處：傳統狀態機在面對太多程式狀態，就會「狀態爆炸」，產出看不懂的狀態圖；如今，呂維德引進了他稱為「狀態機加強版」的「Statecharts」，利用樹狀化結構與外連的設計，可以避免狀態爆炸，也讓狀態機的應用空間更大。

不只是前端，狀態機在後端也可以使用。呂維德說，狀態機可以把狀態切片管理、開發速度快、便於除錯，若開發者能強迫自己確實思考過產品的運作方法，就能將商業邏輯封裝在狀態機之中，只要學會 JavaScript 與基礎框架就能寫 UI，因此使用者介面 (UI) 不再是開發重點。也就是說，資深開發者能夠全力設計商業邏輯與狀態機；而資淺的菜鳥就算全權負責 UI，因為 UI 不再重要，出了錯也不至於對團隊造成太大傷害。
對於呂維德而言，2019 年將是前端世界繼 2013年「從 jQuery 到 Thinking in Component」的大改變以來，再一次的天翻地覆，成為「Thinking in State (chart)」的新時代。究竟前端開發是否會如呂維德的預期而有所變革？在拭目以待的同時，有興趣的讀者，可以加入呂維德的臉書社團「Statecharts」一探究竟。