29章Integration 讀書筆記

先說點閑話吧，昨天電腦加了一根１Ｇ記憶體，現在是２Ｇ。感覺非常爽，開啟live writer的速度明顯快了，寫部落格的心情也很爽。今天《代碼大全》看完了30章，看到772頁，總共只有912頁，下周就可以搞定了。這是我看的第二本超過800頁的英文原版書籍（testing 那章沒認真看），也挺有成就感。

明天就要在SK 辦理離職了，終於要回紫光了，這裡兩個月最大收貨估計就是看代碼大全了，還看了周愛民的《大道至簡》是本非常不錯的書，書中都是自己的所見所想，不過那個時候還沒有寫部落格的想法。一些體會也沒有寫下來，過兩天沒事再補上。還有最近出來的《夢斷代碼》，韓磊翻譯，每天睡覺的時候看看，看完了也要寫寫。以前高中作文800字對我來說都是考驗啊，現在寫了四個月的總結，每天一千字讓我寫作有了很大提高。以後我一定也要像周愛民，韓磊那樣，自己也出本書。書名暫訂為《the art of abap programming》或者《the abap programming lanaugae》，比黃佳的那本肯定要高端。扯了好多其它的，還是進入正題吧。

   1. Importance of the Integration Approach

國外作者最有意思的地方，喜歡拿生活中的例子來打比方，或者引用著名作家的的話作為文章的開頭．為了證明整合的重要性拿了張華盛頓大學體育場的圖片作為例子．圖片如下：

steve mcconnell就是強，看到一堆廢鐵還可以想到整合測試．這做體育館本來設計是沒有缺陷的，建造完之後每一處的受力都滿足要求．但是並沒有保證建造過程中它的受力都是在承受範圍之內的．如同我們的軟體，如果我們弄錯了順序可能造成軟體難於測試，難於調試等，最終就和這座體育場一樣崩塌了．

作者認為繼承測試是一個非常複雜的活動，不應該把它作為測試的一部分．不管怎樣，我們只要認識到了它的重要性即可，叫什麼名字並不重要．從繼承測試中我們可以獲得諸多好處，不過我現在項目經驗仍為０，體會不到太多．

   2. Integration Frequency—Phased or Incremental?

關於這點是老生常談了，究竟是階段性的進行繼承測試還是漸增性的進行。對於階段性的是比較省事，對於小型項目還行。但是對於大項目一次測試太多類和組件，明顯增加了複雜度，有些錯誤是難以跟蹤和發現的。使用漸增式的就像滾雪球一般，一次一點，或許只是一個類，但是錯誤比較容易發現。而且對於同一個類如果很早就繼承了的話會反覆測試，讓系統更加可靠。同時專案經理可以更好的檢測項目進度，控制好進度。看到系統完成了50%的功能總比聽到說代碼已經完成了50%要好。看到系統的功能一個一個實現，客戶也會非常開心，估計得經常請吃飯了。

   3. Incremental Integration Strategies

漸增式的繼承測試有很多不同的策略，並沒有最佳的，看在不同情況下選用那個比較合適而已。有些已經非常熟悉了，介紹以前軟體工程課上沒有聽到的吧。

• Feature-Oriented Integration

何謂feature，我想應該是系統的功能。每次繼承測試時，按功能來劃分。

這樣可能碰到的一個問題是一個功能可能包含太多的類，那麼可以對一個功能進行迭代的繼承測試，迭代時可以用其它的方法來進行繼承。使用這種方法我覺得思路很清晰，有以下幾個好處。一是不需要樁函數，不需要額外再寫代碼。一個特性它調用的模組都自己包含了。二是因為添加的特性都是一個比較獨立和完整的功能，那麼可以確定項目是穩步向前的。三是這種方式似乎天生就是為物件導向而生，和物件導向配合的很好。    

整合當然不止這一種方法，  其它的方法就在代碼大全上自己看吧。實際中我認為可以將幾種方法混合，以達到更好的效果。

    4. Daily Build and Smoke Test

  關於這一小節書中談的很多，我覺得它的思想就是一個。為了減少項目的複雜度，對代碼每天進行編譯。更新版本，進行找錯。號稱windows NT就是這麼開發的，儘管build一次要19個小時。更變態的是office和windows 2000的團隊在項目晚期時人手一個bp機，即使淩晨3點發現了錯誤也要來fix it。