軟件質量之路（2）：日構建 軟件質量保證
關鍵字：日構建
軟件質量的重要性是不言而喻的，但是當所有人都意識到它的重要性的時候，卻很少有人能夠清晰的描述出如何才能夠提高軟件質量。軟件質量框架的目的就在于提出一個評價的原型，幫助我們分析一種方法和技術是否能夠提高軟件質量。本系列文章分日構建、測試驅動開發、建立核心框架、面向組件的大規模軟件架構來進行深入的分析。
日構建是一項非�；A的軟件開發實踐，遺憾的是，并沒有多少組織真正意識到它的好處。通過本章的討論，你可以知道日構建對軟件開發的意義，了解日構建的基本情況以及如何著手進行日構建。
什么是軟件開發的有效管理
在一個全國性的銀行中，是什么保證復雜的資金清算的正確性的呢?每天，各個地方的網點在結束營業之前，需要保證賬目、資金、票據的平衡;這些網點的數據不斷的匯集，在每一個匯集點上都要保證賬目余額的平衡，最終完成一個銀行的一天的結算。天天如此，就像是一部設計精巧的機器一樣運作不息。不僅銀行是這樣，任何一個企業都是如此。一個小雜貨鋪的老板，也知道每天算算賬，看看今天是賺是賠。這些行為已經成為了工作的一部分，甚至成為了一種習慣。
軟件開發也是一樣的，必須找到一種方法，來衡量每天的工作，保證每天的工作能夠有效的持續下去，最終把軟件開發的過程變成一種內在的過程。這種方法就稱為日構建或是持續集成。
為什么需要日構建
日構建和持續集成是類似的，對開放源碼熟悉的人應該都知道Nightly Build。而持續集成這個詞來自XP方法，它的頻率可以比日構建更高，可以做到幾分鐘就進行一次集成，故而由此得名。在本文中，我們只討論日構建，而要將日構建轉換為持續集成是非常容易的。事實上，并沒有規定持續集成必須是以分鐘為單位進行的，如果你愿意，以一周為單位進行持續集成也是可行的。這樣區分的目的是為了更好的使用日構建或是持續集成技術：至少以天為單位，頻率越高，效果則越好。
那么，什么是日構建呢?我們傳統開發軟件的流程一般是這樣，理解領域問題，然后分配任務，由不同的人負責不同的軟件部件，在開發完成之后，再把各人的部件整合起來，形成完整的軟件。這個思路看起來并沒有什么問題，但是在實踐中卻問題多多。
首先，這種方式適合開發人員之間工作彼此沒有交集的情況，以前這種現象很常見，但是現在，隨著軟件規模的擴大、分工合作的加深，開發人員間的相互依賴程度越來越高，這種清晰的職責劃分已經變得越來越難了。
其次，在軟件集成時，往往會出現各種各樣的問題，可是卻很難發現到底問題在哪里?公說公有理，婆說婆有理。每個人的代碼都沒有問題，結合到一起就出現大量的問題。
所以日構建就將平時難得一見的集成工作轉換成頻繁進行的一件工作，從而使得原先如同噩夢般的集成變成了一件簡單的工作。這也是很容易理解的，如果集成工作幾個月才進行一次，誰能夠記起幾個月前的細節呢?但是如果集成以天，甚至以分鐘為單位進行，排除bug就變成一件很容易的事情了。
日構建范例
現在的時間是下午的17:00，馬上就到日構建的時間了。團隊里四名程序員中的三位已經將自己的源代碼和測試代碼提交到了一臺名為宙斯的機器上，這臺機器將負責對代碼進行日構建。在他們提交代碼之前，已經通過了本機上的構建，并完成了測試。剩下的一位程序員似乎碰到了麻煩，他的代碼出現了一些問題，他現在需要編寫更多的測試來完善測試網�？磥頃r間來不及了，他只能夠在明天再做提交了。由于他的代碼沒有和其他人產生依賴，所以遲些提交也沒有關系，不過他在下個工作日的時候必須仔細的將最新的源代碼檢出到本地，在版本控制工具的幫助下，這項工作是很簡單的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/