內(nèi)修敏捷開發(fā)心法 + 外煉持續(xù)整合招式

說好的軟件質(zhì)量

提升軟件質(zhì)量是我們一直追求的理想，但軟件開發(fā)唯一不變的真理就是變，為了應(yīng)付變化多端的軟件開發(fā)過程，敏捷開發(fā)提倡了一種擁抱變化的軟件開發(fā)理念，少說也替軟件開發(fā)人員帶來了不少小確幸。

這些軟件開發(fā)模型與方法論，最終的目的在于軟件開發(fā)管理與質(zhì)量的提升，與其說質(zhì)量提升倒不如說是維持一定的水平。雖然敏捷開發(fā)有很多不同的方法論 (例如 Scrum, XP 等等)，但我們注意到這些方法論都一定會提到「持續(xù)整合 (Continuous Integration)」這個概念。持續(xù)整合到底是何方神圣？讓它在軟件工程中被如此受重視。換個方式來說，我常把敏捷開發(fā)比喻為武功心法，心法是虛的，代表方法論核心的理念，其招式才是起作用的媒介，然而持續(xù)整合便是敏捷開發(fā)實現(xiàn)的武功招式之一。

掌握軟件開發(fā)節(jié)奏

先不管敏什么捷開什么發(fā)了，先說說為什么要推薦各位「持續(xù)整合」這個招式。在軟件開發(fā)一定相當重視項目管理，因為軟件在建構(gòu)的過程中含有太多不確定的因素，項目永遠 Delay。經(jīng)常發(fā)生在產(chǎn)品開發(fā)后期，系統(tǒng)漸漸開始浮現(xiàn)各種 Bug 與不穩(wěn)定的征兆，越后期的版本提交期限 Delay 機會越高。持續(xù)整合就是為了避免這樣的情形發(fā)生，我認為持續(xù)整合最大的好處在于能夠「掌握軟件開發(fā)節(jié)奏」！

蛤？什么是軟件開發(fā)節(jié)奏？這其實表示著我們對軟件開發(fā)項目的掌握性，能夠確保軟件在承諾的時間下，交付出合乎規(guī)格與質(zhì)量要求的產(chǎn)品。在持續(xù)整合的過程中，我們會隨時將軟件當下的健康狀態(tài)透明化，這些狀態(tài)一旦透明化，問題就容易被顯現(xiàn)，問題進而容易被掌握與排除。而不是交付到客戶手上，才發(fā)現(xiàn)某個功能有問題。通常的軟件開發(fā)項目都有以下幾個愿望：

· 程序設(shè)計師想踏實地寫程序

· 項目經(jīng)理想確實地掌握時程

· 組織想降低成本與開發(fā)風險

· 客戶想拿到質(zhì)量優(yōu)良的產(chǎn)品

我們也希望藉由掌握軟件開發(fā)節(jié)奏讓這些愿望實現(xiàn)！

快避免由病轉(zhuǎn)疾

若是我們長期參與低劣的軟件開發(fā)過程，久而久之就容易失去信念，失去對軟件質(zhì)量的堅持，這對于組織與團隊的傷害相當大，但也因為不易根除，往往日久為患。工程師為了項目時程而加班，PM 為了時程犧牲品質(zhì)。程序設(shè)計師漸漸為了趕緊搞定眼前的難題，開始不踏實地建構(gòu)軟件，開始用一些奇怪的方法 (Dirty Hard Code) 解決系統(tǒng)自動產(chǎn)生的 Bug...。我想您應(yīng)該明白這些奇怪的方法指的是什么？時間一久，我們對軟件的感情就淡了，反正有了摩菲定理的加持，項目一定延遲，Bug 永遠改不完。我們面對軟件開發(fā)的復雜性，不知不覺已經(jīng)由病轉(zhuǎn)疾，病可以醫(yī)的好，疾就只能控制病情了。

那持續(xù)整合到底是什么？

