軟件質量之路——日構建

軟件質量的重要性是不言而喻的，但是當所有人都意識到它的重要性的時候，卻很少有人能夠清晰的描述出如何才能夠提高軟件質量。軟件質量框架的目的就在于提出一個評價的原型，幫助我們分析一種方法和技術是否能夠提高軟件質量。本系列文章分日構建、測試驅動開發、建立核心框架、面向組件的大規模軟件架構來進行深入的分析。

日構建是一項非�；�礎的軟件開發實踐，遺憾的是，并沒有多少組織真正意識到它的好處。通過本章的討論，你可以知道日構建對軟件開發的意義，了解日構建的基本情況以及如何著手進行日構建。

什么是軟件開發的有效管理

在一個全國性的銀行中，是什么保證復雜的資金清算的正確性的呢？每天，各個地方的網點在結束營業之前，需要保證賬目、資金、票據的平衡；這些網點的數據不斷的匯集，在每一個匯集點上都要保證賬目余額的平衡，最終完成一個銀行的一天的結算。天天如此，就像是一部設計精巧的機器一樣運作不息。不僅銀行是這樣，任何一個企業都是如此。一個小雜貨鋪的老板，也知道每天算算賬，看看今天是賺是賠。這些行為已經成為了工作的一部分，甚至成為了一種習慣。

軟件開發也是一樣的，必須找到一種方法，來衡量每天的工作，保證每天的工作能夠有效的持續下去，最終把軟件開發的過程變成一種內在的過程。這種方法就稱為日構建或是持續集成。

為什么需要日構建

日構建和持續集成是類似的，對開放源碼熟悉的人應該都知道Nightly Build。而持續集成這個詞來自XP方法，它的頻率可以比日構建更高，可以做到幾分鐘就進行一次集成，故而由此得名。在本文中，我們只討論日構建，而要將日構建轉換為持續集成是非常容易的。事實上，并沒有規定持續集成必須是以分鐘為單位進行的，如果你愿意，以一周為單位進行持續集成也是可行的。這樣區分的目的是為了更好的使用日構建或是持續集成技術：至少以天為單位，頻率越高，效果則越好。

那么，什么是日構建呢？我們傳統開發軟件的流程一般是這樣，理解領域問題，然后分配任務，由不同的人負責不同的軟件部件，在開發完成之后，再把各人的部件整合起來，形成完整的軟件。這個思路看起來并沒有什么問題，但是在實踐中卻問題多多。

首先，這種方式適合開發人員之間工作彼此沒有交集的情況，以前這種現象很常見，但是現在，隨著軟件規模的擴大、分工合作的加深，開發人員間的相互依賴程度越來越高，這種清晰的職責劃分已經變得越來越難了。

其次，在軟件集成時，往往會出現各種各樣的問題，可是卻很難發現到底問題在哪里？公說公有理，婆說婆有理。每個人的代碼都沒有問題，結合到一起就出現大量的問題。

所以日構建就將平時難得一見的集成工作轉換成頻繁進行的一件工作，從而使得原先如同噩夢般的集成變成了一件簡單的工作。這也是很容易理解的，如果集成工作幾個月才進行一次，誰能夠記起幾個月前的細節呢？但是如果集成以天，甚至以分鐘為單位進行，排除bug就變成一件很容易的事情了。

日構建范例

現在的時間是下午的17:00，馬上就到日構建的時間了。團隊里四名程序員中的三位已經將自己的源代碼和測試代碼提交到了一臺名為宙斯的機器上，這臺機器將負責對代碼進行日構建。在他們提交代碼之前，已經通過了本機上的構建，并完成了測試。剩下的一位程序員似乎碰到了麻煩，他的代碼出現了一些問題，他現在需要編寫更多的測試來完善測試網�？磥頃r間來不及了，他只能夠在明天再做提交了。由于他的代碼沒有和其他人產生依賴，所以遲些提交也沒有關系，不過他在下個工作日的時候必須仔細的將最新的源代碼檢出到本地，在版本控制工具的幫助下，這項工作是很簡單的。

