第1章：無瑕的程式碼

這是一本關於「程式品質」的書，在不同的領域、不同的語言，定義「品質」的指標、原則可能不同。但雜亂而品質低劣的程式碼，所造成的影響效應是相近的，最中肯的評述，就是序言所提的『唯一有效的的『程式品質』度量單位： (Code Review時)每分鐘罵髒話的次數(wtf/minutes)』。

程式感(code-sense)，是能寫出Clean Code的關鍵因素。有些人天生就富有程式感的天份，有些人則必須靠後天努力習得程式感。本書以物件導向的觀點，介紹一套程式好壞的評量準則。掌握一套基本的方法論，再輔以大量的原碼閱讀，見賢思齊、見不賢而內自省，終歸是培養程式感的不二法門。

雜亂的程式代價

當雜亂劣質的的程式碼充斥於專案中，開發團隊的產能將會逐漸下降，並形成一個惡性循環。軟體的複雜度與其規模總是呈現指數關系，當軟體模組間的交互關係越緊密，每一個變動所帶來的複雜度提昇也越大。所以在書中可以看到一個似曾相識的真實案例：軟體要改版了，而舊有系統的源碼所能提供的助益微乎其微，所有 PG 的產能日漸下降。

程式的專業

然後，書中歸納了幾位程式大師們對於 Clean Code 的看法：直白易讀的、沒有贅餘重複、所有測試完成、有著正規的錯誤處理機制。因為修改程式前的首要步驟就是讀懂程式本身，所以若需要維護的程式碼具備以上特性，我們理應感謝原作者對它的照顧 (即便這個原作就是自己)。 依據書中的估算，花在閱讀程式與花在寫程式的時間比例大約是10:1。所以，讓程式碼更容易閱讀 也才能讓新的程式碼變得更容易撰寫。專業的程式人員要謹記「破窗效應」與「童子軍原則」，前者讓事物日漸衰敗 ，後者讓一切日益美好。

心得

• 在程式碼的整潔與開發效率間，我們必須取得平衡。通常在 prototyping 階段，我只遵守一些最基本的準則，但在 naming、註解部分的品質會較粗略。因為這個階段，可能會有很多破壞性的嘗試，此時，我們的童軍精神應發揮在測試代碼的部分。直到第一次正式 submit code 之前，再進行一次重構與整理。
• 寫得再棒的程式產品，也有存在BUG的機率。區別是在整潔的室內除蟲，還是在荒郊野外捉蟲。

• 據說本書中文版賣得很好，在諸多討論區也是常被推薦的讀物，要求程式碼品質也是被朗朗上口的口號。但是為什麼還是時有看到 dirty code 以及抱怨 dirty code的討論串？可能是：

  1. 業界陳俗
  2. 有此體悟的程式設計者只是少數
  3. 感受得到好的程式風格，但就是寫不出來
  4. 存在 Clean Code 風格間的鄙視鏈

  我希望答案是４，但不幸的是，看來１、２較像是一般現況。

• 程式碼品質要團隊間的成員由上到下都有彼此共識，才能成形。如果有一個多人專案，其成品 source code 被評價為看起來就像是一個人寫的，那我相信這專案的品質多半是良好的。

• 基於程式設計的藝術性，CleanCode沒有十全十美的標準風格，只有正確的努力方向。

• 由於我們並非英文系國家，所以書中的部分範例與論點過於極端。若在本國環境推行時，應該可以做些調整。