別讓三個月後的你，痛恨現在的自己：重讀《Clean Code》

程式碼的終極目標：Clean Code 無瑕的程式碼

請問各位工程師夥伴，有沒有接過維護案呢？
三個月前由離職同事交接的專案？
又或者想不起來三個月前自己寫過的程式碼邏輯？

你打開那個專案，看到一堆 a、b、temp 這樣的變數名稱，還有長達 200 行的函式，裡面塞滿了各種邏輯。

你花了整整一個下午，才勉強理解這段程式碼在做什麼。
更慘的是，當你試圖修改一個小功能時，卻意外地搞壞了其他地方。

這不是特例，而是許多軟體專案的日常。
這就是「技術債」血淋淋的現實：程式碼能跑，但團隊已經失去維護它的勇氣。

《無瑕的程式碼－敏捷軟體開發技巧守則 (Clean Code: A Handbook of Agile Software Craftsmanship) 》這本書，正是為了解決這個問題而生的。

不過，我要先說實話：這本書有些觀點確實值得再思考，但對於剛開始寫程式的開發者來說，它提供了很好的「common sense」基礎。

程式碼的真相：80% 的時間在讀，20% 的時間在寫

程式碼的維護成本

根據統計，軟體開發中：

• 80% 的時間花在維護現有程式碼上
• 20% 的時間才是寫新功能

這意味著，你的程式碼被閱讀的次數，遠遠超過被撰寫的次數。 如果程式碼難以理解，就等於為未來的自己和團隊埋下了無數顆定時炸彈。

程式碼品質的經濟學：你的程式碼是資產還是負債？

壞程式碼就像一筆「技術高利貸」。

一開始，你為了快速上線，「借」了這筆債，感覺很爽快。但很快地，利息開始滾動：

• 第一個月： 改個小功能要花兩天，因為要先讀懂程式碼。

• 第三個月： 新來的同事不敢動你的程式碼，怕改 A 壞 B。

• 第六個月： Bug 層出不窮，團隊大部分時間都在「還利息 (Debug)」，而不是開發新功能 (創造價值)。

• 一年後： 利滾利，債務高築，團隊最終只能痛苦地宣告：「這專案沒救了，我們重寫吧。」——這就是技術債的破產清算。

好程式碼則像一筆「優良資產」，會持續增值。
一開始投入的時間稍多，但它清晰的架構會讓後續的維護、擴充變得極其高效，為團隊帶來長期的複利效應。

從新手到大師：程式碼品質的三個層次

1. 第一層：讓程式碼能跑 (The Survivor) 新手時期，我們最大的目標就是讓功能動起來，看到畫面上出現 Hello World 就是最大的成就。這是生存模式。

2. 第二層：讓「別人」能讀 (The Team Player) 當我們開始團隊合作，就會意識到程式碼不只寫給自己。我們開始寫註解、遵守團隊規範，目標是讓隊友能順利接手。這是合作模式。

3. 第三層：讓「程式碼」自己表達意圖 (The Craftsman) 這是 Clean Code 追求的最高境界。我們不再依賴註解，而是透過精準的命名、清晰的架構，讓程式碼本身就像一篇流暢的文章，直接講述它的商業邏輯。這是工匠模式。

Clean Code 的批判性思考

值得採用的原則

1. 有意義的命名

好的命名自帶註解，直接說明了變數的單位與意圖。

• (Before)

  // d: elapsed time in days
  let d = 10;
  

• (After)

  let elapsedTimeInDays = 10;
  let daysSinceModification = 10;
  

2. 函式應該只做一件事

• (Before: 一個函式處理所有事)

  function handleUserProfile(user) {
    // 1. 驗證使用者資料是否合法
    // 2. 將資料存到資料庫
    // 3. 發送歡迎 Email
    // 4. 更新使用者登入狀態
  }
  

• (After: 拆分成小函式)

  function handleUserProfile(user) {
    validateUserProfile(user);
    saveUserToDatabase(user);
    sendWelcomeEmail(user);
    updateUserLoginStatus(user);
  }
  

3. 避免重複（DRY 原則）

需要批判性思考的原則

這本書最珍貴之處在於啟發思考，而非提供標準答案。

1. 函式長度限制

• 書中建議： 函式不應該超過 20 行
• 我的觀點： 重要的是函式是否單一職責？而不是行數。

2. 參數數量限制

• 書中建議： 函式參數不應該超過 3 個
• 我的觀點： 過多的參數確實是警訊，但關鍵是參數的關聯性。如果 4 個參數是構成一個完整概念所必需的，那把他們封裝成一個物件會更好。

3. 註解的價值

• 書中建議： 好的程式碼不需要註解
• 我的觀點： 有些過於複雜反直覺的業務邏輯，註解是必要的，寧可先多寫起來。

實務中的 Clean Code：團隊協作的角度

• 好的 Code Review 關注：

  1. 可讀性： 這段程式碼的意圖是否清晰？

  2. 可維護性： 未來修改這個邏輯的成本高嗎？

  3. 一致性： 是否符合團隊既有的架構與風格？

• 不好的 Code Review：

  • 只糾結於排版、分號等小問題（這些應交給 Linter 自動化工具）。

  • 缺乏對業務邏輯的討論。

程式碼品質是 empathy 的展現

追求 Clean Code，從來都不只是技術上的潔癖。
它更像是一種修養與 empathy（同理心） 的展現。

• 對未來的自己有同理心： 你不希望未來的你，為了 debug 而痛罵現在的自己。

• 對同事有同理心： 你希望你的程式碼，對接手的同事來說是一份清晰的東西，而不是一個待解的炸彈。

實務建議

• 從命名開始： 時刻問自己，這個命名能表達意圖嗎？

• 小步重構： 每次修改程式碼時，都順手讓它變得比原來更乾淨一點。

• 團隊共識： 建立團隊的 Coding Style Guide，讓所有人有共同的語言。

你不是在寫程式碼，你是在與未來的自己和同事對話。
讓這場對話，盡可能地清晰、友善且高效。

明天我們來聊聊，如何用演算法思維來解決生活中的各種問題。

#CleanCode #程式碼品質 #工程師修養 #程式設計 #吳桑泥的升級書單