「42 年裡，我什麼都經歷過。我被開除過，也被表揚過。我當過小組長、主管、也當過普通員工，甚至當過 CEO。我的同事有絕頂聰明的，也有混日子的。我開發過尖端的嵌入式軟硬體系統，也寫過尋常公司的薪資系統」

「所以，請你把這本書看成我的『錯誤大全』，它記錄了我幹過的所有蠢事；也請你把這本書當成一份指引 — 帶你繞開我曾經走過的彎路」

取自: The Clean Coder (pp.38-42)

CH1: 專業主義

• 這一章有點像本書的總摘要，在傳達專業人士該有的心態與素養，原書內容可大致歸納成幾類：

「專業人士」就是能對自己所犯錯誤負責的人

• 沒人能寫出完美的軟體，但這不表示你不用對不完美負責
  • 要練習的第一件事：「道歉」
  • 對相同錯誤的失誤率應當趨近於 0

避免不負責行為：

• 為如期交付產品，忽略測試環節、或給出做不到的承諾 (X)
  • 我本該早點擔起責任，告訴 Tom 測試還未完成、自己不能按時交付產品
  • Tom 一定會不高興，但客戶不會遺失資料、客服經理也不會打電話來砲轟
  • => 請在關鍵時刻 Say No!

要確信 Code 能 Work

• 把自己沒把握的程式碼發送給 QA 人員本身就是不專業
  • 如何確保程式碼能正常工作? 寫測試!
  • 整個 QA 流程應至少包含「單元測試」和「驗收測試」
• 設計易於測試的程式碼
  • 最好先寫測試，再開發
  • 單元測試的覆蓋率應以 100% 為目標 (作者本身的 FitNesse 專案覆蓋率高達 90%...)
• 每次 QA 找出問題，甚至「用戶找出問題」時都該感到羞愧並以此為戒

P.S. 其實原書在開發時的要求用語更為強烈，我做了點保守潤飾。可以感覺出作者真的對程式開發有著極度完美主義的堅持...

聰明人不會為了發佈新功能而破壞原有結構

• 結構良好的程式更靈活
• 犧牲結構的代價將是得不嘗失、將來必後悔莫及 (作者看過太多失敗案例)

如果希望自己的軟體「靈活可維護」，就應該時常修改它!

• 要證明軟體易於修改，唯一的辦法就是「改」
• 如果發現不好改，此時就應該改進設計，使後續修改簡單
• 童子軍原則 (無情重構, aka Merciless Refactoring)
  • 每次 Check in 程式碼，都要讓它比上一次變得更簡潔
  • 每次讀 Code 都別忘了重構

承上，常見迷失： 對能動的軟體不斷做修改是危險的 (X)

• 錯! 讓軟體保持固定不變才是危險的!
• 如果一直不重構程式碼，等不得不重構時就會發現程式碼已經**「僵化」**

「專業開發人員對自己的程式碼和測試極有把握，他們敢隨心修改類別名稱、拆分冗長方法。他們還會把 Switch 語句改為多型結構，或將繼承層次重構成一條命令鏈(Chain-of-Command)」

取自: The Clean Coder (p.50)

職業道德

「職業發展是你自己的事，雇主沒有義務給你留下學習的時間」

「雇主出了錢，這 40 小時應該用來解決雇主的問題，而不是你自己的問題」

「站在雇主的角度來思考」

取自: The Clean Coder (p.50 & p.55)

• 有時這兩者並不矛盾，而是一致的
• 你為雇主做的工作也使你個人職涯發展受益匪淺

瞭解業務知識

每位軟體開發人員都有義務瞭解自己開發專案所對應的「業務領域 (Domain Knowledge)」

• 未必要成為該領域的專家，但你仍須勤勉付出相當的努力來認識業務領域
• 開啟一個新領域專案時，應當閱讀一兩本該領域書籍
  • 以該領域的基礎架構 & 知識進行「使用者訪談」
  • 花時間和業內專家交流，瞭解他們的原則與價值觀

承上: 最糟糕的作法就是「只照規格說明來撰寫程式」

• 你應該對該領域有所瞭解，能辨別、質疑規格說明書中的錯誤