17:10，宙斯終于開始了構建的過程。他從代碼源中檢出最新代碼，然后開始編譯，構建，并執行了所有的測試，從控制臺界面上，日構建的負責人（其中的一位程序員）似乎看到了有部分的測試沒有通過，他對剩下的人說，似乎有麻煩了。測試完成之后，將會從代碼中生成所有的API文檔，并進行代碼分析和測試覆蓋率分析，最新測試報告和各種其它的報告都將會發布到Web上。

最后。完成構建的軟件和相關的資料已經成功的發布了，時鐘指向17:18。"現在只是項目的早期，到了中后期，至少還需要20分鐘的時間"，老鳥程序員告訴沒有經驗的程序員，并讓大家去看看測試結果。一個程序員邊嘟囔，邊看log日志，"我在本機都已經測試過了呀，怎么會有錯呢。"檢查結果發現是環境問題，配置文件被人改動了�？磥�，集成過程中仍然少不了沖突的問題，只不過，這些問題可以被很快的發現，并很快的得以解決。

以上是一個典型的日構建過程，日構建的過程是完全自動化的，通過預先定義好的指令，機器將按照指令順序執行完所有的構建步驟。日構建中涉及的步驟是可選的。

日構建的價值

可能有些人認為日構建過于浪費時間，但是實際上，比起最后除錯的成本來說，日構建成本是微不足道的。當然，在企業中建立日構建制度確實需要花費不少的時間，但從長遠來看，這絕對是值得的。

從表面上看，日構建能夠減少最終的排錯成本，但這僅僅是日構建最基本的價值。實際上，日構建更為關鍵的作用是能夠引入日構建的制度。這是什么意思呢？日構建的思路將會為軟件企業的開發流程帶來變化：開發人員將會在日構建的制度下更加頻繁的協作，開發進度一目了然，軟件的質量也會更加的穩定。

軟件開發本身就是一項強調溝通和協作的活動。但是在日常的活動中，常常出現阻礙溝通的情況，例如需要溝通的雙方不在同一個地理位置、噪聲、溝通雙方的意愿等等。因此在軟件管理中需要提供一種方法，來鼓勵人們進行溝通。日構建就是其中的一種方法（但它并不是唯一的方法）。每一次的構建將會涉及到團隊中的所有成員，因此溝通是少不了的，在日構建實踐的驅動下，每位開發人員都朝著最終的目的－"成功的構建"努力。

在Alistair Cockburn的敏捷軟件開發的第三章中，詳細的闡述了團隊溝通和協作中的相關問題。例如溝通的實質，影響溝通的各種因素，以及如何克服他們。最后，他還論述了如何促進團隊的溝通，來打造一支成功的團隊。

在日構建的驅動下，項目的進度將會變得非常的明顯。每一天的構建結果將會通過某個渠道發布出來，團隊和團隊的老板可以看到軟件現在的樣子，項目的完成情況，出現的問題等等。這些信息構成了軟件開發的基本信息。不但可以清晰地描述出項目進度，也為管理人員安排計劃提供了基礎數據的支持。有了基本的量化數據，軟件開發才不是靠拍腦袋出成果的。

日構建的最后一個價值是提供了整合性。目前軟件開發中并沒有一種統一的管理軟件，未來似乎也很難做到，因為不同的軟件組織差異很大。在開發過程中，一些有價值的實踐被加入、集成到日構建的過程中，在日構建的推動下，這些優秀實踐很容易成為開發過程的一部分。在文章倡導的另一個優秀實踐－測試驅動開發實踐，就很容易集成到日構建中來。事實上，軟件測試是非常重要的，它已經成為日構建成功的判別因素。

選擇日構建還是持續集成

雖然日構建和持續集成的本質是相同的，但是他們在集成的頻率方面的差異也導致了一些管理上的差異：

首先，日構建樹立了一個明確的以工作日為單位的小目標，團隊的目的就是為了使代碼能夠通過每天的構建。開發人員在明確的目標的指導下，往往能夠發揮出很高的效率。持續集成則將這個頻率變得更小，只要你的代碼提交到代碼庫中，立刻就會檢驗你的成果，如果有問題，你必須立刻排除，否則，要么集成的過程無法繼續，要么出錯的開發人員的信箱被集成過程中的警告信息所填滿。這種做法對團隊的要求要更高一些。對于剛剛開始接觸日構建的團隊來說，可能會手忙腳亂。

