高效團隊開發:工具與方法 高效团队开发 工具与方法 (图灵程序设计丛书)

池田尚史, 藤倉和明, 井上史彰

  • 出版商: 人民郵電
  • 出版日期: 2015-06-01
  • 定價: $294
  • 售價: 8.5$250
  • 語言: 簡體中文
  • 頁數: 299
  • ISBN: 7115295948
  • ISBN-13: 9787115295941

無法訂購

買這商品的人也買了...

商品描述

<內容介紹>

《高效團隊開發:工具與方法》以團隊開發中所必需的工具的導入方法和使用方法為核心,對團隊開發的整體結構進行概括性的說明。內容涉及團隊開發中發生的問題、版本管理系統、缺陷管理系統、持續集成、持續交付以及回歸測試,並且對“為什麼用那個工具”“為什麼要這樣使用”等開發現場常有的問題進行舉例說明。


<章節目錄>
第1章什麼是團隊開發1
1.1一個人也能進行開發2
1.2團隊開發麵臨的問題3
1.3如何解決這些問題4
1.4本書的構成5
1.4.1第2章:案例分析5
1.4.2第3 ~5章:基礎實踐5
1.4.3第6~7章:持續交付和回歸測試6
1.5閱讀本書前的註意事項7
1.5.1最好的方法是具體問題具體分析7
1.5.2沒有最好的工具7
第2章團隊開發中發生的問題9
2.1案例分析的前提10
2.1.1項目的前提條件10
2.2案例分析(第1天) 11
2.2.1問題1:重要的郵件太多,無法確定處理的優先級11
2.2.2問題2:沒有能用於驗證的環境11
2.2.3問題3:用別名目錄管理分支12
2.2.4問題4:重新製作數據庫比較困難14
2.3案例分析(第1天)中的問題點16
2.3.1問題1:重要的郵件太多,無法確定處理的優先級16
郵件的數量太多,導致重要的郵件被埋沒16
無法進行狀態管理17
直觀性、檢索性較弱17
用郵件來管理項目的課題17
2.3.2問題2:沒有能用於驗證的環境18
2.3.3問題3:用別名目錄管理分支18
2.3.4問題4:重新製作數據庫比較困難19
2.4案例分析(第2天) 22
2.4.1問題5:不運行系統就無法察覺問題22
2.4.2問題6:覆蓋了其他組員修正的代碼22
2.4.3問題7:無法自信地進行代碼重構24
2.4 .4問題8:不知道bug的修正日期,也不能追蹤退化25
2.4.5問題9:沒有靈活使用分支和標籤26
2.4.6問題10:在測試環境、正式環境上無法運行28
2.4.7問題11:發布太複雜,以至於需要發布手冊28
2.5案例分析(第2天)中的問題點30
2.5.1問題5:不運行系統就無法察覺問題30
2.5.2問題6:覆蓋了其他組員修正的代碼31
2.5.3問題7:無法自信地進行代碼重構31
2.5.4問題8:不知道bug的修正日期,也不能追蹤退化33
2.5.5問題9:沒有靈活使用分支和標籤35
2.5 .6問題10:在測試環境、正式環境上無法運行35
2.5.7問題11:發布太複雜,以至於需要發布手冊36
2.6什麼是理想的項目37
2.6.1使用缺陷管理系統對課題等進行統籌管理38
2.6.2盡量使用版本管理系統38
2.6.3準備可以反複驗證的CI系統38
2.6.4將環境的影響控制在最小限度,並隨時可以發布39
2.6.5保留所有記錄以便日後追蹤39
2.7本章總結40
第3章版本管理41
3.1版本管理系統42
3.1.1什麼是版本管理系統42
3.1.2為什麼使用版本管理系統能帶來便利42
能夠保留修改內容這一最基本的記錄43
能夠方便地查看版本之間的差異43
能夠防止錯誤地覆蓋他人修改的代碼43
專欄鎖模式和合併模式44
能夠還原到任意時間點的狀態48
專欄基於文件和基於變更集49
能夠生成多個派生(分支和標籤),保留當時項目狀態的斷面49
3.2版本管理系統的發展變遷51
3.2.1沒有版本管理系統的時代(20世紀70年代以前) 52
3.2.2 RCS的時代(20世紀80年代) 52
3.2.3 CVS的誕生(20世紀90年代) 52
3.2.4 VSS、Perforce等商用工具的誕生(20世紀90年代) 53
3.2.5 Subversion的誕生(2000年以後) 54
3.2.6分佈式版本管理系統的誕生(2005年以後) 54
3.2.7番外篇:GitHub的誕生55
3.2.8版本管理系統的導入情況57
3.3分佈式版本管理系統59
3.3.1使用分佈式版本管理系統的5大原因59
能將代碼庫完整地複製到本地59
運行速度快59
臨時作業的提交易於管理59
分支、合併簡單方便59
可以不受地點的限制進行協作開發60
3.3.2分佈式版本管理系統的缺點60
系統中沒有真正意義上的最新版本60
沒有真正意義上的版本號60
工作流程的配置過於靈活,容易產生混亂61
思維方式的習慣需要一定的時間61
3.4如何使用版本管理系統62
3.4.1前提62
3.4.2版本管理系統管理的對象62
代碼63
需求資料、設計資料等文檔64
數據庫模式、數據64
配置文件64
庫的依賴關係定義65
3.5使用Git順利地推進並行開發66
3.5.1分支的用法66
什麼是分支66
什麼是發布分支(release branch) 66
克隆和建立分支67
提交和提交記錄67
分支的切換68
修正bug後的提交69
合併到master 70
向master進行Push 71
分支使用方法總結72
3.5.2標籤的使用方法72
什麼是標籤72
新建標籤72
標籤的確認73
標籤的取得73
專欄避免使用相同的標籤名和分支名74
標籤使用方法總結75
專欄什麼是DetachedHEAD 76
3.6 Git的開發流程77
3.6.1 Git工作流的模式77
中央集權型工作流77
GitHub型工作流78
3.6.2分支策略的模式79
git—flow 79
github—flow 82
筆者的例子(折衷方案) 83
3.6.3最合適的流程和分支策略因項目而異84
3.7數據庫模式和數據的管理85
3.7.1需要對數據庫模式進行管理的原因85
由數據庫管理員負責對修改進行管理的情況85
修改共享數據庫的模式的情況85
3.7.2應該如何管理數據庫模式86
版本管理的必要條件86
什麼是數據庫遷移86
數據庫遷移的功能87
3.7.3數據庫遷移工具88
Migration(Ruby onRails) 88
south(Django) 88
Migrations Plugin(CakePHP) 89
Evolution(Play Framework) 89
3.7.4具體用法(Evolution) 89
規定89
SQL文件的執行90
開發者之間數據庫模式的同步91
一致性問題的管理93
3.7.5數據庫遷移中的註意點94
3.8配置文件的管理96
3.9依賴關係的管理97
3.9. 1依賴關係管理系統97
JVM語言97
腳本語言98
管理依賴關係的優點98
3.10本章總結100
第4章缺陷管理101
4.1缺陷管理系統102
4.1.1項目進展不順利的原因102
4.1.2用紙、郵件、Excel進行任務管理時的問題103
4.1.3導入缺陷管理系統的優點104
具有任務管理所需的基本功能104
直觀性、檢索性較強104
能夠對信息進行統一管理及共享104
能夠生成各類報表105
能夠和其他系統進行關聯,具有可擴展性105
4.1.4什麼是缺陷驅動開發106
缺陷驅動開發的具體步驟106
專欄徹底貫徹缺陷驅動開發的情況107
4.2主要的缺陷管理系統108
4.2.1 OSS產品108
Trac 108
Redmine 109
Bugzilla 110
Mantis 111
4.2.2商用產品112
JIRA 112
YouTRACK 113
Pivotal Tracker 113
Backlog 114
GitHub 115
4.2.3選擇工具(缺陷管理系統)的要點116
專欄缺陷管理系統的應用事例117
4.3缺陷管理系統與版本管理系統的關聯118
4.3.1通過關聯實現的功能118
從提交鏈接到問題票118
從問題票鏈接到提交118
提交的同時修改問題票的狀態119
4.3.2關聯的配置方法119
4.3. 3 GitHub 119
GitHub的issue 119
Service Hooks 120
GitHub和Pivotal Tracker的關聯121
GitHub和JIRA的關聯123
4.3.4 Trac/Redmine 124
4.3.5 Backlog 124
Backlog和Git的關聯125
Backlog和GitHub的關聯126
4.3.6 Git自帶的Hook的使用方法127
4.4新功能開發、修改bug時的工作流程128
4.4.1工作流程128
A建立問題票128
B指定負責人129
C開發129
D提交129
E Push到代碼庫129
4.5回答“那個bug是什麼時候修正的”的問題131
4.5.1 PivotalTracker的例子131
用記憶中殘留的關鍵字進行檢索131
檢索131
通過問題票查找代碼修改132
4.5.2 Backlog的例子133
檢索134
4.6回答“為什麼要這樣修改”的問題136
……
第5章CI(持續集成)
第6章部署的自動化(持續交付)
第7章回歸測試