Johannes Brodwall

警告的困境#

你是否曾經看過一長串編譯器警告，然後心想「我真的該處理…但現在沒時間」？反過來，當一次編譯只出現一個孤零零的警告時，你是否直接修好了它？

零容忍政策#

當你從頭開始一個新專案時，沒有警告、沒有雜訊、沒有問題。但隨著 codebase 成長，如果你不注意，雜亂、警告和問題就會開始堆積。當噪音太多時，要在數百個不關心的警告中找到真正重要的那一個，就變得非常困難。

為了讓警告重新變得有用，作者嘗試對 build 中的警告採用零容忍政策（zero-tolerance policy）：

• 即使警告不重要，也要處理它
• 如果不是關鍵但仍然相關的警告，就修好它
• 如果編譯器警告潛在的 null pointer exception，即使你「知道」問題不會在生產環境出現，也要修好根本原因
• 如果內嵌文件（Javadoc 等）引用了已移除或改名的參數，清理文件

處理你不在乎的警告#

如果是你真的不在乎且確實不重要的警告，跟團隊討論是否能調整警告政策。例如：

• 為方法的參數和回傳值撰寫文件在某些情況下並不增加價值，那就不應該在缺少時產生警告
• 升級程式語言版本可能讓原本正常的程式碼產生新警告（例如 Java 5 引入泛型後，所有未指定泛型型別參數的舊程式碼都會警告）

不要等到需要大掃除才處理。當不想看到的東西出現時，立即處理——修復警告來源、抑制警告，或調整工具的警告政策。

保持 Build 乾淨的好處#

• 確保 build 永遠乾淨，就不必每次遇到警告都判斷它是否相關——忽略也是一種心智負擔
• 乾淨的 build 讓其他人更容易接手你的工作；如果你留下警告，別人要不就得費力篩選哪些重要、哪些不重要，要不就索性全部忽略，包括重要的那些

保持 build 乾淨不只是消除編譯錯誤或測試失敗——警告也是程式碼衛生的重要且關鍵的一部分。