假設(shè)我們能隨時掌握軟件的狀態(tài)，讓開發(fā)中軟件一切的狀態(tài)變得透明，那不是很好嗎？回到「持續(xù)整合」這個議題，簡單從字面上解釋「持續(xù)」就是「不間斷、不停地、一直、有事沒事就做一下」大概這樣的意思；那「整合」呢？在軟件開發(fā)中的整合不就是「把大家寫的 Code 在一起跑看看有沒有錯！」。以此類推「持續(xù)整合」四個字的意思就是「有事沒事就把大家寫的 Code 在一起跑看看有沒有錯！」，聽起來很簡單吧!?

我們先來講講持續(xù)整合的用意好了，我們常接觸的敏捷開發(fā) (Agile)，為了快速適應(yīng)變化，常常在很短的周期 (Scrum 大約兩周) 就會發(fā)布一個新版本，這件事在 XP (極限編程) 中稱為 Small Release。然而每一個版本發(fā)布重視的不是新增的多少功能？而是產(chǎn)生一個逐漸接近市場的產(chǎn)品。注意喔，每次發(fā)布的軟件都必須是可以被正確執(zhí)行的！在很多敏捷開發(fā)方法論都提到，可正確執(zhí)行的程序碼勝過一切，當然也勝過那些該死的文件。

問題來了，要如何在短時間驗證軟件是可以正常運作的呢？如果一開始功能少還可以花點時間手動測，到后期功能多就沒辦法了，更不用說除了測試新版本的功能，還要確保既有的功能能夠運作正常。這時候「持續(xù)整合」就是發(fā)揮效用的時候了?；氐絼倓偺岬降模骸赣惺聸]事就把大家寫的 Code 在一起跑看看有沒有錯！」這樣的事情對我們而言，其實就是自動地從版本控制系統(tǒng)拉 Code 進行建置與測試，一旦我們不停的在開發(fā)的過程中持續(xù)地進行這件事，當軟件發(fā)生不穩(wěn)定時就可以立即察覺，將能夠大幅降低整合測試的風險與時間，因為我們隨時隨地都在進行整合測試！

關(guān)于測試與自動化

上述提及的測試并非手動測試或半自動測試，而是全自動測試。在必須反覆且密集測試的過程中，我相信你不會想要手動測試的 (花錢找工讀生測也不是辦法)，而且只要是人做的都有機會錯！自動化測試會是比較好的方法。

在實際上，對于「撰寫測試」這件事，大概是整個持續(xù)整合過程中最難推動的，常因為我們的教育一開始就沒有讓新手程序設(shè)計師明白測試程序的重要性，日常的工作也都是在追求功能的實現(xiàn)，而不是功能正確無誤地實現(xiàn)，往往只重視在程序本身的執(zhí)行結(jié)果 (用眼睛看)。在敏捷開發(fā)中，也曾提到測試驅(qū)動開發(fā) (TDD, Test-driven development) 這樣的概念，但如果您開發(fā)的系統(tǒng)沒有經(jīng)驗老道的軟件架構(gòu)師，那么這個模式在實務(wù)推行上將更為困難，因為常發(fā)現(xiàn)根本沒辦法在既有的軟件架構(gòu)設(shè)計自動測試，要改就得大改，實行測試的信心與意念就被消滅了。

在實作測試的過程中，其實有些重新審核系統(tǒng)的味道，象是我們都可以發(fā)現(xiàn)更多軟件設(shè)計上的缺失，發(fā)現(xiàn)更多可以改進的設(shè)計，象是利用解耦合、物件抽象化、資料連結(jié)層 (Data Access Layer)、Mock Object、Dummy Data 等等技巧對架構(gòu)進行軟件重構(gòu)。實行測試還有另一種很棒的方法，就是實行「結(jié)對編程 (Pair Programming)」，但這跟測試有什么關(guān)系呢？我們先想想，在結(jié)對編程中常常一位寫程序另一位寫測試，這樣的過程迫使我們能夠設(shè)計出可被其他程序測試的程序碼，間接達到自動化測試。許多組織高層的觀念必須調(diào)整，有的老板很難理解為什么要兩個人做同一件事，但公司卻要付兩個人的薪水！

