Engineering · 1 min read
在教訓褪色前，把它寫成規則
八個除錯教訓如果只留在某人腦袋裡，等於沒學到。我們把它們提煉成 code review 原則，更新到 plugin 裡。
八篇文章，一場連鎖反應。事後看來教訓很清楚，但事後的清醒會褪色。半年後，下一個要升依賴版本的人不會記得這個故事。他們會走跟我們一樣的路：信任測試、釘版、跳過 EOL（End of Life，官方停止維護）檢查。
解法不是「記住教訓」，而是把教訓變成自動觸發的檢查點，在 PR 合併前就攔住。
學到的，壓縮版
- 版本升級會連鎖。 升語言版本會移動 base image，base image 移動系統函式庫。
go.mod裡的一行動了三層（總覽）。 - 手動拼湊之前先查矩陣。 你要的組合通常已經發布了（查 tag 矩陣）。
- graft 是解決真實缺口，不是猜測的。 先驗證需求再堆複雜度（graft）。
- 逐層下降隔離時，也要變動輸入。 逐層下降走程式碼軸，輸入變異走另一軸（逐層下降）。
- 被污染的 oracle 會反轉你的診斷。 嚴謹用在壞測試上只會更有信心地確認錯誤（oracle）。
- 符合規格的最佳化看起來像 bug。 GIF 編碼器合併相同影格不是回歸（regression：更新後壞掉的行為）（GIF 編碼器）。
- 測試結果是關於輸入的事實，不是關於系統的。 做結構性決策前，先用生產形態的輸入重新驗證（FACT）。
- 「最後已知好」可能等於 EOL。 落在 EOL 上的釘版，用真實的安全修補換了一個不存在的修正（釘版、EOL）。
從教訓到 review 原則
我們把這些提煉成具體的 code review 檢查點，更新到 code-reviewer plugin（版本 1.0.0 → 1.1.0）。這次更新新增了：
- 依賴連鎖感知 — 一次版本升級有沒有連帶動到隱式的下游依賴？
- 測試輸入有效性 — 測試用的是生產形態的輸入，還是可能遮蔽或反轉真實行為的人造資料？
- 釘版衛生 — 版本 pin 有沒有退場計畫，釘住的目標還在支援中嗎？
- EOL 偵測 — base image 或依賴的分支還在收安全修補嗎？
這些不是格式檢查。這是結構性的問題，用來防止團隊花好幾天除錯一個不存在的問題。
一次事件的教訓有價值。但能撐過事件、變成 review 原則的東西，才是真正能防住下一次的。
Related： 回到連鎖反應總覽。