Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
The Clean Coder
A Code of Conduct for Professional Programmers
Andy Cheng
2014.3.6
Robert C. Martin
• 自稱Uncle Bob (Bob大叔)
• 敏捷宣言(Agile Manifesto)發起人之一
• 魯蛇(Loser)到人生勝利組的代表
• https://twitter.com/unclebobmar...
Uncle Bob的著作
大綱
• 專業素養
• 接受與拒絕的藝術
• 寫程式的奧義
•測試策略
•時間管理與預估
•團隊協作與管理
專業素養
希波克拉底誓言 (Hippocratic oath)
作為一個專業人士,首要職責與目標是盡其所能行有益之事
讓QA找不出任何問題
• 承擔責任
• 能對自己所犯的錯誤負責
• 練習道歉,必須不會再三犯同樣的錯誤
• 不要破壞軟體功能
• 要做的專業,就不能留下Bug
• 要確信程式碼能正常工作
• 測試,使出渾身解數來測
• 自動化單元測試
• 10...
程式結構的持續改善
• 持續重構程式碼: 讓程式保持固定不變是危險的
• 如果不隨時修改,程式碼會僵化改不動
• Eagleson's law
• 任何一段你自己寫的程式,只要超過六個月沒去看它,就跟別人寫的沒
兩樣了
• 無情重構(merci...
職業道德
• 雇主沒有義務確保你的職涯發展
• 雇主沒有義務送員工參加培訓課程和會議
• 一周40小時的工作時間,應該用來解決雇主的問題
• 每周工作40+20小時
• 前40小時給雇主工作,後20小時給自己用於學習
• 持續學習:軟體開發人員...
軟體開發人員必須精通的事項
• 設計模式 (Design Patterns)
• 可以描述GoF的23個設計模式,必且對於POSA (Patten-Oriented Software
Architecture) 書中所介紹的許多模式都有實務上的...
接受與拒絕的藝術
拒絕的藝術: 學會說不
• 行就是行,不行就是不行,不要說「試看看」
• 嘗試不是積極的行為,代表沒有盡全力
• 要考慮說「是」的成本,因為客戶永遠不像你那麼在乎
• 學會說不,才是專業的態度
接受代表承諾
• 承諾用語
• 口頭上說(Say)自己將會去做
• 心裡認真(Mean)對待自己所做出的承諾
• 真的付諸行動去做(Do)
識別「缺乏承諾」的徵兆
• 需要(need) / 應當(should)
• 我需要(need)把這工作做完
• 我需要(need)減肥
• 有人應當(should)負責去推動這
件事
• 讓我們(Let’s) (而不是讓我)
• 讓我們(Let...
真正的承諾是
• 你對自己將做某件事做了清楚的事實陳述,並明確說明完成期限
• 我將在星期二之前完成這個任務
專業人士不需要對所有請求都回答「是」
說「不」後,但仍應努力尋求創新方法,盡可能做到有求必應
寫程式的奧義
基本觀念
• 程式碼必須能夠正常工作
Code must work
• 程式碼必須能夠幫你解決客戶提出的問題
Code must solve the problem
• 程式碼必須要能和現有系統結合得天衣無縫
Code must fit wel...
聚精會神
• 心中覺得焦慮的時候不要寫程式
• 流態區 (Flow Zone):
• 程式設計師在寫程式時會進入的一種意識高度專注,但思維視野卻會收斂到狹
窄的狀態
• 只有練習時才進入流態區,撰寫程式碼時最好避免進入流態區
• 因為在此狀態下...
進度延遲
• 早期檢測、保持透明
• 根據目標定期衡量進度
• 堅決維持你的估算,不要盲目衝刺
• 縮減範圍才能加快進度,不要盲目衝刺
• 除非以下條件都滿足,否則絕不加班
• 你個人的時間安排允許
• 最多加班兩週
• 你的老闆(或要求你加班...
練習
• 練習: 熟能生巧,工作之餘練習技能,以其自我提升
• 看看音樂家如何掌握演練技能
• 盡可能重複編碼與測試過程,並迅速作出決定
• 重點不是解決問題,而是練習解決問題需要的動作和決策
練習的方法
• Kata (日文:型, 武術套路)
• 整套敲擊鍵盤和滑鼠的動作,用來模擬編程問題的解決過程
• http://katas.softwarecraftsmanship.org/
• Wasa
• 兩個人的Kata
• 自由練習 ...
自身經驗的拓展
• 為開源項目貢獻代碼
• 對於練習的職業道德
• 利用自己的時間來練習: 不必限定老闆規定的語言和平台
• 保持自己技能不落伍是自己的責任
• 練習時你賺不到錢,但練習之後,將得到豐厚的回報
其他
• 老闆/客戶的問題就是你的問題
• 瞭解業務領域: 只按照規格說明來撰寫程式,是不專業的
• 除錯時間也算開發時間,目標是要將除錯時間降到最低
• 軟體開發是一場馬拉松,要保持穩定節奏,不要一下衝太快
測試策略
自動化測試金字塔
人工測試的覆蓋率最低
單元測試的覆蓋率最高
測試驅動開發(TDD)
• 如同外科醫師不須極力捍衛”手術前要洗手”,程式設計師也不須
極力捍衛TDD,因為這些都是順理成章的事
• TDD的原則
• 在撰寫一個單元測試前,不可以撰寫其他程式
• 只撰寫剛好無法通過的單元測試,不能編譯也算無法...
TDD的優勢
• 確定性
• 任何時刻,程式碼有任何修改,都可以執行所有測試
• 缺陷注入率
• 顯著降低缺陷率
• 勇氣
• 隨時重構程式,徹底杜絕「放任程式碼劣化而視若無睹」的情況
• 文件
• 每個單元測試都是一個範例,也是描述系統設計細...
避免需求過早精緻化
• 不確定原則 (觀察者效應):每次向用戶展示一項功能,他們就獲
得比之前更多的訊息,這些新訊息反過來又會影響它們對整個系
統的看法
• 預估焦慮:因為需求一定會變 (不確定原則),即使擁有準確的訊
息,預估仍然存在巨大的變...
驗收測試 (這裡指的是SIT)
• 目的在於確定需求已經完成
• 完成的定義(DoD, the definition of done)
• 所有的程式碼的都完成,通過全部的測試,QA和需求方已經認可
• 人工測試的成本太高 (是一種浪費)
• ...
QA的職責
• QA也是團隊的一部分
• QA與開發人員不是敵對的關係
• 需求規約定義者
• 業務人員編寫正常路徑的測試 (happy-path test)
• QA編寫異常狀況的測試 (corner, boundary, unhappy-p...
時間管理與預估
會議
• 會議的成本是每人每小時200美元 (NTD 6,000元)
• 會議是必須的
• 會議浪費大量時間
• 要拒絕不必要的會議
拒絕不必要的會議
• 如果會議沒有現實且顯著的成效,應該主動拒絕
• 應該謹慎選擇會議,受邀請的會議沒有必要主動參加,參加太多
會議,只能證明你不夠專業
• 有些會議是你感興趣的,但當下沒有參加的必要,就要自行判斷
是否花得起時間
• 老闆的主...
立會 (Stand up meeting)
• 站著開會
• 每個人輪流回答以下問題
• 我昨天做了什麼
• 我今天打算做什麼
• 我遇到了什麼問題
• 每個問題的回答時間不超過20秒
會議中的衝突
• 凡事不能在五分鐘內解決的爭論,都不能靠辯說解決
• 強辯無法解決爭論,最終需要數據
技術爭論很容易走入極端。每一方都有各種說法來支持自己的觀
點,只是缺乏資料。在沒有資料的情況下,如果觀點無法在短時
間(5~30 分鐘)內達...
專注力點數
• 點數(manna),出自聖經,也可用線上遊戲生命力點數比喻
• 每個人每天都有一定的專注力點數,不能補血
• 要妥善安排時間,善用你的專注力點數
專注力點數充足時寫程式,專注力點數匱乏時做其他事
番茄工作法
• 計時25分鐘內(一個番茄時間)不要讓任何事干擾你的工作
• 干擾的事,延到下個25分鐘處理
• 每25分鐘後,休息5分鐘
• 做完4個番茄時間後,休息30分鐘
預估的定義
• 什麼是預估?
• 業務方:承諾,必須做到
• 開發方:猜測,不是承諾,是一種機率分布
• 承諾:承諾不能兌現是一種欺騙,避免對不確定的事進行承諾
• 預估:沒有承諾色彩,因為不知道要花多少時間,所以叫預估
專業開發人員能清楚分...
預估是一種機率分布
如何預估
• 原則
• 墨菲定律:凡是可能出錯的事就必定會出錯
• 除非你已經做過這件事,否則一定無法準確預估時程
• 預估方法
• PERT (計畫審查技術)
• Delphi (德爾菲法)
• 大數法則: 把大任務切割成小任務,分開預估再加總
PERT
(Program Evaluation and Review Technique)
• 三元分析法
• O: 樂觀預估
• N: 常規預估
• P: 悲觀預估
• 期望值 = (O + 4N + P) / 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.1...
Delphi法
• 一群人討論某項任務,預估完成時間,重複討論直到意見一致
• 討論偏離值發生的原因,取得共識
• 好處是避免別人的預估影響到自己的判斷
• 方法
• 亮手指
• 規劃撲克(Planning Poker)
團隊協作與管理
開發人員之間
• 協作性的程式碼共有權 (Collective Ownership)
• 團隊中每個成員都能簽出任何模組的程式碼,並做修改
• 程式碼所有權是團隊,不是個人
• 結對 (Pairing)
• 解決問題的最有效方法
• 最有效的程...
團隊合作
• 開發人員全部時間投入在一個專案,沒有半個人這件事
• 開發人員 與 業務分析師(含QA)的比例,2:1是最好的組合
• 例如: 團隊成員9人 = 6 Developer + 3 BPA/QA
• 應以團隊找專案,而非以專案來找團隊...
團隊紀律
• 程式設計師並非天生的協作者,需要透過紀律原則來驅動大家保
持良好的協作
• 即使在危機中仍要堅信你平時遵守的紀律原則
輔導與經驗傳承
• 現況: 失敗的學位教育
• 缺少技術方面的傳承、培訓、督導與檢查
• 缺少資深人員輔導新人向其傳授技藝的環節
• 輔導: 傳道授業的同時,導師也能從中受益
• 花時間輔導年輕程式設計師,是資深程式設計師的專業職責
• 向資深...
總結
• 專業素養
• 開發人員需要具備專業素養
• 接受與拒絕的藝術
• 當專業人士給出肯定回答時,它
們會使用承諾用語,以確保雙方
能無誤地明白及理解承諾的內容
• 寫程式的奧義
• 利用自己的時間練習和學習
•測試策略
• 開發人員要擁抱...
延伸閱讀
• 那些年,我們一起上的 BBS: 洪任諭 TED x NCTU 2013
• Planning Poker
• 英文書摘
Nächste SlideShare
Wird geladen in …5
×

The clean coder

343 Aufrufe

Veröffentlicht am

The clean coder 讀書心得

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

The clean coder

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

×