高效團隊開發

第1章 什麼是團隊開發

1.團隊開發

​ 如果軟體的規模超過一定程度，僅由一個人把控產品的所有內 容就比較困難了。不難想象，這時候就需要由多人組成團隊進行開發。

​ 即：由多人開發程式的體制稱為團隊開發

第2章 團隊開發所面臨的問題

1.重要事情太多，無法確定處理的優先順序

2.沒有能用於驗證的環境，即生產環境與部署環境不一致

3.部署的專案程式碼版本名字容易混淆，沒有用工具生產版本號

4.重新制作資料庫比較困難

5.程式碼一整合就出問題

6.覆蓋了其他組員修正的程式碼

7.無法自信地進行程式碼重構

8.不知道bug的修正日期，也不能追蹤退化

9.沒有靈活使用分支和標籤

10.在測試環境、正式環境上無法執行，忘記安裝本機上的庫

11.釋出太複雜，以至於要釋出手冊

第3章 版本管理

3.1 什麼是版本管理系統

​ 版本管理系統是將什麼時候、誰、對檔案做了怎樣的修改這樣的資訊以版本的形式儲存並進行管理的系統。這裡提到的檔案當然包括程式碼，但不是說版本管理系統只能管理程式碼的版本。

3.2 為什麼使用版本管理系統能帶來便利

● 能夠保留修改內容這一最基本的記錄 ● 能夠方便地檢視版本之間的差異 ● 能夠防止錯誤地覆蓋別人修改的程式碼 ● 能夠還原到任意時間點的狀態 ● 能夠生成多個派生（分支和標籤），保留當時專案狀態的截面 ● 能夠保留修改內容這一最基本的記錄

第4章 缺陷管理

4.1 缺陷管理系統

缺陷管理系統的優點：

1.具有任務管理所需的基本功能

●“必須要做什麼”這樣的任務定義 ●“誰來做”這樣的職責分配 ●“什麼時候完成”這樣的期限管理 ●“現在正處於作業中還是已經完成了”這樣的狀態管理

2.直觀性、檢索性較強

3.能夠對資訊進行統一管理及共享

4.能夠生成各類報表

5.能夠和其他系統進行關聯，具有可擴充套件性

4.2 主要的缺陷管理系統

4.2.1 OSS產品(Open Source Software)

Trac

​ TracC是基於 Python 的缺陷管理系統。它匯入簡單，印象中過去幾乎所有的開源專案都使用 Trac，之後被後來的 Redmine 以及SaaS（Software as a Service）形式的 GitHub 和 PivotalTracker 等逐漸取代，最近已經很少看到了。但如果要說上手簡單的話，Trac 至今依然是第一選擇。

Redmine

​ Redmine是比 Trac 稍晚的基於 Ruby on Rails 框架的缺陷管理系 統。因此，使用 Ruby on Rails 的專案匯入 Redmine 的門檻會比較低。

Bugzilla

​ Bugzilla是基於 Perl 的缺陷管理系統。原本是 Netscape 公司內部的系統，後來被作為 OSS 公開。現在由 Mozilla 基金會繼續開發，可以說是 OSS 界最具“歷史和傳統”性質的缺陷管理系統。

Mantis

​ Mantis是基於 PHP 的缺陷管理系統。由日本人開發，過去在日本曾被廣泛使用，但近年來幾乎看不到了。新專案一般不會使用Mantis，但在參加歷史較久的專案時，還是有機會看到 Mantis 的。

JIRA

​ JIRAA 是由 Atlassian有償提供的基於 Java 的缺陷管理系統。雖說是商用的，但有 30 天的免費試用期。該產品可以以安裝檔案或 SaaS 的形式提供，功能豐富。如果專案預算允許的話，可以考慮使用 JIRA。

YouTRACK

​ YouTRACK是以 IntelliJ IDEA 等 IDE 出名的 JerBrains 所提供的基於 Java 的缺陷管理系統。這也是一款收費軟體，但 10 個使用者之內的可以免費使用。提供安裝檔案和 SaaS 兩種形式。

Pivotal Tracke

​ Pivotal Tracker是 PivotalLab 提供的缺陷管理系統。特別適 合於敏捷開發的 Scrum 開發流程。只提供 SaaS 形式的產品。

Backlog

​ Backlog是由日本的 nulab提供的缺陷管理系統。支援SaaS 和安裝檔案兩種形式。因為是日本公司的產品，所以對日語的支援方面完全沒有問題，當然也支援多語言，包括中文 C。

GitHub

​ 作為缺陷管理系統，GitHub 同樣具備不俗的功能。檢索功能等可能稍微弱了些，但和程式碼管理的互動做得非常出色，還具備 Wiki 的功能。並且還有名為 GitHub Pages的用於建立專案網頁的功能，以及類似於 Travis CI 的 CI 工具。可以毫不誇張地說，GitHub 能夠提供 OSS 專案所需要的所有功能。

第5章 CI(持續整合)

5.1 什麼是 CI（持續整合）

整合（integration）

​ 將各個成員的工作成果集中到一處進行整合，直到形成可以執行的 系統，各個成員的開發工作才有了意義，才能進行測試，最終才能以產 品的形式向顧客提供價值。 ​ 整合，具體來說就是像下面這樣執行 build 和測試的流程。

● 將所有的程式碼集中到一處 ● 設定依賴程式庫等的路徑 ● 必要的情況下進行編譯 ● 進行資料庫構建和資料載入 ● 必要的情況下對中介軟體進行配置和啟動 ● 實施單元測試、整合測試、使用者驗收測試等

持續地進行整合就是 CI

​ 將這些整合處理流程持續地執行，就是 CI（Continuous Integration，持續整合）。

CI的必要條件

● 版本管理系統 ● build 工具 ● 測試程式碼 ● CI 工具

第6章 部署的自動化(持續交付)

​ 所有部署相關的作業都應該實現自動化”。這裡所說的部署是指將開發的程式碼以能夠使用的狀態放置到伺服器上這一連序列為。

部署自動化方面的共識

1 要全部採用版本管理 2 所有的環境都要用同樣的方式來構建 3 要實現釋出工作的自動化，並事先進行驗證 4 要反覆多次進行測試

第7章 迴歸測試

7.1 什麼是迴歸測試

​ 迴歸測試是以檢查退化為目的的測試

​ 一般來說這類測試和使用系統的使用者一樣，利用瀏覽器進行輸入或 頁面遷移，並測試是否得到所期待的結果或頁面。因此執行一個個測試 用例的時間往往變得很長，如果是長年運維的系統，到所有測試執行結 束為止耗費大量時間的情況並不罕見。

7.2 什麼是 Selenium

​ Selenium是實現 Web 應用程式的功能測試以及整合測試自動化的 瀏覽器驅動測試工具群，具備以 Web 應用程式的測試自動化為特點的各 類功能。 ​ 和使用系統的使用者相同，在瀏覽器上進行的滑鼠操作、在表單中輸 入文字或者開啟頁面時，Selenium 能夠檢查頁面的內容是否正確顯示、 檢查表單的值以及驗證頁面內執行的 JavaScript 等。因此藉助 Selenium 能夠重複實施至今為止手動操作的測試。