David Wood — Fredericksburg, Virginia, USA

「聰明」程式碼的兩面性#

開發者常常被要求創造奇蹟——用巧妙的方式讓現有程式碼與老舊的 legacy 系統整合，通過技巧和創意寫出大量「聰明」的程式碼來完成任務。然而，越聰明的程式碼，往往意味著越長的程式碼行數與越高的複雜度，埋下未來維護的隱患。

注意： 程式碼太「聰明」，最終會難以維護。後來接手的開發者看不懂程式碼，就無從維護起，最終只能進行代價高昂的重寫。

允許探索新語言與工具#

如果你是剛進入軟體開發領域的專案經理，不要害怕讓開發者探索新的程式語言和開發工具。這是他們發現改善程式碼實踐與成果的途徑。他們可能設計出更快、程式碼更少的解決方案，對專案更有利。

現代的創新程式語言，往往能以少得多的程式碼行數完成相同功能：

• 更簡單的程式碼結構，更易於測試
• 可自我定義，更具可讀性
• 儲存空間更小
• 更易於長期維護

引入新語言前的評估清單#

在組織內部引入新語言或平台，需要謹慎考量：

• 這個新程式碼能否真正解決當前軟體的問題？
• 能否與現有 legacy 資料庫、使用者介面和第三方軟體長期相容？
• 團隊或部門中是否有其他開發者能使用這個語言？
• 語言作者是否提供充分的產品支援和及時更新？

評估捷徑： 如果新語言能追溯到 C 或 Java 等主流語言的脈絡，整合進現有實踐通常相對順暢。

文件是維護的生命線#

無論引入多新穎的做法，都必須在程式碼中記錄新的實踐。否則，程式碼庫與文件會逐漸背離，最後只能靠閱讀程式碼本身來理解系統——這稱為軟體元件與系統 metadata 之間的「耦合失效」（loss of coupling）。文件不足的系統，最終命運往往是被迫全面替換。

核心原則： 鼓勵開發者創新，但不要「聰明」到複雜過頭。任何開發者試圖用過度複雜的程式碼來鞏固自身職位，對專案經理而言百害而無一利。可讀性才是真正的技術資產。