【讀後心得】Clean Code - 軟體工程師聖經之一
這本書讀到最後，最精華的部分莫過於作者 Uncle Bob 整理的「啟發（Heuristics）」清單。它像是一面照妖鏡，反映出我們日常開發中不經意留下的技術債。為了方便日後複習，我將書中的重點與常犯錯誤整理成這份清單。
一、 註解的藝術：程式碼應該自我解釋
註解通常是為了彌補程式碼表達能力的不足。如果程式碼夠清楚，註解往往是多餘的。
避開不適當的資訊： 註解應該存放技術心得或決定理由，而不是版本紀錄或作者資訊（那是 Git 的工作）。
清理廢棄與多餘的註解： 過時的註解比沒註解更危險，因為它會誤導開發者。
拒絕被註解掉的程式碼： 這是最該避免的！如果程式碼不再需要，請直接刪除。Git 會幫你記得它。
寫得不好的註解： 避免廢話（例如：
i++; // i 加 1），要寫就寫「為什麼」這麼做，而不是「怎麼做」。
二、 函式：專注於「一件事」
函式是程式的最小邏輯單位，混亂通常從這裡開始。
參數精簡化： 盡量不超過 2 個參數。**旗標參數（Flag Arguments）**是大忌，因為它明示了這個函式做了「不只一件事」。
輸出型參數的陷阱： 習慣上我們預期參數是輸入。如果要改變狀態，應該改變它所屬物件的狀態（
object.update()而非update(object)）。說到做到（Do One Thing）： 函式名稱如果是
renderPage()，它就不該順便saveSession()。副作用（Side Effects）必須在名稱中體現。避免傳遞性導覽： 也就是所謂的「火車連結」。程式碼不該出現
a.getB().getC().doSomething()，這代表 A 過度了解 B 與 C 的內部結構。
三、 命名：代碼的靈魂
好的命名能省下好幾行註解。
範圍與長度成正比： 區域變數（範圍小）可以用短名；全域變數或大範圍使用的變數，名稱必須夠長且具備描述性。
標準命名法： 整個專案應該有一套共通語言。如果你用
fetch拿資料，就不要在別的地方用get或retrieve做同樣的事。描述副作用： 如果一個函式會初始化連線並回傳資料，別只叫
getData()，應該考慮createConnectionAndFetchData()。
四、 測試：程式碼的最後防線
沒有測試的程式碼就是「壞掉的程式碼」，只是你還不知道而已。
邊界條件是關鍵： 測試不要只跑快樂路徑（Happy Path），要針對
0、null、empty或極大值進行測試。詳盡測試錯誤附近： 臭蟲喜歡聚在一起。如果你在某個函式發現錯誤，那它的上下游通常也藏著問題。
速度必須快： 如果測試跑一次要五分鐘，開發者就不會想跑它。慢速的測試最終會被遺棄。
五、 一般性常犯錯誤 (Heuristics)
這些是開發中最容易被忽略的細節：
重複程式碼（DRY）： 這是萬惡之源。只要看到重複，就該考慮抽象化。
不一致性： 如果你在一個類別用
req代表 Request，另一個類別就不該用request。保持一致能降低認知負擔。被遺棄的程式碼： 沒被呼叫的函式、永遠不會進入的
if區塊，請果斷刪除。選擇型參數： 盡量避免在函式中使用選擇性參數，這通常代表函式邏輯可以被拆分。
結語：童子軍規則
最後，我想補充書中最重要的核心心法：「離開現場時，要比你進來時更乾淨。」 (The Boy Scout Rule)
我們不需要一次就把整份爛程式碼重構完，但每次修改 bug 或新增功能時，順手改掉一個爛命名、刪掉一個廢棄註解。持之以恆，程式碼就不會走向腐化。
