[讀書心得] SCM 軟體配置管理

書名: SCM 軟體配置管理  作者: 董越

這三天把這本書看完了，我大概 brief 一下每章的一點筆記就好，其實主要是書已經在身上，寫太多出來也沒有太大的必要 XD 大家有興趣再去看看書吧 :D (新年新希望難道沒有一年要看幾本書的目標嗎?! :P)

SCM 是 Software Configuration Management 的縮寫，書中翻為軟體設定管理，簡單的說就是對一個不斷演化的軟體資產做管理，主要有兩個方向，一是針對資產做管理以及儲存，二是適當的控制軟體的品質，像是關注於軟體的整合。

比較精確的定義要參考 IEEE-STD-610，或是你可以參考本書本書的ch01。

Ch02 基本的版本控制
* 即使只有一個人，也要做 SCM
* 防止版本覆蓋: 如果你仔細去細想，在多人開發軟體的時候，同一隻檔案被同時修改的機率非常高，因此防止檔案被別人覆蓋，是很重要的議題。
當然，不同的版本控制工具各有不同的處理方式，第一種是串列的方法，類似我們寫程式處理的 quene 啦，就是當有人要拿檔案去修改，該檔案就會被 lock 住，但是這雖然是一種方法，可是對開發效率來說是偏低的，因為如果檔案一直 lock 住，表示其它的開發人員只能乾等。這種防止覆蓋的方法的版本控制工具的一個例子是 Visual SourceSafe (縮寫 VSS，微軟出的古老版版本控制工具)。

第二種方法是平行，平行的處理手法解決了串列的問題，就是允許多人同時修改同一個地方，在做合併時，工具會判斷什麼時候需要合併，合併哪些東西，大部份情況是可以自動合併的 (像 git 的 auto-merge)，不能的時候就會叫你人工合併 (類似 conflict)。這類的版控工具，像是耳熟的 Subversion(SVN), GIT, ClearCase(CC, 同時支援串列跟平行的方法，是 IBM Rational 出品的商用軟體設定管理工具)。

書本有列一些市面上的版控系統，很多我也沒聽過 XD，但是後面幾個章節主要都是拿 svn, git, ClearCase 來比較，有 ClearCase 的原因我想大概是因為書中有提到他的市佔率蠻高的，老實說我不知道台灣有哪些公司有用到..?! 知道的朋友可以幫忙舉例一下 XD

不同的工具做類似事情的行話不太相同，像是:
* SVN 用 check out, commit, update...etc
* git 用 pull, fetch, merge, add, commit, push..etc
* ClearCase 用 check out, check in... 恩..ClearCase 我覺得比較複雜一點，但是我沒機會接觸到所以沒有特別去記，看看就過去了... 。

假設企業要導入 SCM，也要有人出來處理工具的選擇, 教育訓練, 制定開發流程等等。這也是 SCM Engineer 的工作之一~ 類似的職稱有 CM (簡稱配管), 或是設定經理 (Configuration Manager)。 一樣.. 我也不知道台灣有沒有這樣的缺 ?!  SCM Engineer 我是沒聽過耶 =="(我果然是井底的青蛙)...


Ch03 當代的版本控制方法
* 變更集合的概念 (或是變更套件  change set, change package)
* 小單位的修改就可以交付程式碼，盡量不累積
* 修改前先以拿到最新版的程式碼開始，或是反方向處理，在自己的工作區域修改後常常去更新 Repo 最新程式碼回來，在 git 是指 pull,  在 ClearCase 是指 Rebase。


Ch04 關注整體品質
* 這章主要在提整合。Intergration 主要的使命就是把產品的各部分合在一起，並且保障產品還是可以運作的情況，而不是每個模組, 單元都各自在特定的環境下可以運轉。因為每個地方都是正確的情況下，並不能確保整合在一起後就是正確的。

* 4.2 保障交付的品質: 關於這點，有幾個方向可以努力，一就是寫測試，單元測試與 TDD 是個很好的方法，再來是 Peer Review，或是 Code Inspection (現在很多 Peer Review 工具都有跟版本控制整合，像是 github 上就有幾套，只是大部份都要付費。在我任職過的公司 urAD 曾經對某專案做過 Code Review，還蠻有趣的，每個人都要針對同事發的 pull request 做 review)。還有 Pair Programming，目的也是加強程式品質。

上述的幾個方法，都是靠人來完成，當然也有方法，不是靠人來幫忙達到品質的把關，像是靜態程式分析 (Statis Program Analytics)，利用類似的工具發現程式碼的錯誤等等。畢竟有人就有可能有疏漏, 也有可能有犯錯的機會，所以利用一些工具來相輔相成幫助軟體的品質更好。