其次，日構建有一條非常明確的分界線，開發工作要么是完成，要么是沒有完成，不存在第三種狀態。

日構建的基礎實踐

日構建的基礎包括三個實踐：自動構建、統一代碼源和集成測試。

自動構建

自動構建的思路是通過腳本語言，而不是通過在IDE環境中點擊構建按鈕來完成項目的構建過程。日構建需要不斷的進行集成的工作，如果手工來完成這項工作，既費時，效果又不好。所以更聰明的做法是把這件工作給自動化。在早期的Unix環境中，都是采用Make編寫相應的腳本來完成構建的過程。隨著先進的IDE環境的發展，慢慢的人們就不愿意再編寫Make腳本了�？墒乾F在，為了自動構建的目標，我們需要回歸到手工編寫Make腳本的歷史上去。應該說，IDE環境中的構建方式側重于個人開發，而自動構建則側重于團隊開發

自動構建目標就是通過一個簡單的命令就能夠全部的構建過程。

統一代碼源

其次，保證一個開發團隊共享統一的代碼源。這時候我們需要使用版本控制工具。共享的代碼庫同樣也是XP的一個基本實踐。雖然XP還要求開發人員可以修改他人的代碼，但我們并不提倡這種做法，這要求團隊成員之間有非常高的默契程度。統一的代碼源能夠保證所有人的代碼都歸總到一起，這是日構建的基礎。如果沒有這一點的保證，每一次的構建我們都不得不把所有人的代碼集中起來，這無疑會使構建過程變成災難。

統一代碼源能夠保證任何一位團隊成員獲得所有的代碼，并以此為基礎進行開發。

集成測試

只是把代碼編譯通過并不能夠證明軟件可以正常工作，評價軟件的標準應該是測試。在日構建中必須要執行集成測試，來保證軟件確實是能夠工作的。

集成測試也是一個同義詞相當多的名詞，有人把它稱為驗證測試（BVT－Build Verification Tests），因為他們認為這種測試主要的目的是為了驗證構建的正確性。有些人把它稱為冒煙測試（Smoke Test），因為他們覺得這個測試的目的是運行軟件，看它是否會"冒煙"。

測試應該全部執行完畢，而不是遇到未被滿足的錯誤就放棄測試過程。測試將形成結果，成功的測試，失敗的測試，失敗測試的細節。最后的結果將通過某種方式通知給相應的人員，要求他們修改設計或測試（如果是測試本身的問題的話）。

集成測試是證明構建成功的關鍵因素。和構建一樣，集成測試也應該是自動化的。

日構建的基本工具

日構建的工具有很多，但是最基礎、最廣泛的工具是Ant（http://ant.apache.org）。Ant類似于Make，但是加入了跨平臺的特性。在這個目標的驅動下，Ant摒棄了Make工具的給予Shell的缺點，提供了一種使用XML配置文件的構建方式，并定義了一個統一的微核心和強大的擴展機制。這些特點使得Ant很快被人所接受、推廣。目前，Ant的最新版本是1.6.0。


<project name="MyProject" default="dist" basedir=".">
<description>
simple example build file
</description>
<!-- set global properties for this build -->
<property name="src" location="src"/>
<property name="build" location="build"/>
<property name="dist" location="dist"/>

<target name="init">
<!-- Create the time stamp -->
<tstamp/>
<!-- Create the build directory structure used by compile -->
<mkdir dir="${build}"/>
</target>

<target name="compile" depends="init"
description="compile the source " >
<!-- Compile the java code from ${src} into ${build} -->
<javac srcdir="${src}" destdir="${build}"/>
</target>

<target name="dist" depends="compile"
description="generate the distribution" >
<!-- Create the distribution directory -->
<mkdir dir="${dist}/lib"/>
<!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
<jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
</target>

<target name="clean" description="clean up" >
<!-- Delete the ${build} and ${dist} directory trees -->
<delete dir="${build}"/>
<delete dir="${dist}"/>
</target>
</project>



