前言
歷經好幾個月的風雨，最近終於靜下心來看完這本 Clean Coder 無暇的程式碼，與過去看的技術工具書不同，這本比較偏向在職場工程師需謹記的態度和原則，從 Bob 大叔長年的親身經歷和過去踩過的雷，相信可以從他的經驗中學習，同時面對如瘋子般的 User，能夠保持專業的行為。
保持專業主義
身為專業的軟體工程師需秉持專業主義，整理如下幾點須謹記
對自己所做的不完美負責
不管是最底層碼農，到 Google 的工程師肯定都會開發出有 bug 系統的經驗，面對自己寫出的缺陷，必須要勇於承擔這不完美，而不是找其他藉口搪塞，甚至是亂掰撇清自己責任。深刻知道開發的業務邏輯
我工作的第一個專案開發就被主管 judge 這塊，問我「你開發的這系統知道是給誰用?用的目的是?何時會用?以前的方法是什麼?你解決了什麼?是否適用其他地區使用?…」，當時只記得系統功能要符合需求，並再確認 CRUD 正常執行就好。從此我也深刻知道，身為開發者不能只按照規格書來寫程式，必須對商業邏輯方面清清楚楚，不只是在寫程式時能更加精準符合需求，同時過程也會比較有趣。不害怕持續重構自己程式
過去學的 SOLID 的開放封閉原則 (Open-Closed Principle) 教我們對於擴展功能時，不應該修改既有的程式碼，這也是大多工程師的準則，修改過去的程式碼，意味可能會出現異想不到的 bug 發生，這也是我工作兩年很頭痛的問題，所以都漸漸地不敢去重構。但 Bob 大叔鼓勵我們不需要害怕去重構這些舊 code，因為他認為保持不變才是危險的，但重構的前提是要有完善的自動化測試。站在使用者角度思考系統
其實很多時候使用者自己要什麼他們自己也說不清楚，所以有時候能夠換為思考，更有機會挖掘出他們真正的需求。
大膽說「是」/說「不」
沒有把握請堅守說「不」
Bob 透過大量過去故事說明說「不」的重要性，而且越是關鍵時刻，這句話的價值也就越高。大多情況都是主管要求你短時間完成某個系統功能，但你確信這段時間搞不定，這時候不要妄想自己加班或熬夜能夠搞定，而是要互相溝通協調，達到雙方都希望的共同目標結果。
其實評估系統的開發時間也是另外一個挑戰，而且過程中還可能被要求加入其他新功能…說「不」的小技巧
工作的這些年來，堅守自己原則說「不」真的非常不簡單，首先如果老闆很自以為，可能會覺得這員工還沒試就再推拖，印象分數直接掉好幾分。所以我覺得說「不」之前一定要有些證據可以支撐我的判斷，可以準備不行的原因及替代的方案來協調，甚至能列出開發的先後順序如第三點提到的，可以先完成初步畫面，比較複雜再接著繼續做。堅守自己目標互相協調
Bob 有個故事說明這原則，主管 Mike 要求程式設計師 Paula 明天完成登入畫面，因為 User 隔天要來看 demo，最好情況是雙方都互相堅守自己原則，而不是有一方妥協，像是 Paula 回覆確定完成不了這功能，Mike 就妥協說「好，那再延期」，另一情況是 Paula 心理確定完成不了，但礙於主管拜託，就半撒謊的妥協說「好，我會試試看」，這些都是沒有協商的結果，運氣不好就會造成雙方的傷害。
最好情況是彼此了解對方的目標，互相協調達到雙方都可以接受的結果，Paula 可以回 「不，沒辦法這功能至少要兩周」，而 Mike 表達自己立場說「不行啦，明天 User 就要來看 demo，我必須給他展示基本登入使用畫面」，而他們最終的定案是只做前端的假登入畫面，沒有後端的驗證、權限或資料庫串接等功能。如此就完美解決這次遇到的難題，這也是我們在職場時常會遇到的狀況，謹記要堅守自己原則，並互相協調!不必解釋太多「為什麼」
Bob 提到「為什麼」遠不如「事實」重要。當你在解釋為什麼時，沒有技術背景的老闆可能會指示說不要做這個，那個可以怎樣簡化，這就是一個不專業的行為，正確應該是解釋目前事實狀況，並用他們聽得懂的語言來說明。避免說出「試試看」
會說「試試看」語言、平台、現有架構以及當前系統的所有問題的情況，大多都是不太確定是否可完成，並可能需求照單全收加班熬夜犧牲自己，讓產出的品量變差。如果不確定就要說「不」或互相協商，而不是用說試試看來搪塞目前交辦的工作，同時也是一個不誠實的表現。給出承諾就盡可能達成
每次承諾都是對你這人的可靠度打分數，所以承諾的重要性非常重要。Bob 提到如果涉及其他團隊的專案，就會有比較多不確定因素，我們只能承諾自己的可控範圍，所以不能夠隨意承諾答應 User。
另外想到如果一起 co-work 的其他 team 同仁一直在裝死，這時候有幾個步驟，首先可以先工程師之間的 mail 通知，如沒反應再慢慢從自己 team 的 leader 到 Manger 來發信通知，這樣還繼續裝死就太佩服。
寫程式
先搞定測試再寫程式本體
我自己覺得測試的完整度決定產品程式的品質，但很多時候確實沒有那麼多時間…寫程式時保持聚精會神
作者有提到寫程式有個步驟，首先需要知道當前要解決什麼問題以及該如何解決，接著對我們使用的的語言、平台、架構以及當前問題進行整合，目標是能夠反映解決 User 真實的需求，並且要隨時注意程式碼不能讓現有系統更僵硬或破碎，最好情況是其他 Programmer 能夠讀懂你的 Code，而且過程當中都保持良好精神狀態!避免陷入心流區 (Flow zone)
聚精會神到極致時，可能會進入這種感覺效率極高，但可能會無法兼顧全局，會寫出意想不到的錯誤寫程式不想被中斷
在開發的過程當中，難免會被 user 或同事打擾，Bob 鼓勵我們盡可能停止手邊工作來去幫助他們。但我認為可以先自己判斷輕重緩急，如果不急可以累積到一定的量在某個時間點來一次處理，這樣也會顯得較有效率點。遇到解不開的問題
開發的過程難免會被問題卡住，Bob 有提供他過去使用的小方法，像是結對程式設計(Pair programming)，顧名思義就是找同事一起來看問題，這招我有試過，確實會有奇特的化學效應，感覺思緒會變得更清楚，我覺得就是不想在同事面前表現很爛，觸發我們自己的潛在實力。其他方法來有放下問題去做其他事，解法可能就會在通勤路上、洗澡或睡覺時想出來。
測試驅動開發
不管怎樣先寫測試程式，接著在完成產品程式的軟體開發方式
- 三大法則
- 單元測試前，絕對不可寫任何產品程式
- 只寫剛好無法通過的單元測試之產品程式
- 只寫剛好能通過當前測試的有問題之產品程式
- 三大工具
- Junit
- Mockito
- AssertJ
預估
我覺得開發的時程預估是需要經驗的累積，大多時候都會 高估自己，接著就需要下班後繼續趕工…
對業務端而言，預估就是承諾
對開發者來說，預估其實是猜測
不同角色對預估有不同定義，所以我們開發人員要盡可能減少預估與實際的落差