《Code Complete 2nd Edition》，簡稱 cc2e，是一本很經典，也挺有年紀的書。2004 年就出版，幾乎是每一位頂尖的開發人員都閱讀過很多次的好書。
然而篇幅很長，這就是本軟體開發的四庫全書，是屬於「大全」類型的書。很多人買了之後，就只在案頭上供著，看沒幾個段落就提不起興趣往下看。
本文希望藉由自己的一些經驗，整理幾個閱讀的重點與注意事項，希望能幫助大家更輕鬆、有感、持續地體會這本書能為你帶來的實際價值。
基本資訊
- 經典作者經典書：2004 年出版，作者為兩屆 Jolt 大獎得主 Steve McConnell。
- 繁體中文書也有兩版，最近這一版為博碩文化的名家名著系列，書籍資訊請參考天瓏網站。
- 超厚實、超大篇幅：主要內容一共有 35 個章節，856 頁，1.7 kg。如果拿《軟件開發本質論》來跟《cc2e》做比較，就像【蠅量級】 vs 【重量級】的差異。
- 軟體開發界的四庫全書，軟體開發實務大全。
閱讀注意事項
- 相當考驗耐心跟讀書技巧
- 屬於案頭上必須得擺著的經典鉅作，隨著職涯不同階段翻閱，都會領略不同的感受
- 另一本同等經典的鉅作是《人月神話》，必備、必看、不能只看一次。
- 畢竟是本老書，所以時代背景不同，用詞也不盡相同，翻譯上有些東西也不是挺好翻，當看到不太直覺的詞彙，可以上網找一下原文，當然，如果你手邊也有原文書可以對照著看，就更好了。
- 不一定要照著順序讀，大部分篇幅很長的書，讀者都不容易有耐心讀，而且最前面通常都是基底、心法、概念，不好懂或容易無感。
- 本文後半段會介紹我替各位將各章節簡單的分類，包含如何讀起來會比較有感覺，能比較早應用在實務上。
- 不要整本書都讀完，才開始去思考、去嘗試、去練習。不太會有讀完的一天的，即使讀完了，你也忘記之前看的內容了。
- 看完一段，就嘗試在實務上比較、體會、練習、印證看看書裡的內容。這樣才能讓學習的效果提升到極致。
- 閱讀過程中，思考與了解書裡許多 topic 為何會這樣建議，是最重要的重點。
- 例如命名風格，在 legacy product 中一致性比正確性重要，不代表你就不需要了解正確性。想了解更多，可參考第 11 章。
- 想辦法發現自己哪些東西還在殺豬公，人家在 2004 年就上外太空了。
- 例如 pair programming 在 2000 年 Kent Beck 就已經在極限編程（extreme programming, XP）中提出來了。更多資訊可參考第 21.2 章。
- 千萬不要錯過了每個章節中的檢核表（checklist），以及每一章最後的【要點整理】
- 書裡側邊的 icon 也都是有 highlight 效果，例如：
KEY POINT: 代表重點內容CODING HORROR: 代表誤區、anti-patternHARD DATA: 如果特別需要相關資料數據佐證，這個標記的段落就是引經據典、提供相關數據說明交叉參考：事實上我自己唸書，看到有興趣的段落有交叉參考，我絕對就是再切到交叉參考的段落，把前後文再看過一輪。這就像是 wiki 的閱讀方式一樣，從這個知識連結到相關知識，這是幫助學習很大的一環。作者跟出版社都幫忙標示了，不懂得應用就太可惜了。
章節分類剖析
因為這本書內容篇幅實在太長，連章節也高達 35 章，一般人如果照順序念，大概很快就會放棄了。這邊我針對 programmer 這條路線，按照有感、立馬能用的順序分出下面幾個群組。希望能幫助大家更輕鬆、持續保持興趣地讀這本經典書。
開發細節
- ch10: 變數
- ch11: 命名
- ch14: organizing straight-line code
- ch15: 條件語句
- ch16: 控制迴圈
- ch19: 一般控制問題
- ch12: 基本資料型別
- ch31: 佈局與風格
- ch32: 自我文件化程式碼
- ch30: 程式設計工具
- ch23: 除錯
- ch13: 不常見的資料型別
- ch17: 不常見的控制結構
設計相關
- ch5: 軟體建構中的設計
- ch6: 工作類別
- ch7: 高品質的子程式
- ch8: 防禦性程式設計
- ch24: 重構
- ch9.4: PPP 的替代方案
軟體品質與優化
- ch20: 軟體品質概述
- ch21: 協同維護
- ch22: 開發者測試
- ch25: code-tuning strategies
- ch26: code-tuning techniques
- ch29: 整合
建構專案/產品注意事項
- ch3: 前期的前置作業
- ch4: 關鍵的「建構」決策
- ch5: 軟體建構中的設計
- ch27: 程式規模對建構的影響
- ch28: 管理建構
- ch33: 個人性格
- ch34: 軟體工藝的話題
簡單的說，你越資深，角色越偏向 leader 或需要關注全局的人，就越該重視上述後半段的內容。
如果你還是個 junior programmer，那我建議可以照上面的分類順序，先從開發相關的內容看起。就像風清揚一開始教令狐沖獨孤九劍時，是先教「總綱」跟「破刀式」，因為眼前馬上就要用了，學以致用才是真學習，得感興趣，才可能繼續往下閱讀這本書其他內容。
91 的其他補充
- 光只有看書是沒用的，要把對書裡資訊的理解轉化成知識，其關鍵在於跟既有知識體系建立連結，讓知識點不會形成孤島。並且嘗試在實務中實驗、落實，才能印證書裡的道理，才可能從知識內化成技能，才能更深入了解其適用場景與限制。
- 書裡很多內容看不懂，是正常的。看書是這樣的，很多書的內容你在看的當下沒有感覺，不太懂。然後你在實務上經過血淚、疤痕累積到了知識與技能，覺得很有成就感。當某一天你重看那些書時，發現原來書裡早就寫了這些知識，只是當時的自己不懂罷了。而有趣的是，如果你不曾先經過那段「看不懂」的經歷，實務上要獲得對應的知識與技能，難度就會變得很高。
Steve Jobs 說過一段話，就是這個道理。
you can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.
- 對我來說，cc2e 是一本絕世武功的目錄，可以幫助讀者透過大全來了解全局的樣貌，但仍須持續針對各個層面深入研究與了解。針對現代軟體開發，用【道法術器】來舉例子的話，大概是這樣。
- 道：Agile/DevOps/Lean...
- 法：Scrum/Kanban/引導...
- 術：Unit Test, Refactoring, ATDD/TDD/BDD, Specification by Examples, User Story Mapping, Impact Mapping, CI/CD, world coffee, lean coffee, retrospective, daily scrum meeting, pair programming, code review, design patterns 等等…
- 器：實體白板、便利貼、war room、retrospective room、投影機、生產力工具（如 Wox/Alfred/TextExpander）、IDE（如 JetBrains/Visual Studio/VSCode）、各種 plugin（IDE/editor/browser 上的擴充套件）、螢幕、電腦配備、電腦椅、電腦桌等等…
要 code review? 要分享碰到的問題或剛找到的解決方案？直接在位置上投影機 chromecast 投出來，這才是效率。
想要作到敏捷宣言第一條，人與溝通互動 重於 流程與工具，首要條件就是拉高溝通頻率，但要能降低單次溝通成本。
Raise your bar，很多人寫 code 快不了，是因為不覺得自己慢。很多人很難變強，是因為活在自己的井裡，太少接受外部刺激。
完美是個動詞，追求完美的過程，才是完美的體現。而不放過各個細節，讓自己 work as an artist，享受其中，讓軟體開發的過程像是藝術般的呈現，這個過程會讓你一直變強，因為你不斷在追求各種極限。
- 2019/5/18(六)：【單元測試實戰營】第六梯次（台北）
- 2019/5/19(日)：【極速開發】第七梯次（台北）
- 2019/6/15(六)~2019/6/16(日)：工程實踐與流程規範導入實務 201906 第一梯次（台北）
- 2019/7/27(六)~2019/7/28(日)：演化式設計：測試驅動開發與持續重構 第六梯次（台北）
blog 與課程更新內容，請前往新站位置：http://tdd.best/
