Filip van Laenen

編碼規範的常見困境#

你可能經歷過這樣的場景：專案啟動時，每個人都有滿滿的好意——這些「新專案的決心」被寫成文件，其中關於程式碼的部分成為了編碼規範。在啟動會議上，每個人都同意遵循。然而一旦專案真正開始，這些好意就逐一被拋棄。專案交付時，程式碼一團混亂，沒有人知道怎麼會這樣。

問題出在哪裡？很可能從啟動會議就開始了：

• 有些人沒有認真聽
• 有些人不理解也不認同
• 有些人已經在計畫自己的「編碼規範叛變」
• 當壓力來臨時，格式規範就被犧牲了

為什麼需要自動化#

格式良好的程式碼不會讓客戶多給你分數，手動遵循規範又很枯燥。因此，解決方案不是更多的文件，而是自動化。

如果編碼規範沒有被自動化執行，它就只是一份沒人遵守的文件。

自動化的具體做法#

• 程式碼格式化納入建構流程：確保每次編譯時自動執行格式化
• 靜態分析工具：掃描程式碼中的反模式（antipattern），發現問題就中斷建構
• 自訂規則：設定工具掃描專案特有的反模式
• 測試覆蓋率自動檢查：不只測量覆蓋率，還要在覆蓋率過低時中斷建構

無法自動化的部分，整理成一份輔助性的指引文件，作為自動化規範的補充，但也要接受團隊不一定會嚴格遵循。

規範應該動態演進#

編碼規範不應該是靜態的。隨著專案演進和需求變化，初期看似明智的決定，幾個月後未必仍然適用。讓規範與專案一同成長。