Clean Code 讀書筆記 - Chapter 1 無瑕的程式碼

在 13 年前早有人在討論程式碼不在是議題，未來程式碼都會自動產生，書中提供了一個觀點

程式碼代表了需求細節

撰寫細節 -> 撰寫程式（programming）
明確描述 -> 程式碼（code）

書中講了一個故事，曾今的殺手級應用，因為急於上市，導致程式碼混亂，因此在後續新功能不段添加後，變得越來越糟，最後到了無法處理

劣質的程式碼導致了這家公司的倒閉

正如前面提到的，隨著時間的前進，開發難度越來越高，開發產能逐漸下降

接下來會發生什麼事

• 補人？
• 重構？

補人

• 新人可能更有機會疊床架屋，因為對原本架構不熟悉
• 需要有人當 mentor，勢必減少開發能量

重構

• 就技術人來說可能合理，但老闆怎麼說服？
• 新舊會同是並存，那可能就會產生政治問題
• 幾年後新產品所有功能都追上了，且 QA 成功，到時會不會發現又是另外一個 『雜亂的程式碼』

Ｑ：程式碼失控脫離原有設計，最後難以維護走向專案的 fail，是誰的問題？

可能我們心中的答案：需求不段改變，或是根本沒有明確過？隕石流開發？Deadline 過短？

書中提到的論點：工程師不夠『專業』導致

下面舉了一個有趣的說明

在以前醫生動手術與下場手術間，並不會洗手消毒，原因是『太忙了』

但到了現代呢？你的病人要求你快一點，不要浪費時間洗手

病患（老闆）
要求不洗手改快進行（發動隕石流開發）
那身為醫生（工程師）
你具備了比病患更多的醫學知識與常識（Know-how）
你應該拒絕不然顯得你不夠『專業』

慢慢造成這樣的是『我們』
最後痛苦的也是『我們』

需要通過練習，才能練出『程式感』（code-sense）

• 不具備程式感的人，可能可以看出程式雜亂，但無法提出改良它的方法
• 具備 程式感 的人，則提出如何改善、如何執行

書中將 Clean Code 看作為藝術，能將空白畫面經過一連串轉換後，構築成優雅的系統

• 優雅又有效率
• 盡量少的依賴
• 可讀性佳
• 俐落的抽象
• 越少越好（API、Entities、Class 或 Method）
• 沒有重複的程式碼
• 包含單元測試與驗收測試

『有作者，就有讀者』

使具備程式碼可讀性，花精力在寫程式更重要

作者通過 IDE 功能回放開發的過程，可以看出

『讀』舊有程式碼的時間，遠大於實際『開發』

應花費的精力：可讀性 > 寫程式