Clean Code 相信很多人都看過，提供軟體界一個自我審思程式碼品質的標竿，也被許多工程師奉為圭臬，這一本 Clean Coder 更多著重於身為一名專業人士所需具備的內涵，包括但不限於程式碼
Highlight 兩點我覺得被重重提醒的地方，並提出一些自己的想法
說「不」與說「是」
身為工程師，都遇過 PM 臨時來的需求，並強硬的要壓一個不太合理的日期，在這種壓力下，不論是出於善意或是懶得爭辯，是否都曾說過「好的我試試」
對於答應接下工作的工程師而言，「試試」就是代表有可能做到，但是 PM 會解讀成「好的沒問題」
等到上線日來臨開天窗，身為 PM 覺得被工程師耍了，而工程師也很無辜的表示「就說試試而已」，開始踢起皮球，這對雙方都是很不專業的表現
當我們要給予承諾時，請非常小心我們的措辭，如果因為壓力就改口說「我試試看」，那是否代表著過去的你都在偷懶，在壓力相逼的情況下反而增加工作產能？
如果還是照既定的方式做，那所謂的「嘗試」又是在嘗試什麼呢？
這聽起來很理想化，或許會嗤之以鼻，但及早說不，並堅守底線，不要因為壓力就放棄測試，不要因為壓力就想寫出有臭味的程式碼，身為專業人士應該有對自己工作品質的保證，而不是一昧的降低標準
或許更好的方式是將任務細分，在時限內給出合理的成果，並規劃未來逐步完成的時辰，遇到時辰困難應儘早反應，而不是抱著僥倖的心態祈禱或是冷眼看著任務失敗
當確定要接下任務時，請確保再給予「是」的承諾時包含三個步驟
- 口頭上說自己會去做
- 心裡認真對待自己所做出的承諾
- 真的付諸行動
如果發現有這些徵兆，那多半承諾都會落空
- 需要 / 應當 - 我們需要有人完成這項事情
- 希望 / 但願 - 但願我有時間幫你處理
- 讓我們 (而不是「讓我」) - 讓我們一起做這項任務
真正的承諾，應當是明確指出自己將負責這件事情，並給予明確的時辰與交付內容
這點真的很有感，尤其是做後端，時常要協助其他團隊調查 API 呼叫紀錄 / 伺服器運作狀況 / DB 資料查詢等瑣事，常常會說「好的，我等等幫你查」，一方面正事一直被打斷效率差，另一方面也容易忘記答應過的事情，導致整天工作很忙卻也沒有什麼產出
後來我做了一些調整
- 上班一開始就用筆記本寫下今天要完成的任務
- 開發途中有人敲 slack 需要協助，除非事態緊急，否則等任務做到一個階段再回覆
- 每天只接固定的瑣事數量，其餘的給予明確時間回覆(如隔天)
盡可能確保自己的任務準時且有品質交付，之餘也協助其他團隊成員的調查，讓自己給予的承諾是正面的
預估
預估工時是一個蠻微妙的藝術，PM 會拿一個不是完全明確的需求來詢問一個預估的工時，預估不是承諾，帶有著一點模糊的空間，「可能三天？如果有緊急事件可能要五天？」未來有著太多的不確定性，但是預估與資源安排息息相關，不能因為預估不準而讓 PM 難以安排進度，而往往工程師有過度樂觀的狀況 (笑
PERT (Program Evaluation and Review Technique)
美軍在 1957 年發展潛艇極地航行計畫時所設計的預估工時方法，採用三個數值
- O 異常樂觀：所有事情都很順利的情況下的工時，機率應小於 1%
- N 常規預估：機率發生最高的預估工時
- P 異常悲觀：考量各種災害如地震等，給予最悲觀的工時預估，機率應小於 1%
得出上面三個數值後，可以用機率分析表示
- 預估完成工時: u = (O+4N+P) / 6
- 標準差，用來衡量不確定性：(P-O) / 6
德爾菲法
剛才的 PERT 是一個人預估的工時，但是換一個人可能會給出不同的預估結果，仰賴團隊成員給出不同的預估，最後達成共識也是一種方法
主持人請每個成員在他人不知道的狀況下決定預估工時，時間到一起亮牌(數手指之類的)，看大家是否有共識，如果有人有很大的歧異，則開始討論分歧的依據，接著下一輪，直到大家給予的評估都差不多才結束
凝聚共識也是很重要的一環，尤其是團隊合作上，從每一個人評估工時的不同，就能去看出對於細節與實作想法上的差異，彌平這類的差異可以讓團隊合作更順暢
大數定律
將大任務拆解成小任務後在估時會比較精準，且經過拆解可以更理解任務的各種面向
結語
書中還有談其他面向如測試 / 練習 / 協作等，算蠻有趣的一本書，明確指出專業人士的區別，其中舉的案例也是歷歷在目，值得在職涯中時時品味