實行自動化測試困難重重，但這些都不是我們逃避的原因，其實一開始不用急著提高測試覆蓋率，先從基本的功能測試開始。大致上有兩個方向可以慢慢實現(xiàn)：

1. 先進行基本功能的正確性測試，至少保證功能可以被執(zhí)行（雖然不一定對）。

2. 當系統(tǒng)出現(xiàn) Bug 時，解 Bug 前撰寫復制錯誤的測試程序，接著才修正 Bug 確保未來同樣的 Bug 不會一再發(fā)生。

這兩點對于已經(jīng)開發(fā)中的系統(tǒng)特別有效，可以慢慢搭建起自動化測試的工作，有了開始就容易多了。我曾經(jīng)看過實際的例子，在一個開發(fā)已久的軟件后期才加入自動化測試，雖然覆蓋率不到 30%，但是管理者做了一個很有約束力的決策，就是整合版本控制系統(tǒng)，未來 Commit 的程序碼不能降低整個系統(tǒng)的覆蓋率。所以每次 Commit 后就會進行自動測試，約束未來加入的程序碼必須強制撰寫自動化測試，保證產(chǎn)品的質(zhì)量不會越來越糟。

測試的模式與種類繁多，試著找出適合自己產(chǎn)品的自動化測試手段即可，并沒有一定的標準答案。最后，盡管我們可以達到的測試覆蓋率有限，或者當下復雜的軟件架構(gòu)導致難以撰寫測試，但這些都不是借口，必須先開始才會有進步的空間。

系統(tǒng)反饋

前面提到，由于持續(xù)整合系統(tǒng)無時無刻都在進行系統(tǒng)整合與測試，當持續(xù)整合發(fā)現(xiàn)軟件不穩(wěn)定時（指的是建置或測試失?。?，就會發(fā)出警示給予開發(fā)者。這個行為我們稱為「Feedback 系統(tǒng)反饋」，系統(tǒng)反饋是持續(xù)整合系統(tǒng)中相當重要的一件事。當我們收到系統(tǒng)給予我們這樣的反饋時，應(yīng)當立即著手處理，而不是拖到接近產(chǎn)品釋出期限，才開始面對持續(xù)整合早就給予我們的警示，造成產(chǎn)品時程與質(zhì)量的憂慮。

最容易實現(xiàn)系統(tǒng)反饋的方法可以透過「每日建置」來完成，每日建置通常在晚上執(zhí)行 (或稱為 Nightly Build)，由于通常身心正常的程序設(shè)計師會在下班前提交比較穩(wěn)定的程序碼，在夜深人靜的時候進行整合測試是一個好方法。由于系統(tǒng)每天晚上會更新最新的程序碼進行建置，當遇到問題時就會發(fā)出「系統(tǒng)反饋」警示，通常是發(fā)出 Email 告知幾位相關(guān)衰人，好讓事主在隔天一早上班就可以著手處理問題，盡可能讓我們所建構(gòu)的軟件在軟件開發(fā)過程中，能夠隨時保持穩(wěn)定的狀態(tài)。若是在合理的測試覆蓋率下，甚至可以隨時發(fā)布開發(fā)中的系統(tǒng)，「快速適應(yīng)變化」這不就才是敏捷開發(fā)的精神嗎？

持續(xù)整合的精神：自動化 + 測試 + 系統(tǒng)反饋

由于每個軟件項目都不盡相同，軟件建構(gòu)流程并沒有絕對的標準答案，只有做適合團隊的對應(yīng)作法。實務(wù)上建置持續(xù)整合系統(tǒng)，確實要花上不少功夫撰寫 Script 建置腳本，特別在測試環(huán)境的自動化建置與執(zhí)行測試等等工作。雖然方法不同，但是所有的概念還是環(huán)繞在「自動化＋測試＋系統(tǒng)反饋」這三個精神上。我認為我們都需要一種義無返顧的勇氣，好讓我們持續(xù)在持續(xù)整合工作上投入心力，讓軟件變得更好！我相信我們都能打造出讓自己也能驕傲的軟件！