the clean coder
TRANSCRIPT
Robert C. Martin
• 自稱 Uncle Bob (Bob 大叔 )• 敏捷宣言 (Agile Manifesto) 發起人之一• 魯蛇 (Loser) 到人生勝利組的代表
• https://twitter.com/unclebobmartin
• https://github.com/unclebob
讓 QA 找不出任何問題• 承擔責任• 能對自己所犯的錯誤負責• 練習道歉,必須不會再三犯同樣的錯誤
• 不要破壞軟體功能• 要做的專業,就不能留下 Bug
• 要確信程式碼能正常工作• 測試,使出渾身解數來測• 自動化單元測試• 100% 測試覆蓋率
程式結構的持續改善• 持續重構程式碼 : 讓程式保持固定不變是危險的• 如果不隨時修改,程式碼會僵化改不動• Eagleson's law • 任何一段你自己寫的程式,只要超過六個月沒去看它,就跟別人寫的沒
兩樣了• 無情重構 (merciless refactoring) / 童子軍規則• 對於每個模組,每次簽入一次程式碼,就要讓它比上次簽出時更為簡潔
有了覆蓋率 100% 的自動化測試,不要害怕改壞程式碼
職業道德• 雇主沒有義務確保你的職涯發展• 雇主沒有義務送員工參加培訓課程和會議
• 一周 40 小時的工作時間,應該用來解決雇主的問題• 每周工作 40+20 小時• 前 40 小時給雇主工作,後 20 小時給自己用於學習
• 持續學習:軟體開發人員必須堅持廣泛學習才不至於落伍• 你會找不看醫學期刊的醫生看病 ? 你會聘請不瞭解最新稅法的稅務律師 ?
軟體開發人員必須精通的事項• 設計模式 (Design Patterns)
• 可以描述 GoF 的 23 個設計模式,必且對於 POSA (Patten-Oriented Software Architecture) 書中所介紹的許多模式都有實務上的使用經驗
• 設計原則 (Design Principles)• SOLID
• 方法 (Methods)• XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, Structured Design
• 學科 (Disciplines)• TDD, Object-Oriented Design, Structured Programming, Continuous
Integration, Pair Programming
• 工具 (Artifacts)• UML, DFD, Structure Chart, Petri Net, State Transition Diagram and Table,
Flow Chart, Decision Table
識別「缺乏承諾」的徵兆•需要 (need) / 應當 (should)• 我需要 (need)把這工作做完• 我需要 (need)減肥• 有人應當 (should) 負責去推動這件事
• 讓我們 (Let’s) (而不是讓我 )• 讓我們 (Let’s)把工作做完
• 希望 (hope)/但願 (wish)• 希望 (hope)我明天能完成這個
任務• 但願 (wish)我有時間做這件事• 但願 (wish)電腦能更快一點
基本觀念• 程式碼必須能夠正常工作
Code must work
• 程式碼必須能夠幫你解決客戶提出的問題Code must solve the problem
• 程式碼必須要能和現有系統結合得天衣無縫Code must fit well into the existed system
• 其他程式設計師必須能夠讀懂你的程式碼Code must be readable by other programmers
聚精會神• 心中覺得焦慮的時候不要寫程式• 流態區 (Flow Zone):
• 程式設計師在寫程式時會進入的一種意識高度專注,但思維視野卻會收斂到狹窄的狀態
• 只有練習時才進入流態區,撰寫程式碼時最好避免進入流態區• 因為在此狀態下只是處於一種「淺層冥想」,開發人員並沒有顧及全域,很可能
會作出一些日後得砍掉重練的程式• Pair Programming 是防止進入流態區的方法
• 聽音樂容易進入流態區,並消耗原應用於編寫代碼的腦力資源• 不要怕工作時被人打斷
• 也許下次會輪到你去打斷別人請求幫助• TDD 和 Pair Programming 是應付中斷的好方法
進度延遲•早期檢測、保持透明•根據目標定期衡量進度• 堅決維持你的估算,不要盲目衝刺•縮減範圍才能加快進度,不要盲目衝刺•除非以下條件都滿足,否則絕不加班• 你個人的時間安排允許• 最多加班兩週• 你的老闆 (或要求你加班的人 ) 要有萬一加班失敗的後備方案
練習的方法• Kata (日文 :型 , 武術套路 )• 整套敲擊鍵盤和滑鼠的動作,用來模擬編程問題的解決過程• http://katas.softwarecraftsmanship.org/
• Wasa• 兩個人的 Kata
• 自由練習 (Randori)• 多人參與
自身經驗的拓展• 為開源項目貢獻代碼• 對於練習的職業道德• 利用自己的時間來練習 : 不必限定老闆規定的語言和平台• 保持自己技能不落伍是自己的責任• 練習時你賺不到錢,但練習之後,將得到豐厚的回報
其他•老闆 /客戶的問題就是你的問題• 瞭解業務領域 : 只按照規格說明來撰寫程式,是不專業的•除錯時間也算開發時間,目標是要將除錯時間降到最低• 軟體開發是一場馬拉松,要保持穩定節奏,不要一下衝太快
測試驅動開發 (TDD)
• 如同外科醫師不須極力捍衛”手術前要洗手”,程式設計師也不須極力捍衛 TDD ,因為這些都是順理成章的事
• TDD 的原則• 在撰寫一個單元測試前,不可以撰寫其他程式• 只撰寫剛好無法通過的單元測試,不能編譯也算無法通過• 只撰寫剛好能通過當前測試失敗的產品程式
TDD 的優勢• 確定性• 任何時刻,程式碼有任何修改,都可以執行所有測試
•缺陷注入率• 顯著降低缺陷率
•勇氣• 隨時重構程式,徹底杜絕「放任程式碼劣化而視若無睹」的情況
•文件• 每個單元測試都是一個範例,也是描述系統設計細節的文件
• 設計• 基於測試先行的需要,會迫使你去思考怎樣才是好的設計
避免需求過早精緻化• 不確定原則 (觀察者效應 ) :每次向用戶展示一項功能,他們就獲得
比之前更多的訊息,這些新訊息反過來又會影響它們對整個系統的看法• 預估焦慮:因為需求一定會變 ( 不確定原則 ) ,即使擁有準確的訊息,
預估仍然存在巨大的變數• 盡可能推遲需求精緻化,專業開發人員直到著手開發的前一刻才會把需求具體化•觀念同 Scrum 的延遲決定•需求文件要寫到清楚是很困難的
• 需求文件若有模糊不清之處,都代表著各個利害關係人之間還存在著尚未解決的衝突與分歧 (Tom DeMarco)
驗收測試 (這裡指的是 SIT)
• 目的在於確定需求已經完成•完成的定義 (DoD, the definition of done)• 所有的程式碼的都完成,通過全部的測試, QA 和需求方已經認可
• 人工測試的成本太高 ( 是一種浪費 )•遵循「推遲需求精緻化」的原則,驗收測試應該越晚越好• 盡可能減少 GUI 測試,因為畫面常改,所以這類測試很不穩定,
且不易維護• CI 的系統裡,測試失敗代表緊急狀況,所有人應放下手邊工作一起解決問題
QA 的職責• QA 也是團隊的一部分• QA 與開發人員不是敵對的關係
• 需求規約定義者• 業務人員編寫正常路徑的測試 (happy-path test)• QA 編寫異常狀況的測試 (corner, boundary, unhappy-path)
• 特性描述者• 鑑別系統運行的真實狀況,並將之反饋給開發人員與業務人員
拒絕不必要的會議• 如果會議沒有現實且顯著的成效,應該主動拒絕• 應該謹慎選擇會議,受邀請的會議沒有必要主動參加,參加太多
會議,只能證明你不夠專業• 有些會議是你感興趣的,但當下沒有參加的必要,就要自行判斷
是否花得起時間•老闆的主要任務之一,就是幫助你從某些會議中脫身•收到會議邀請,應主動了解會議議程,如果沒有清楚的議程,可
以禮貌拒絕出席• 如果在會議中,討論的議題不是你應該知道的,就應主動離席
會議中的衝突•凡事不能在五分鐘內解決的爭論,都不能靠辯說解決 •強辯無法解決爭論,最終需要數據
技術爭論很容易走入極端。每一方都有各種說法來支持自己的觀點,只是缺乏資料。在沒有資料的情況下,如果觀點無法在短時間( 5~ 30 分鐘)內達成一致,就永遠無法達成一致。唯一的解決方法是『去取得資料,讓資料來說話』。
專注力點數•點數 (manna) ,出自聖經,也可用線上遊戲生命力點數比喻• 每個人每天都有一定的專注力點數,不能補血• 要妥善安排時間,善用你的專注力點數專注力點數充足時寫程式,專注力點數匱乏時做其他事
預估的定義•什麼是預估 ?• 業務方:承諾,必須做到• 開發方:猜測,不是承諾,是一種機率分布
• 承諾:承諾不能兌現是一種欺騙,避免對不確定的事進行承諾• 預估:沒有承諾色彩,因為不知道要花多少時間,所以叫預估
專業開發人員能清楚分辨預估和承諾,只有在確切知道可以完成的前提下,才會給出承諾,並盡可能說清楚預估的機率分布
如何預估• 原則• 墨菲定律:凡是可能出錯的事就必定會出錯• 除非你已經做過這件事,否則一定無法準確預估時程
• 預估方法• PERT ( 計畫審查技術 )• Delphi ( 德爾菲法 )• 大數法則 : 把大任務切割成小任務,分開預估再加總
PERT (Program Evaluation and Review Technique)• 三元分析法• O: 樂觀預估• N: 常規預估• P: 悲觀預估
• 期望值 = (O + 4N + P) / 6•機率分布標準差 = (P – O) / 6
PERT 例子任務 樂觀預估 常規預估 悲觀預估 期望值 標準差A 1 3 12 4.2 1.8
B 1 1.5 14 3.5 2.2
C 3 6.25 11 6.5 1.3
Total 預估值 : 14天Total 變異數 σ = 3.1317天 (1σ), 20天 (2σ)
Delphi 法• 一群人討論某項任務,預估完成時間,重複討論直到意見一致•討論偏離值發生的原因,取得共識•好處是避免別人的預估影響到自己的判斷
• 方法• 亮手指• 規劃撲克 (Planning Poker)
開發人員之間• 協作性的程式碼共有權 (Collective Ownership)• 團隊中每個成員都能簽出任何模組的程式碼,並做修改• 程式碼所有權是團隊,不是個人
• 結對 (Pairing)• 解決問題的最有效方法• 最有效的程式碼審查方法
團隊合作• 開發人員全部時間投入在一個專案,沒有半個人這件事• 開發人員 與 業務分析師 (含 QA) 的比例, 2:1 是最好的組合• 例如 : 團隊成員 9 人 = 6 Developer + 3 BPA/QA
• 應以團隊找專案,而非以專案來找團隊• 因為團隊合作是有凝聚力的
輔導與經驗傳承•現況 : 失敗的學位教育• 缺少技術方面的傳承、培訓、督導與檢查• 缺少資深人員輔導新人向其傳授技藝的環節
•輔導 : 傳道授業的同時,導師也能從中受益•花時間輔導年輕程式設計師,是資深程式設計師的專業職責•向資深程式設計師尋求輔導,是年輕設計師的專業職責
總結
•專業素養• 開發人員需要具備專業素養
•接受與拒絕的藝術• 當專業人士給出肯定回答時,它們會使用承諾用語,以確保雙方能無誤地明白及理解承諾的內容
•寫程式的奧義• 利用自己的時間練習和學習
•測試策略• 開發人員要擁抱 TDD
•時間管理與預估• 預估是機率分布,不是承諾
•團隊協作與管理• 要幫助他人,遇到問題時也要主
動請別人幫忙
延伸閱讀• 那些年,我們一起上的 BBS: 洪任諭 TED x NCTU 2013• Planning Poker•英文書摘