以上是一個簡單，但已經可以完全說明Ant工作流程的例子，來源于Ant的手冊。在這個例子中，先定義了項目的基本信息和構建過程中所需要使用到的屬性（1），然后初始化環境（2）（創建時戳和目標目錄），在3和4中，對項目進行編譯和打包，在5處，提供了清除項目輸出的途徑。

在Ant中，最關鍵的四個概念就是項目（Project）、目標（Target）、任務（Task）和屬性（Property）。這四個概念的定義和調度、配置文件的處理構成了Ant的核心。而具體的任務則作為擴展機制。這種微核心的處理思路在很多成功的軟件項目中采用過。

本文并沒有打算對Ant進行全面的介紹，因此，如果你打算在組織中引入日構建，那么，學會使用Ant是必須的。目前很多的IDE環境都提供了對Ant的支持（例如Eclipse），所以使用Ant是很方便的。

原則上，光有Ant就已經可以完成一個日構建過程了，但是還有一些軟件提供了更好的封裝，使得持續集成變得更加的簡單。典型的兩個工具是AntHill（http://www.urbancode.com/projects/anthill/default.jsp）和CruiseControl（http://cruisecontrol.sourceforge.net/）。前者是一個商業軟件，提供了很多優秀的日構建實踐。使用起來也很簡單。后者是鼎鼎大名的Martin Folwer所在的ThoughtWorks公司開發的，可以免費使用。

另一個值得關注的軟件是Apcache組織下的Maven項目（http://maven.apache.org/）。這個項目還很年輕，目前才到1.0的發布版。Maven給自己的定位是項目管理軟件，使用項目對象模型（POM）來描述一個項目，進一步的簡化構建過程，并統一構建過程所出產的工件。Maven的另一個目標是通過一種實際的工具，來推廣優秀的實踐。例如開發目錄樹的組織。

日構建的代價

雖然日構建有諸多的好處，但是要使用日構建并不是一帆風順的。最大的問題是如何引入日構建的三項基本實踐。前兩項相對簡單，最難的是建立自動化測試。關于這部分的說明請參考測試驅動開發的相關部分。

日構建擴展任務

日構建的核心任務是編譯、構建、執行測試和發布。除了這些任務之外，還可以微日構建添加擴展任務。

生成文檔。生成文檔有很多的方法，其中最關鍵的是生成API文檔。JavaDoc的概念減弱了傳統軟件開發中文檔的重要性，而把大量的文檔嵌入到了代碼層面中。除了標準的JavaDoc文檔之外，還可以利用第三方的工具生成自定義的文檔，例如to-do列表文檔。XDoclet就是其中的一個工具。

預編譯。不少的應用引入了預編譯。典型的如AspectJ，作為一個AOP工具，AspectJ的作用是使用特定的代碼生成器生成AOP的Java代碼，然后再進行編譯。將預編譯的工作納入到構建過程，可以簡化開發的工作量。典型的還包括一些ORM工具。

代碼分析。代碼分析是軟件度量的重要工作。代碼分析可以為管理人員提供一個判斷代碼質量依據（不要把它作為唯一的標準）。代碼分析是形式化的，因此可以制作成軟件，集成到構建過程中來。例如，判斷代碼是否符合編碼規范，文檔和代碼的比率，包和類涉及的合理性。

測試覆蓋分析。測試覆蓋分析作為輔助測試的手段是非常重要的。測試代碼的復審，最關鍵的評價測試是否足夠（相對），單靠人工完成這項工作太勉強了。所以應該令其自動化，并成為構建過程的一部分。

問題跟蹤。測試過程中出現的問題應該被納入到一個問題跟蹤系統中，可以通過和問題跟蹤系統接口來設計自動化的任務。

歸檔和備份。這是很基本，但也是很重要的功能。每天產生的工件應當進行妥當的歸檔、備份。

進一步了解

試圖在短短的一篇文章中完整介紹日構建技術是很難的，從DW的網站上，你可以找到更多管理日構建工具的相關內容。

文章來源于領測軟件測試網 http://www.kjueaiud.com/