背景

這場討論源於計算機科學傳奇人物 Brian Kernighan 的經典名言：「除錯的難度是編寫程式碼的兩倍。因此，如果你在寫程式時極盡聰明之能事，根據定義，你將不夠聰明去為它除錯。」這句話被視為對程式開發者的及時提醒，強調簡潔與可維護性遠比展現個人技巧更為重要。

社群觀點

在 Hacker News 的討論中，多數開發者對 Kernighan 的觀點深表認同，並將其延伸至程式碼審查與驗證的範疇。有觀點指出，證明大型程式碼庫中不存在初始化或生命週期等問題，其難度遠超編寫程式碼本身。然而，關於「測試」的必要性與實踐方式，社群內出現了顯著的分歧。部分開發者認為測試並非單純為了品質，更是為了提高開發效率，良好的測試紀律能引導出更易於整合與理解的設計。特別是在航太等高風險領域，自動化測試、虛擬環境模擬與硬體實驗室驗證是不可或缺的標準流程。

相對地，另一派聲音則對過度追求測試表示懷疑。有開發者分享在電商、數據轉換或伺服器編排領域的經驗，認為在這些變動快速且風險相對較低的環境中，手動測試或直接模擬使用者行為往往比撰寫單元測試更有效。他們觀察到許多 Bug 其實源於對業務邏輯的誤解，而非程式碼本身的錯誤，而這類邏輯問題很難透過自動化測試捕捉。此外，也有人批評測試驅動開發（TDD）可能導致開發者只為了通過測試而編寫程式，忽略了規格書背後的真實意圖，誤將測試結果當作完美的證明。

隨著人工智慧（LLM）的興起，討論也轉向了 AI 對除錯與開發動力的影響。支持者認為 LLM 擅長處理繁瑣的除錯工作，能快速找出隱藏在多層抽象中的低級錯誤；但反對者則擔心，過度依賴 AI 會導致開發者喪失精進技術的動力。如果 AI 產出的程式碼僅維持在平均水準，且人類不再具備超越 AI 的除錯能力，技術創新可能會陷入停滯。更有趣的爭論點在於，如果未來大部分程式碼都由 AI 生成，而 AI 又是基於人類現有的數據訓練，這種循環可能會導致訓練數據的枯竭與品質下降。

最後，部分資深開發者分享了對「聰明程式碼」的重新定義。他們認為真正的聰明並非使用晦澀的技巧，而是透過強型別、緊湊的依賴關係與直觀的命名來建立「防錯設計」。這種設計能讓 Bug 在開發階段就變得顯而易見，從而減少事後除錯的負擔。這種從「炫技」轉向「透明」的思維轉變，被認為是開發者成長過程中的必經之路。

延伸閱讀

• Kernighan's Lever：Linus Akesson 對這句名言的深度解析文章，被社群認為是最佳的註解。
• Unix 早期影片：Brian Kernighan 年輕時介紹 Unix 管道（Pipes）概念的珍貴影像，展示了簡潔組合工具的力量。