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