The Clean Coder 是The Clean Code的姊妹篇，由同一個作者編寫，The Clean Code主要講述如何編寫高質量的代碼，而The Clean Coder則關於於人，講述如何做一個”專業“的編碼人員。
以下是我看完此書的一些筆記，做個小記。
- 持續重構：無論什麼時候看到壞味道的代碼，重構它，不要以”怕影響線上功能“爲理由，如果想保證代碼的高質量，只有不斷的，無情的重構。同時，爲了能保證重構前後代碼的等效性，完備的測試代碼是必不可少的。
- 練習編碼：就像運動員需要訓練、棋手需要對弈一樣，程序員需要不斷練習。這裏的練習不是找尚未解決的問題，而是重複地練習固定的題目，只求越來越熟悉，直到訓練出編寫固定題目再無任何冗餘動作的地步。它旨在練習手指和思路，還有工具的熟練程度。TDD、算法、固定起手式，都可以練習。並且練習可以結對進行，比如一人寫測試用例，一人寫實現，二者交換角色。這有助於練習結對編程。
- 對於工時預估：不可能準確的，但是專業的編碼人員能識別延期的風險，最大限度告訴外界，給外界正確的預期。所以，我們要：
- 大膽說不，完成不了的時候，強硬的說完不成，只能做到預期功能的幾分之幾
- 要求告知工時的時候，區分 ”承諾“和”預估“ 能完成的時間，承諾必須遵守，而預估是一個可以不斷修正的模糊值。
- 講工時拆分，拆開爲樂觀估計、一般估計、悲觀估計，三者綜合考慮，或者僅僅考慮一般估計和悲觀估計的加權平均(4:1)
- 如果發現進度落後，不要一個人低頭煩躁，趕進度。告訴別人，讓別人知道自己當前的狀態，風險提前暴露
- 更多關於工時預估， 對於工時的估計，於以下幾種方式
- PERT:對樂觀估計、標稱估計、悲觀估計按照 1：4：1 的比例求算數平均((最差 + 4*標稱 + 最好)/6)，統計計算標準差( (最差-最好情況)/6)，工時偏差是平均值得一個標準差到兩個標準差範圍。
- 打撲克方式：在敏捷開發過程中，迭代會上，對於同一個任務，所有成員出牌告知自己對任務的預估時間，如果大家預估時間偏差不大，則採納之，否則討論之。
- 講工時拆分，對於小任務的預估更容易準確，所以先把任務拆分，分別估算時間，然後組裝。
- 不要在狀態不佳的時候寫代碼
- 不要進入心流狀態–(本條存疑，作者是不贊同心流狀態寫的代碼是好代碼的)
- 關於TDD：TDD不是花一天時間寫測試，再花一天時間寫代碼，如此反覆。而是先寫10分鐘測試，寫剛好讓測試跑通的代碼，再寫下一部分測試，如此反覆。TDD事關 重構的驗證和高質量的代碼，有效性毋庸置疑
- 關於會議：對於和自己關係不大或者 會中發現和自己關係不大的會議，選擇不去 以及會中離開
- 立會：一個人一分鐘，回答三個問題：昨天做了什麼、今天要做什麼、遇到了什麼問題
- 開發過程中的陷阱：
- 死衚衕：即走不通的技術道路，比如技術選型有問題，解決問題的思路有問題，死衚衕可以快速意識到，意識到之後就要趕緊回頭
- 泥潭：即 也許可以走通，但是會花很大力氣的技術道路，泥潭的殺傷力要比死衚衕更大，因爲在解決問題的過程中，泥潭總給人一種 ”我能解決“的 微弱希望，直到花費了很多很多精力。要訓練條件反射 識別泥潭。
- 關於面對壓力：應對壓力最好的方式就是避免壓力，從一開始避免壓力的產生。如果無法避免，在受壓期間，堅持一般時候自己的行爲方式，一般時候自己堅持TDD，受壓期間繼續TDD，不要在過程中變形。
- 關注業務：作爲程序員，除了關注自己的代碼寫沒寫完，還要關注業務，解決公司業務面臨的問題，老闆其實是爲解決問題付錢，不是爲代碼付錢。
- 程序員的培養體系：醫生、工匠都有自己的培養體系，但是程序員很奇怪，很多時候靠自覺來自我提升。這樣對程序員，對公司人才建設都不好。建議通過結對編程、code review方式，將經驗豐富的編程人員的能力傳承下去。
- 在多個系統，使用過多種語言工作過經驗豐富的大師，除了管理和架構建設之外，還可負責對熟練工的督導。
- 精力充沛，一般只瞭解一種語言、一個平臺的熟練工，已經有了較高的變成素養，但是對架構尚缺乏經驗，他們是編程的主力，在接受大師的督導之外，他們還可以貼身指導進入行的學徒。
- 剛剛入行的學徒，前幾年就是要亦步亦趨，接受來自於熟練工的 關於設計原則，模式、重構等思想和編碼實操的最佳實踐。
- 如上，結對編程往往是個好方法。
- 不要以項目組建團隊，尤其不要讓不是一個團隊的人，投一部分精力，在同一個項目中(eg：這個項目不太複雜， 你投半個人，支持一下隔壁組的開發工作)。這種模式，註定團隊是散的，沒有凝聚力的。要用團隊管理項目。