Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Clean Coder

Andy Cheng
March 06, 2014
4.4k

The Clean Coder

Andy Cheng

March 06, 2014
Tweet

Transcript

  1. Robert C. Martin • 自稱Uncle Bob (Bob大叔) • 敏捷宣言(Agile Manifesto)發起人之一

    • 魯蛇(Loser)到人生勝利組的代表 • https://twitter.com/unclebobmartin • https://github.com/unclebob
  2. 讓QA找不出任何問題 • 承擔責任 • 能對自己所犯的錯誤負責 • 練習道歉,必須不會再三犯同樣的錯誤 • 不要破壞軟體功能 •

    要做的專業,就不能留下Bug • 要確信程式碼能正常工作 • 測試,使出渾身解數來測 • 自動化單元測試 • 100%測試覆蓋率
  3. 程式結構的持續改善 • 持續重構程式碼: 讓程式保持固定不變是危險的 • 如果不隨時修改,程式碼會僵化改不動 • Eagleson's law •

    任何一段你自己寫的程式,只要超過六個月沒去看它,就跟別人寫的沒 兩樣了 • 無情重構(merciless refactoring) / 童子軍規則 • 對於每個模組,每次簽入一次程式碼,就要讓它比上次簽出時更為簡潔 有了覆蓋率100%的自動化測試,不要害怕改壞程式碼
  4. 職業道德 • 雇主沒有義務確保你的職涯發展 • 雇主沒有義務送員工參加培訓課程和會議 • 一周40小時的工作時間,應該用來解決雇主的問題 • 每周工作40+20小時 •

    前40小時給雇主工作,後20小時給自己用於學習 • 持續學習:軟體開發人員必須堅持廣泛學習才不至於落伍 • 你會找不看醫學期刊的醫生看病? 你會聘請不瞭解最新稅法的稅務律師?
  5. 軟體開發人員必須精通的事項 • 設計模式 (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
  6. 識別「缺乏承諾」的徵兆 • 需要(need) / 應當(should) • 我需要(need)把這工作做完 • 我需要(need)減肥 •

    有人應當(should)負責去推動這 件事 • 讓我們(Let’s) (而不是讓我) • 讓我們(Let’s)把工作做完 • 希望(hope)/但願(wish) • 希望(hope)我明天能完成這個任 務 • 但願(wish)我有時間做這件事 • 但願(wish)電腦能更快一點
  7. 基本觀念 • 程式碼必須能夠正常工作 Code must work • 程式碼必須能夠幫你解決客戶提出的問題 Code must

    solve the problem • 程式碼必須要能和現有系統結合得天衣無縫 Code must fit well into the existed system • 其他程式設計師必須能夠讀懂你的程式碼 Code must be readable by other programmers
  8. 聚精會神 • 心中覺得焦慮的時候不要寫程式 • 流態區 (Flow Zone): • 程式設計師在寫程式時會進入的一種意識高度專注,但思維視野卻會收斂到狹 窄的狀態

    • 只有練習時才進入流態區,撰寫程式碼時最好避免進入流態區 • 因為在此狀態下只是處於一種「淺層冥想」,開發人員並沒有顧及全域,很可 能會作出一些日後得砍掉重練的程式 • Pair Programming是防止進入流態區的方法 • 聽音樂容易進入流態區,並消耗原應用於編寫代碼的腦力資源 • 不要怕工作時被人打斷 • 也許下次會輪到你去打斷別人請求幫助 • TDD和Pair Programming是應付中斷的好方法
  9. 進度延遲 • 早期檢測、保持透明 • 根據目標定期衡量進度 • 堅決維持你的估算,不要盲目衝刺 • 縮減範圍才能加快進度,不要盲目衝刺 •

    除非以下條件都滿足,否則絕不加班 • 你個人的時間安排允許 • 最多加班兩週 • 你的老闆(或要求你加班的人)要有萬一加班失敗的後備方案
  10. TDD的優勢 • 確定性 • 任何時刻,程式碼有任何修改,都可以執行所有測試 • 缺陷注入率 • 顯著降低缺陷率 •

    勇氣 • 隨時重構程式,徹底杜絕「放任程式碼劣化而視若無睹」的情況 • 文件 • 每個單元測試都是一個範例,也是描述系統設計細節的文件 • 設計 • 基於測試先行的需要,會迫使你去思考怎樣才是好的設計
  11. 避免需求過早精緻化 • 不確定原則 (觀察者效應):每次向用戶展示一項功能,他們就獲 得比之前更多的訊息,這些新訊息反過來又會影響它們對整個系 統的看法 • 預估焦慮:因為需求一定會變 (不確定原則),即使擁有準確的訊 息,預估仍然存在巨大的變數

    • 盡可能推遲需求精緻化,專業開發人員直到著手開發的前一刻才 會把需求具體化 • 觀念同Scrum的延遲決定 • 需求文件要寫到清楚是很困難的 • 需求文件若有模糊不清之處,都代表著各個利害關係人之間還存在著尚 未解決的衝突與分歧 (Tom DeMarco)
  12. 驗收測試 (這裡指的是SIT) • 目的在於確定需求已經完成 • 完成的定義(DoD, the definition of done)

    • 所有的程式碼的都完成,通過全部的測試,QA和需求方已經認可 • 人工測試的成本太高 (是一種浪費) • 遵循「推遲需求精緻化」的原則,驗收測試應該越晚越好 • 盡可能減少GUI測試,因為畫面常改,所以這類測試很不穩定, 且不易維護 • CI的系統裡,測試失敗代表緊急狀況,所有人應放下手邊工作一 起解決問題
  13. QA的職責 • QA也是團隊的一部分 • QA與開發人員不是敵對的關係 • 需求規約定義者 • 業務人員編寫正常路徑的測試 (happy-path

    test) • QA編寫異常狀況的測試 (corner, boundary, unhappy-path) • 特性描述者 • 鑑別系統運行的真實狀況,並將之反饋給開發人員與業務人員
  14. 拒絕不必要的會議 • 如果會議沒有現實且顯著的成效,應該主動拒絕 • 應該謹慎選擇會議,受邀請的會議沒有必要主動參加,參加太多 會議,只能證明你不夠專業 • 有些會議是你感興趣的,但當下沒有參加的必要,就要自行判斷 是否花得起時間 •

    老闆的主要任務之一,就是幫助你從某些會議中脫身 • 收到會議邀請,應主動了解會議議程,如果沒有清楚的議程,可 以禮貌拒絕出席 • 如果在會議中,討論的議題不是你應該知道的,就應主動離席
  15. 立會 (Stand up meeting) • 站著開會 • 每個人輪流回答以下問題 • 我昨天做了什麼

    • 我今天打算做什麼 • 我遇到了什麼問題 • 每個問題的回答時間不超過20秒
  16. 預估的定義 • 什麼是預估? • 業務方:承諾,必須做到 • 開發方:猜測,不是承諾,是一種機率分布 • 承諾:承諾不能兌現是一種欺騙,避免對不確定的事進行承諾 •

    預估:沒有承諾色彩,因為不知道要花多少時間,所以叫預估 專業開發人員能清楚分辨預估和承諾,只有在確切知道可以完成 的前提下,才會給出承諾,並盡可能說清楚預估的機率分布
  17. 如何預估 • 原則 • 墨菲定律:凡是可能出錯的事就必定會出錯 • 除非你已經做過這件事,否則一定無法準確預估時程 • 預估方法 •

    PERT (計畫審查技術) • Delphi (德爾菲法) • 大數法則: 把大任務切割成小任務,分開預估再加總
  18. PERT (Program Evaluation and Review Technique) • 三元分析法 • O:

    樂觀預估 • N: 常規預估 • P: 悲觀預估 • 期望值 = (O + 4N + P) / 6 • 機率分布標準差 = (P – O) / 6
  19. 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.13 17天(1σ), 20天(2σ)
  20. 輔導與經驗傳承 • 現況: 失敗的學位教育 • 缺少技術方面的傳承、培訓、督導與檢查 • 缺少資深人員輔導新人向其傳授技藝的環節 • 輔導:

    傳道授業的同時,導師也能從中受益 • 花時間輔導年輕程式設計師,是資深程式設計師的專業職責 • 向資深程式設計師尋求輔導,是年輕設計師的專業職責
  21. 總結 •專業素養 • 開發人員需要具備專業素養 •接受與拒絕的藝術 • 當專業人士給出肯定回答時,它 們會使用承諾用語,以確保雙方 能無誤地明白及理解承諾的內容 •寫程式的奧義

    • 利用自己的時間練習和學習 • 測試策略 • 開發人員要擁抱TDD • 時間管理與預估 • 預估是機率分布,不是承諾 • 團隊協作與管理 • 要幫助他人,遇到問題時也要主 動請別人幫忙