☆☆☆☆☆




點擊這裡下載

類似圖書 點擊查看全場最低價

---

內容簡介

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

作者簡介

池田尚史（作者）
DeNA軟件開發工程師。曾做過IT顧問、程序員，從事過軟件包開發、Web服務開發。Java的Web應用框架Play Framework 1的提交者。負責本書第1章~第5章，其中第2章的案例分析都是基於自身的實際經驗編寫的。
Twitter @ikeike443

藤倉和明（作者）
想能（SHANON）基礎設施工程師。負責公司內部基礎設施及服務環境的安全保障，緻力於推動應用部署的自動化，並基於這方麵豐富的實踐經驗，完成瞭本書第6章。喜歡OpenVZ、LXC等容器型虛擬化技術。
Twitter @fujya

井上史彰（作者）
想能（SHANON）軟件工程師、QA工程師，現為想能信息科技（上海）有限公司總經理。開發經驗豐富，緻力於推動高效的自動化測試。負責本書第7章。
E-mail fu.inoue@gmail.com

嚴聖逸（譯者）
畢業於上海交通大學。8年軟件開發經驗，期間赴日本工作。現就職於想能信息科技（上海）有限公司，從事基於雲平颱的客戶關係管理及各類營銷自動化係統的開發，側重於對持續集成、自動化部署、自動化測試以及相關的開源工具的研究。本書所介紹的即是譯者日常工作中所應用的開發流程以及工具。

目錄

目錄

第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
專欄　什麼是Detached HEAD　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　on Rails）　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　Pivotal Tracker的例子　131
用記憶中殘留的關鍵字進行檢索　131
檢索　131
通過問題票查找代碼修改　132
4．5．2　Backlog的例子　133
檢索　134
4．6　迴答“為什麼要這樣修改”的問題　136

精彩書摘

　　《高效團隊開發 工具與方法》：
　　3.7.2 應該如何管理數據庫模式
　　對數據庫模式進行版本管理，應該管理什麼？又怎麼管理呢？讓我們具體地來看一下。這裏假設數據庫為MySQL或PostgreSQL等，也就是說使用瞭RDBMS，以此為前提來繼續下麵的話題。但是這裏的數據庫並不局限於RDBMS，文本文件、XML文件、對象數據庫以及最近使用頻率逐漸增加的MongoDB等NoSQL數據庫，它們的思考方法也是完全相同的。
　　版本管理的必要條件
　　對數據庫模式進行版本管理的必要條件中，比較重要的是以下3個。
　　無論什麼環境都能用相同的步驟來構建數據庫
　　能夠反復執行多次
　　文本文件
　　上麵這些也是和CI相關聯的思考方法。CI相關的內容將在第5章進行說明。對於數據庫模式，和代碼一樣進行版本管理，無論任何環境都能反復構建，這一點是非常重要的。另外，為瞭用版本管理係統方便地進行閤並，以文本文件的形式管理模式也是很重要的。
　　例如有的開發現場使用商用的GUI工具來建立數據庫模式，這樣的工具有時反而會影響團隊開發的效率。因此一定要以程序能夠反復執行的文本文件形式來管理數據庫模式。
　　什麼是數據庫遷移
　　數據庫模式的CI稱為CDBI（Continuous DataBase Integration）。《持續集成：軟件質量改進和風險降低之道》中也以專門的章節對其進行瞭說明。但是最近比起CDBI，使用從RubyonRails的工具名（Migration）衍生而來的“數據遷移”這個叫法的人似乎更多一些。
　　……

前言/序言

高效團隊開發 工具與方法 下載 mobi epub pdf txt 電子書

評分☆☆☆☆☆

在前進的道理上需要多讀一些書

評分☆☆☆☆☆

的書都比較經典。

評分☆☆☆☆☆

送貨及時,小型圖書館逐漸豐富館藏

評分☆☆☆☆☆

過於泛泛瞭

評分☆☆☆☆☆

這本書各種工具介紹的比較全麵，五星推薦！

評分☆☆☆☆☆

好書，值得一看，很有啓發~

評分☆☆☆☆☆

送貨速度很快！！！！

評分☆☆☆☆☆

速度很快，書也不錯。。。

評分☆☆☆☆☆

慢慢看。。。。。。。

類似圖書 點擊查看全場最低價

查看全網最低價