我們用 SMART——Specific（具體）、Measurable（可衡量）、Achievable（可達成）、Relevant（具關聯）、Time-bound（有時限）——把每個故事拆成五天，作為每次動手造輪子前的五個檢查問題。

本篇是故事一「客戶要加個按鈕切換 LED 呼吸燈，一個月後 RD 還在談 CMSIS 與 Clean Code」的 Achievable 篇：利用現有工具與最小變更，做得到嗎？

本篇定位：討論如何以最小必要變更完成需求，而不是從最理想的架構開始。

當時發生了什麼

驗收表攤開之後，下一個問題自然是：怎麼走到那裡？會議室裡很快出現標準答案：「這份程式沒辦法直接加東西，要先整理。」理由大家都聽熟了：驅動和應用邏輯攪在一起、沒有狀態機框架、命名新舊混雜。先把分層與框架搭好，按鈕自然水到渠成。

奇怪的是，「非重構不可」這個主張從來沒有被驗證過。沒有人打開程式碼，指著某一段說：按鍵事件會被這裡擋住。倒是有人私下花了一個下午把相關程式讀完，看到的和印象不太一樣：LED 早就有控制函式，開機自檢會用它閃燈；有現成的毫秒級 timer；主迴圈雖長但看得懂。真正缺的只有四樣：按鍵的 GPIO 輸入、去彈跳、記住目前燈效的狀態變數，以及呼吸效果本身。

真正的問題在哪裡

「要先整理才能改」聽起來像工程判斷，其實是個沒被測試過的假設，而且永遠不會被證明是錯的——只要整理還沒完成，就輪不到「改」出場檢驗。

兩條路的風險結構完全不同。先重構再加功能，是把風險全部前置：那份程式碼再醜，承載的都是在客戶現場跑了很久的行為，是專案裡最值錢的資產；大規模搬動等於把這筆已驗證的存款領出來重新賭一遍，而這次交付要買的只是一顆按鈕。最小變更則讓風險只落在被碰到的路徑上。

「做得到嗎」在會議室裡被偷換成了「做得漂亮嗎」。前者的答案藏在既有程式裡，要去讀、去試才知道；後者的答案永遠是否定的，所以永遠能支持再整理一輪。判斷一份程式能不能安全加功能，唯一的辦法是指出具體擋路的段落。

可以怎麼做

後來我自己重做一次，順序是這樣的。

先盤點，而且要盤到能動手的細度。「有 GPIO 可以用」不算盤點完成：按鍵那一腳是按下接地還是接高、要不要開內部上拉或下拉、這支腳有沒有和其他功能共用（燒錄腳、既有指示燈都很常見）。沒查清楚就動手，症狀往往是「板子上好好的，機器上偶爾亂跳」。

呼吸效果也在這一輪看清楚。它掛在 PWM（pulse width modulation，脈寬調變）上，但佔空比從零線性掃到滿，看起來並不均勻：人對亮度的感知接近立方根關係，暗處敏感、亮處遲鈍，線性掃描會先快後慢，後段像卡住。要做出視覺上均勻的呼吸，得補一層 gamma 校正（工程上常取 2.2 到 2.5），或放一張亮度查表。這是整件事裡唯一真的要新學的部分，而它跟分層無關。

盤點的產出是一張兩欄清單：已有什麼可重用、缺什麼要新做，把「這程式很亂」的印象換成排得進時程的事實。

再切一條垂直切片（vertical slice）：寬度最窄，深度貫穿輸入到輸出。先做「短按切換常亮與熄滅」——一顆按鍵、兩個狀態，但從按鍵讀取、去彈跳到 LED 輸出全部到位，對應驗收表前幾列；跑通再加呼吸。切片讓真問題提早現身：中斷若真的衝突、主迴圈若真的被忙等（busy-wait）延時塞死，第一天就會撞上，不必等框架蓋完才發現。前面把技術債分成擋路與不擋路兩堆，卻沒說怎麼分；切片就是分法——擋不擋路由這條路自己回答。

切片也順帶回答了狀態機那一題。三個狀態、一個事件，需要的是狀態機這個做法：一個列舉型別、一個轉移函式、一個狀態變數，同一個檔案就寫得完；需要的並不是一套狀態機框架。做法今天就能用，框架得先設計、再實作、再說服全隊照它寫。

最後，給重構設准入條件：只有實際擋住切片的程式才就地整理，範圍以「讓這條路通過」為界。忙等延時如果真的讓呼吸效果插不進主迴圈，就整理那一段；其餘不擋路的，寫進工單描述或待辦。

最小變更是風險控制：改得少，回歸測試範圍就小；切片照樣要過驗收與審查，去彈跳照樣要做對。反過來說，先抽介面也有划算的時候：如果這份韌體接下來要支援好幾種機構的按鍵配置——不同腳位、不同接法、有的兩顆有的一顆——那把按鍵輸入抽成一層介面就值得，它服務的是已經看得到的第二、第三個使用者。

今天學到的事

「要先整理才能加功能」是這個故事裡最貴的一句話——它太像負責任的工程判斷，以致沒有人要求它出示證據。垂直切片是對它最便宜的測試：讓最短的使用路徑先跑通，真正擋路的技術債會自己浮出名單，而名單幾乎總是比想像的短。

不過，就算按鈕動起來了，有個聲音也不會消失。散會前真的有人問了一句：「所以 CMSIS 和 Clean Code 就這樣算了嗎？」問的人沒有挑釁的意思，比較像失落。這句話值得一個認真的回答，而我當下答不出來。