堅持學習 & 練習

每個專業軟體開發人員至少須精通的事項：

1. 設計模式 (Design Patterns)
   必須能描述 GOF 書中全部 24 種設計模式，同時還有 POSA 書中多數模式的實戰經驗
2. 設計原則 (Design Principles)
   必須瞭解 SOLID 原則，而且要深刻理解元件(Component)設計原則
3. 方法 (Methods)
   必須理解 Extreme Programming (XP)、Scrum、Lean、Kanban、瀑布、結構化分析及設計...等
4. 學科 (Disciplines)
   必須練習 TDD、OOD、結構化程式設計、Continuous Integration (CI) 和 Pair Programming
5. 工具 (Artifacts)
   必須瞭解如何使用 UML圖、DFD圖、結構圖、Petri 網路圖、狀態遷移圖表、流程圖和決策表

P.S. 本書初版為 2013 年

「軟體開發人員必須堅持廣泛學習才不至於落伍」

• 不寫程式的架構師必然遭殃
• 不學新語言的程式設計師同樣會遭殃

只完成日常工作並不是「練習」

• 「練習」指的是工作之餘的自我提升
• 關注 Blog、參加技術大會、讀書會與學習小組、學新語言...等
• 訓練手指和大腦： Kata (刷題)

程式設計就是意味著「與人協作」

• 學習的第二個最佳方式是「與他人合作」
• 我們需要和業務人員合作、開發者之間也需要合作
• 如果想終生能以程式設計度日，那麼，一定要學會交流 — 和人們(People)交流

幫助他人 (原文: 輔導)

• 專業人士會「視輔導新人為己任」，他們不會放任新手胡亂打撞

謙虛

• 專業人士從不會嘲諷別人，自作自受時他會接受別人的嘲諷
• 它不會因別人犯錯就貶低對方
• 因為專業人士知道，自己有可能就是下一個犯錯的人

CH4: 寫程式

焦慮時寫下的程式碼

• 思考：你曾經有過在心煩意亂的時候繼續寫程式的經驗嗎? (e.g., 剛分手、和人大吵一架後、生活遭遇變故...等)
• 是否注意到此時在大腦裡還有一個背景程序在運行，試圖解決或回想這些問題?

「這個時候根本就不應該寫程式。這時產出的任何程式碼都會是垃圾」

「如果發現內心的焦慮正不斷削減工作效率，那麼最好還是它們先安靜下來，這要好過硬逼自己去寫程式」

「當然，有許多焦慮無法在一兩個小時內解決，且老闆也無法長期容忍我們因為個人問題而不投入工作。關鍵所在，是要學會如何關閉背景程序」

取自: The Clean Coder (p.95)

P.S. 就筆者感想，心煩意亂時工作效率的確會變差。如何快速處理情緒 (或至少暫時切換情境)，確實是一門深奧的學問。有讀者想分享任何心得的話歡迎留言~

流態區

「關於『高效率狀態』人們已經寫了很多，通常被稱之為『流態(flow)』。這是一種意識高度專注但思維視野卻會收斂到狹隘的狀態」

「他們會感到自己絕無錯誤、感到自己效率極高。然而這種意識狀態並非真的極為高效，這其實只是一種淺層冥想。為了追求所謂的速度，理性思考的能力會下降。你其實沒有顧及全域，你很可能會做出一些後來不得不摧毀的決策」

取自: Clean Coder (p.95-96)

為什麼我們不該陷入流態區?

• 在這種狀態下，你其實沒有顧及全域
• 你很可能做出一些後來不得不摧毀重做的決策

P.S. 關於避免進入流態，作者極度推崇 Pair Programming。至於 2 個人使用 1 台電腦的工作模式是否真的能提升(效益 / 成本)的比值又是另一個議題了

以筆者淺見，就像寫論文卡關時一樣，有時候只要適當抽離，跟朋友聊聊研究想法、甚至向他解釋你正在做什麼，就會有助於靈感提升了

聽音樂時寫的 Code

卡關的時後 (原文: 阻塞)

保持節奏

幫助他人 & 接受他人幫助

面對交付延遲