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

說好的軟件質(zhì)量

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

成都創(chuàng)新互聯(lián)公司主要從事成都做網(wǎng)站、網(wǎng)站制作、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)鎮(zhèn)沅,十多年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18982081108

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

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

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

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

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

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

· 組織想降低成本與開發(fā)風(fēng)險(xiǎn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

系統(tǒng)反饋

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

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

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

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

 

當(dāng)前名稱：內(nèi)修敏捷開發(fā)心法+外煉持續(xù)整合招式
分享地址：http://muchs.cn/article34/pipjse.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、網(wǎng)站維護(hù)、靜態(tài)網(wǎng)站、全網(wǎng)營銷推廣、關(guān)鍵詞優(yōu)化、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)