Ch05 從原始程式碼到執行中的程式碼
* 軟體的建構有兩種，全量建構 Full Build 以及增量建構 Incremental Build，主要指的是編譯連結的過程。 全量是從頭開始，重新編譯每隻檔案，比較耗時。增量主要是找有差異的重新建構，較快但有風險，相較之下比較沒這麼可靠。不過這個我體會不深，我寫的語言幾乎是不太需要編譯的 XDDD

Ch06 邁向持續整合
* 持續整合: 整合可以更頻繁，也就應該要更頻繁。如果能夠收到工程師的 commit 就開始進行整合是最好，通常也是會寫個 hook，當有人 commit 的時候就去跑 ci。
* 越大的專案，越能夠從持續整合中看到明顯的成效。 (但越大的專案要做持續整合也越難...)。
* CI 的工具有，像是有名的 Jenkins, 或是 CruiseControl (這個我就沒聽過了... )


Ch08 管理文件
* 軟體設定管理當然不只管軟體，也管文件。
* 軟體寫給機器看，文件寫給人看。
* 檔案的命名應該要加上版本號，另外也建議使用具有版本控制功能的文件管理工具。
* 不同文件可能會有保密的不同層級，應該要在文件附註這些資訊。


Ch09 
* 第九章都在講跟 bug 有關的，主要是也提到幾個 Defect Tracking System 缺陷追蹤系統，(Bug 的學名就叫做缺陷)。工具很多像是 Bugzilla, Redmine, Mantis, Trac, BugFree, ClearQuest (IBM Rational 出品的), JIRA。
JIRA, Redmine 我都用過，還蠻喜歡 JIRA，但是商用都是要付費的。
* 對於 bug 的描述一定要做到可以讓開發人員及 QA 可以做到複現，包含遇到的情況, 當時的作業環境。


Ch10
第十章在講遇到 Feature 時的處理方式，另外也提到 Scrum, FDD 等。

* Scrum 是敏捷開發的一種方法，用一種反覆運算, 增量為主的特點來開發軟體。 這裏的增量指的是 Enhancement 代表一些小小的功能請求，想在原有的程式加上一些功能。 (我也打算看一下 Scrum 的書，如果有推薦的書目也歡迎留言推薦給我，謝謝 ! :D )

* 除了可以用 Scrum 來管理這種一個一個的 Feature 之外，也可以用 FDD 也就是特性驅動開發 (Feature Drive Development) (wiki)，FDD 也是一種敏捷開發方法，我有找到一篇文章有興趣可以看看: David Ko的學習之旅 - Feature Driven Development 簡介。
(不過...  FDD 我比較少聽到 XD，大部份聽到 Scrum 比較多)

FDD 對於 Feature 的週期是兩週內完成，Scrum 的週期單位是用一個 Sprint (衝刺) 來算的，通常是 15-30 天，長度由開發團隊決定。

* 在瀑布模型下管理 Feature，要注意一旦決定要執行的計畫就不要去更改他了。(瀑布下要減少變更, 變更是不能夠隨意的發生，但不是指完全不行)

其實我覺得增加 Feature 在大型專案上比較麻煩，因為要往上通報，由主要 Leader 決定開發這個 Feature 的成本是否有意義，因為會影響時程, 開發人力，實際對 user 的方便性跟效益是否是值得的? 會不會引發後續的其他 issue 跟 maintain 時程, 以及相對應的測試 code 都要修改。

* 書中有提到可以成立變更控制委員會 (Change Control Board, CCB)，由一群人來決定是否要執行某個 Feature(我個人覺得有這種會議如果遇到很麻煩的 Feature 應該很容易開的沒完沒了 XDD )。

* Feature 的處理流程，應該要依照 Feature 的程度而有所劃分，並不是所有的 Feature 都要經過嚴格的管理。


CH11
11章在講學院派對 SCM 的理論。讀起來比較悶，感覺很像在唸考試的東西 XD 其實主要在講 CMMI 啦

* SCM 主要由四大部分組成:
1. 設定識別 (Configuration Identification, CI)
2. 設定控制 (Configuration Control)
3. 設定報告狀態 (C... Status Report)
4. 設定稽核 (C.... Audit)


後面章節的我就先不寫了，但都是在講 SCM 在實際場景的舉例，嘻! 有興趣知道可以買回家看看 :) 總之我是覺得，看這種書很快樂 XD 雖然實際上在工作不一定都能用到或是親生經歷，但是知道有什麼方法就夠了(工作與團隊之間，不同階段有不同挑戰)。