為程式碼庫設一組號誌

團隊一大，程式碼庫就會慢慢鬆掉。同一個專案裡，有人每行都補分號，有人一個都不加；有人留下沒用到的變數，有人把外層已經用過的名字在內層再宣告一次；還有人送出非同步呼叫，卻沒有任何人接住它失敗的那條路。這些事今天都不會讓建置失敗，但半年後一定會有人為它們多花一個下午。程式碼審查抓不住這個量級的問題，因為它出現在每一次提交裡。

這套工具的作法很樸素。它把原始碼一句一句讀過去，逐條比對規則。每一條規則只負責一種樣式：沒被用到的名字、沒人接住的 promise、永遠為真的比較、永遠走不到的分支。命中時它報出位置、規則名稱與嚴重程度。嚴重程度這一欄最常被低估。規則不是等價的，如果每一條都喊得一樣大聲，這份報告的價值大約等於沒有報告。

規則寫在設定裡，不是寫在品味裡

它與前一代檢查工具最大的差別，是幾乎沒有任何一條規則是寫死的。每一條都能關掉、降成警告、升成錯誤，而且各自帶自己的參數。團隊不喜歡某種書寫習慣，關掉它，繼續做事就好；團隊被某一類缺陷坑過，把那條升成錯誤，之後不必再為它爭論。

擴充的模式也是同一個道理。框架專屬的問題留在自己的套件裡，不會被塞進核心：一套管與型別相關的檢查，一套管元件，其餘按框架或按測試框架分開。專案只安裝自己用得到的部分，設定檔因此保持簡短，因為裡面每一行都指向一條真正在跑的規則。

同一份規則集會被兩個地方消費。編輯器裡邊打邊報，滑過去看得到規則名稱，多數修正因此從一則審查意見變成幾秒鐘的動作。流程裡跑的是同一份設定，整座儲存庫走一遍，出現錯誤就讓建置停下來。編輯器抓的是作者腦中還有上下文時犯的錯，流程抓的是疲倦的人漏掉的部分。

這一代改了什麼

設定格式整組重寫。過去那種層層繼承的檔案串，靠擴充鏈接起來、靠所在資料夾隱含作用範圍，如今退場，換成一個扁平的陣列，每一項自己聲明套用到哪些檔案。好處是推論容易、除錯容易、載入也快；代價是一次性的搬遷，多數專案已經搬完。

自動修復的範圍同時擴大。相當比例的規則可以直接改寫有問題的程式碼，而不只是指出位置；改寫採保守策略，不會在沒人注意的時候動到行為。最沒有營養的那類審查話題，也就是縮排與引號，在存檔時修一次、提交前再修一次之後，基本上就消失了。

一套規則的價值，等於它背後那份共識的價值。工具能保證的只有一件事：一旦談定了，這份共識在當初談定的人全部調去別的專案之後，仍然繼續生效。

治理對這種無聊的基礎設施反而關鍵。專案掛在開放基金會底下，發版節奏可預期，重大變更另有公開政策，大型程式碼庫因此敢升主版本，不必為此把一季的功能開發凍住。

划算的地方，與不划算的地方

對個人來說，裝一套社群維護成熟的設定，等於在第一次提交之前就避掉一整類缺陷。對團隊來說，價值是另一種。寫在共筆裡的風格指南，只要事情不急就還有人看；同一份指南寫成規則，每一次推送都對每一個人執行，包括上週才加入的那位。

邊界也該用同樣的力氣講清楚。它比對的是語法裡的形狀，不是型別檢查器，也不是測試套件。它不會告訴你某個函式在執行時回傳了錯的形狀，不會告訴你某個功能壞了，也不會讓一個設計變好。一個有三百條規則卻沒有測試的儲存庫，仍然是一個沒有測試的儲存庫。

務實的順序勝過完整的清單。先從社群已經維護的那份設定開始，讓它只回報、跑一週，看實際上是哪些規則在響。抓到真問題的升上去，只製造噪音的關掉，剩下的定期重看。一條所有人都學會忽略的規則，比沒有這條規則更糟，因為它訓練整個團隊忽略報告。