作者首先提到程式碼是一種用來被明確說明需求的文字，擁有「描述細節的精確性」，這種性質使得程式碼永遠無法被一些方便的軟體套裝工具取代。
而撰寫「好」的程式碼是非常花時間的，理論上閱讀舊的程式碼的時間比真正撰寫程式碼的時間多出 10 倍，因為你必須非常清楚舊有架構才能使他易讀，並進行重構。
但是撰寫「不好」的程式碼是更花時間的（後面 Debug 的時間跟講 WTF 的時間），造成產能下降，書中甚至提到劣質的程式碼讓一間公司倒閉的案例。
既然不好，為什麼大家都還要寫劣質的程式碼？
- 上層在催你，你有時間壓力
- 你可能厭倦寫這份程式碼，不想重構它，想要跑得過就好
- 你不懂得什麼是好的程式碼，以及該如何撰寫它（我）
但前面及此處強調的觀念是：製造爛的程式並不會讓你趕上 Deadline，反而會讓你後面開發速度變慢而錯過 Deadline。
那 Clean Code 是什麼？
每個人對於 Clean Code 的定義有所不同，於是作者訪問了許多資深程式設計師的看法，以下為我自己節錄書中一些能被「具體」描述的重點（其它部分是偏向抽象的感覺）：
- 只專注做好一件事，每個函式、類別、模組等只表達單一的意圖
- 說明事實，不該使人胡亂猜測設計者的意思
- 沒有重複的程式碼
- 使用有意義的名稱
- 能夠通過所有測試
- 可以被作者以外的人閱讀跟增強
而本書作者認為：「減少重複、具有高度的表達力，並且及早建立簡單抽象概念」即為 Clean Code。
總結
這一章節主要講解了撰寫劣質的程式碼會有什麼後果，以及帶出什麼是 Clean Code，為本書後面的章節所要介紹的原則作一個鋪陳。
用心保護程式碼，是程式設計師的工作
我印象較深刻的是作者提及的態度，身為程式設計師，如何維護一個好的程式碼就是我們的職責。其實也正好呼應 Michael Feathers 的看法：「Clean Code 一定是由某位重視且照料它的人所撰寫的」。
