本書由 Clean Code 作者 Bob 大叔撰寫，關於工程師如何處世之道，薄薄 200 多頁，但許多精要都涵蓋在內。由於撰寫此篇時，書已經不在手中，因此部份內容參考網路資料，將其放在文章前頭。
參考資料
專業主義
- 對自己的不完美負責，發送明知有缺陷的程式，這種做法是不專業的。
- 自動化測試能減少測試的時間，但提高通過QA測試的成功率。
- 無情重構（童子軍規則）：每一次簽入都比上一次簽出更為簡潔。
- 讓軟體保持不變（僵化）才是危險的，讓開發人員不害怕修改的基底：自動化測試。
- 每週168小時，給你的雇主40小時，為自己的職業發展留20小時做一些能激發、強化你熱情的事。
- 了解領域
- 設計模式：GOF中的24種模式、POSA書中多數模式的實戰經驗
- 設計原則：SOLID原則、元件設計原則
- 方法：理解XP、Scrum、精益（Lean）、看板、瀑布、結構化分析與設計等
- 學科：TDD、ODD、結構化程式設計、CI、Pair Programming
- 工具：UML圖、DFD圖、結構圖、Petri 網路圖、狀態遷移圖表、流程圖、決策表
- 持續練習，重複做一些簡單的練習：kata。
- 了解業務領域：最糟糕最不專業的做法是只按照規格說明來撰寫程式碼，卻對於業務的為什麼不求甚解。
- 站在雇主的角度來思考，開發出可以真正滿足雇主需要的功能。
說「不」
- 「為什麼」遠不如「事實」重要，儘管細節對決策者有幫助，但提供更多細節，可能會讓對方要求省略某些步驟，而成為一個口令一個動作的管理方式。
- 越是關鍵時刻，「不」字越具價值（展現專業）。
- 許諾「嘗試」，意味著承認之前未盡全力，還有餘力可施。也意味著再加把勁還是可以達成目標。而且這也是種「承諾」。承諾嘗試，意味著有新方案、新作法，如果沒有，那就是一種「不誠實」。
- 消極對抗，在故事中，Paula 如果放任事情發展，任由 Mike 走上絕路，那便是一種消極對抗，但另一種做法是，他可以直接與上層交流來阻止災難發生。這樣雖然有風險，但也是體現了團隊精神的內涵。
說「是」
- 說「是」是一種承諾：
- 口頭上說自己將會去作
- 心裡認真的對待自己做出去的承諾
- 真的付諸行動去作
- 能就是能，不能就是不能，不要說試試看。
寫程式
- 避免進入流態區 (Flow zone)，在此狀態下雖然寫程式有如神助，但會因此而無法顧及大全，導致之後還是需要重構或捨棄產出。
- 可以藉由結對 (Pairing) 來避免雙方進入流態區，與外界保持互動和聯繫。
- 保持節奏，尤其焦慮的時候不要寫程式。
- 一個專業的程式設計師，要不吝於幫助他人，也要學會請求別人的幫助。不要死命護住自己的地盤。
- 大部分的情況不要超時加班，除非是以下三個條件都符合：
- 你個人能擠出這些時間
- 短期加班，最多兩週
- 你老闆要有備案（最關鍵）
測試驅動開發
- 完成的定義：程式碼完成、所有測試通過、QA測試通過、業務單位確認過，才叫完成。
- TDD：先寫最簡要的測試，再撰寫剛好可以通過測試的產品程式。
- 程式能夠快速的迭代，同時測試覆蓋率也會很高。
- 先寫測試再寫程式，是攻擊；先寫程式再補寫測試，是防守。
練習
- 透過道場 (Dojo)、Kata、Wasa 來進行小片段的練習。
- 一周的工時是 60 小時，其中一周40 (一天 8 小時) 小時是為雇主工作，剩下的 20 小時是要為自己工作，等於一天要培養自己的技能 3 個小時。
驗收測試
- 驗收測試：要由業務人員與 QA 一起來撰寫驗收測試，它是需求文件，用來描述系統會提供什麼樣的功能，如果要由開發人員來寫，要與開發功能的人不同。
- 持續整合與自動化：要能將這些測試自動化，透過持續整合機制幫我們運行這些測試，如果有發生測試失敗，團隊要立即停下來修正程式，直到測試可以完全通過為止。
- 避免過早精細化：在需求不確定的情況下，不要過早精細化，業務方可能會因為精細的成果提出更多反饋，在這連續影響之下，很高機率離完成越來越遠。
測試策略
- 自動化測試金字塔
- (5%) 人工探索測試：就是非腳本化的測試，需要人工介入，確保系統在人工作業下運行良好。
- (10%) 系統測試：最終的整合測試，用來測試組裝好的系統各個部分是否可以正確交互操作，由架構師操作，在這個層級必須包含性能與產能測試。
- (20%) 整合測試：是一種編排性的測試，確認元件組裝之後是否協調，由架構師撰寫，在這個層級已經可以進行性能與產能測試了。
- (50%) 元件測試：是驗收測試的一種，對業務規則的一種驗收測試，由QA與業務人員撰寫。主要測試成功路徑的狀況。
- (100%) 單元測試：由程式設計師撰寫，確保程式碼意圖沒有遭到破壞，且程式碼是運作正確的，要包含邊界與異常狀況。
- 『QA應該找不到任何錯誤』 這只能說是一個目標，儘管公司可能有一支專業的QA團隊，再送測之前，要確保自己功能完整，沒有發現 bug。
- QA 也是團隊的一部份
- QA 是需求規約定義者 (QA as Specifiers)
- QA 是特性描述者 (QA as Characterizers)
時間管理
- 會議：為自己的時間管理負責，應該要拒絕不必要的會議。當會議議題與自身無關，應禮貌地要求離席。
- 會議是必須的
- 會議浪費了大量的時間
- 立會：在 1 分鐘內回答以下問題，總體不應超過 10 分鐘。
- 昨天做了什麼？
- 今天預計完成什麼？
- 在這之中遇到了什麼問題或阻礙？
- 爭論：在 5 分鐘內無法有結論的爭論，就沒有辯論的必要。代表雙方都沒有足夠有力的證據，此時應該停下來，收集資料，讓資料來說話。
- 蕃茄鐘：給予自己一個完整的不被打擾的時間，將正式與雜事分開，專心一致地完成項目。
- 優先順序錯亂：藉由說服自己某些事情更重要，來逃避真正該完成的項目。
預估
- 對業務端而言，預估就是承諾；對開發者來說，預估其實是猜測。
- 為了降低時間預估與實際的落差，可以透過一些方法：
- PERT 估算法
- O：樂觀預估 (Optimistic Estimate)
- N：常規預估 (Nominal Estimate)
- P：悲觀預估 (Pessimistic Estimate)
- Delphi 德爾菲預估法：比手指、撲克牌、任務難度排序等，以取得參與者的共識，如果差異過大，應該要停下來說明理由
- 大數定理
- 將任務拆分成小項目，各個擊破來預估時程。
- PERT 估算法
壓力
- 不要壓力 (XD)
協作
- 要合作 (XDD)
團隊與專案
- 組建一個長期合作、凝聚力高的團隊。團隊彼此熟悉，知道做事方法，效益比較高。
- 將專案分配給這一個專業團隊，而不是圍繞的專案拉人來組隊。
輔導、學徒期與工藝典範
- 醫師、廚師等工作，都會有學徒制，不會直接將病人的生死交給一個新手醫生，而要經過重重訓練和輔導才能夠執業。
- 然而工程師卻很常看到一上工就製作核心功能。當然軟體失敗的後果不像醫生這麼嚴重，但因此損失千萬的公司也是大有人在。
- 作者希望身為一個專業的工程師，也應該要引入學徒制，技術主管指導一般工程師，一般工程師帶領實習生。
小心得
- 書中所描述的做法，很多都是「正道」，可惜或許文化不同，做事習慣不太一樣，仍然會有些許的差異：
- 願意接受「有但書的試試看」
- 說「不」與說「是」，都是根基於專業程度高的展現
- 在規劃完整的情況下，應該能夠進入流態區
- 會議是提高凝聚力的做法
- 做中學、做中問，還是比較常見的訓練方式