Yuanchieh's Blog

Yuanchieh's Blog

生命是長期而持續的累積

26 Jan 2021

《Clean Coder 無瑕的程式碼》心得

Clean Code 相信很多人都看過,提供軟體界一個自我審思程式碼品質的標竿,也被許多工程師奉為圭臬,這一本 Clean Coder 更多著重於身為一名專業人士所需具備的內涵,包括但不限於程式碼

Highlight 兩點我覺得被重重提醒的地方,並提出一些自己的想法

說「不」與說「是」

身為工程師,都遇過 PM 臨時來的需求,並強硬的要壓一個不太合理的日期,在這種壓力下,不論是出於善意或是懶得爭辯,是否都曾說過「好的我試試」
對於答應接下工作的工程師而言,「試試」就是代表有可能做到,但是 PM 會解讀成「好的沒問題」
等到上線日來臨開天窗,身為 PM 覺得被工程師耍了,而工程師也很無辜的表示「就說試試而已」,開始踢起皮球,這對雙方都是很不專業的表現

當我們要給予承諾時,請非常小心我們的措辭,如果因為壓力就改口說「我試試看」,那是否代表著過去的你都在偷懶,在壓力相逼的情況下反而增加工作產能?
如果還是照既定的方式做,那所謂的「嘗試」又是在嘗試什麼呢?

這聽起來很理想化,或許會嗤之以鼻,但及早說不,並堅守底線,不要因為壓力就放棄測試,不要因為壓力就想寫出有臭味的程式碼,身為專業人士應該有對自己工作品質的保證,而不是一昧的降低標準

或許更好的方式是將任務細分,在時限內給出合理的成果,並規劃未來逐步完成的時辰,遇到時辰困難應儘早反應,而不是抱著僥倖的心態祈禱或是冷眼看著任務失敗

當確定要接下任務時,請確保再給予「是」的承諾時包含三個步驟

  1. 口頭上說自己會去做
  2. 心裡認真對待自己所做出的承諾
  3. 真的付諸行動

如果發現有這些徵兆,那多半承諾都會落空

  1. 需要 / 應當 - 我們需要有人完成這項事情
  2. 希望 / 但願 - 但願我有時間幫你處理
  3. 讓我們 (而不是「讓我」) - 讓我們一起做這項任務

真正的承諾,應當是明確指出自己將負責這件事情,並給予明確的時辰與交付內容

這點真的很有感,尤其是做後端,時常要協助其他團隊調查 API 呼叫紀錄 / 伺服器運作狀況 / DB 資料查詢等瑣事,常常會說「好的,我等等幫你查」,一方面正事一直被打斷效率差,另一方面也容易忘記答應過的事情,導致整天工作很忙卻也沒有什麼產出

後來我做了一些調整

  1. 上班一開始就用筆記本寫下今天要完成的任務
  2. 開發途中有人敲 slack 需要協助,除非事態緊急,否則等任務做到一個階段再回覆
  3. 每天只接固定的瑣事數量,其餘的給予明確時間回覆(如隔天)

盡可能確保自己的任務準時且有品質交付,之餘也協助其他團隊成員的調查,讓自己給予的承諾是正面的

預估

預估工時是一個蠻微妙的藝術,PM 會拿一個不是完全明確的需求來詢問一個預估的工時,預估不是承諾,帶有著一點模糊的空間,「可能三天?如果有緊急事件可能要五天?」未來有著太多的不確定性,但是預估與資源安排息息相關,不能因為預估不準而讓 PM 難以安排進度,而往往工程師有過度樂觀的狀況 (笑

PERT (Program Evaluation and Review Technique)

美軍在 1957 年發展潛艇極地航行計畫時所設計的預估工時方法,採用三個數值

  1. O 異常樂觀:所有事情都很順利的情況下的工時,機率應小於 1%
  2. N 常規預估:機率發生最高的預估工時
  3. P 異常悲觀:考量各種災害如地震等,給予最悲觀的工時預估,機率應小於 1%

得出上面三個數值後,可以用機率分析表示

  1. 預估完成工時: u = (O+4N+P) / 6
  2. 標準差,用來衡量不確定性:(P-O) / 6

德爾菲法

剛才的 PERT 是一個人預估的工時,但是換一個人可能會給出不同的預估結果,仰賴團隊成員給出不同的預估,最後達成共識也是一種方法

主持人請每個成員在他人不知道的狀況下決定預估工時,時間到一起亮牌(數手指之類的),看大家是否有共識,如果有人有很大的歧異,則開始討論分歧的依據,接著下一輪,直到大家給予的評估都差不多才結束

凝聚共識也是很重要的一環,尤其是團隊合作上,從每一個人評估工時的不同,就能去看出對於細節與實作想法上的差異,彌平這類的差異可以讓團隊合作更順暢

大數定律

將大任務拆解成小任務後在估時會比較精準,且經過拆解可以更理解任務的各種面向

結語

書中還有談其他面向如測試 / 練習 / 協作等,算蠻有趣的一本書,明確指出專業人士的區別,其中舉的案例也是歷歷在目,值得在職涯中時時品味

Categories