我想是因為工程師說的"Yes"與"No"的界線都太模糊了, 以致於一個功能, 兩種解讀. 專案經理說登入的功能要完成, 意思是所有流程, 包括沒有登入過的使用者要導到註冊流程, 輸入錯密碼會有錯誤訊息, 忘記密碼可以寄信更改, 登入後可以登出等, 但工程師說"Yes"可能只有包含"輸入一組已經存在的使用者帳號與密碼, 可以登入系統"這樣一條成功路徑. 大叔在書裡面舉的例子都是很寫實的例子, 前線的人最常說的話是: "我已經答應客戶了", "如果我們不這麼做, 我們就會失去這張大單..", 工程師有時消極的回答"我盡量試試看", 專案經理就駝鳥的當成是承諾; 有時專案經理或 Sales 會塑造一種"只有你能拯救我"的氛圍, 工程師也很愛掉入這種陷阱裡面, 但過往的經驗總是一再證明, 急就章的東西拯救不了任何人, 現在欠下的債以後總會回頭來找你. 我們可以把一切推給溝通問題, 但要改善這個問題, 無疑就是需要更多的練習, 說"不"的時候解釋清楚, 說"是"的時候更要確認雙方認知一致. 有趣的是, "拙於溝通"通常是軟體工程師的刻板印象, 甚至還有些"引以為傲"的味道, 有人會說:"我就是不喜歡與人社交, 才當工程師的呀....", 但那只是對自己專業能力要求太低的而已.
我一直覺得測試非常重要, 但不少工程師覺得測試不在自己的工作範圍裡, 或是 debug 不算在開發時間裡, 但是提交有明顯 bug 的程式碼其實就代表沒有自己驗收過交付內容, 等同於沒有完成工作, 我們不見得要採用 TDD 的開發模式, 但是為每個涵蓋邏輯寫測試是基本的要求. 曾經有組員跟我爭論過這個要求, 他說這些邏輯都很直觀, 他不可能會寫錯, 為什麼要寫測試？但測試不只是驗收當下的 code , 也是為了確保之後新加的 code 沒有破壞之前的邏輯, 從測試項目也可以清楚的檢視是否有涵蓋所有要求, 重構的時候也可以回溯當初的 spec, 好處多多. 當下修復測試出現的問題也是基本紀律, 但很多人會以"不嚴重, 只是警告而已"來忽略, 忽略久了, 對測試出現的紅字習以為常, 測試就失去意義了. 所以要嘛就修正 code, 要嘛就修正測試, 不要得過且過的放任紅字成為日常.
作者大大推崇"pair programming", 但我真的無法忍受有人看著我寫 code (尤其我有很多 type 的怪癖), 不過絕對推崇"code review", "沒有被 review 過的 code 不可以被 merge 進來" 是基本紀律. code review 對雙方都有益處, 整個團隊的coding basic style 可以被確立下來, 多看別人的 code, 不只是挑錯, 有時更是學習不同的思考方式; 想到自己的code 會被其他人 review, 在提交前一定會整理確認一下, 不犯下低級錯誤. 另外, 也可以透過code review 了解專案的其他功能, 而不只是專注在自己實作的部份.
MINEBOOK掘冊連結:
https://www.minebook.tw/book_main_page.php?bookid=20_700416
沒有留言:
張貼留言