一洗显、前言

軟件交付過程是用代碼實現(xiàn)各用戶關(guān)注點的過程棱貌，也是架構(gòu)真正經(jīng)受第一輪實戰(zhàn)考驗的過程禀晓。軟件交付的結(jié)果可以檢驗架構(gòu)是否真正地如之前所設(shè)計的那樣能滿足各方面用戶的關(guān)注點精续。所以軟件交付過程是否理想很大程度決定了架構(gòu)設(shè)計的落地是否理想，也決定了系統(tǒng)滿足各用戶關(guān)注點的效果是否理想粹懒，那什么才是理想的軟件交付過程呢重付？

二、從國內(nèi)IT行業(yè)加班多說起

國內(nèi)IT行業(yè)歷來都是加班多的代名詞凫乖，那為什么國內(nèi)IT行業(yè)加班這么多呢确垫？先通過筆者身邊的一個真實的故事來說起：

筆者的朋友小N在國內(nèi)一家大的公司工作，這一年來他加班都特別多拣凹，每天平均在晚上十一點多才能下班森爽，有時候還需要連續(xù)搞幾個通宵，人看起來非常疲憊嚣镜。跟他聊了以后爬迟，了解了導(dǎo)致他加班的幾個主要原因（問題有點多，但確實是如此）：

原因1：上個上線的版本用戶在使用過程中存在比較多的問題菊匿，需要進行緊急的支撐和補丁升級付呕。

原因2：很多時候上面的領(lǐng)導(dǎo)需要給更上一級的領(lǐng)導(dǎo)演示，需要在版本的開發(fā)工作外額外再開發(fā)一個演示的版本跌捆。據(jù)他預(yù)計可能50%左右的版本外的工作都是給領(lǐng)導(dǎo)做演示版本徽职。

原因3：公司層面要求內(nèi)部所有的系統(tǒng)云化，所以一段時間都在搞現(xiàn)有系統(tǒng)的微服務(wù)化以及對于DevOps的支持佩厚。領(lǐng)導(dǎo)對這個完成的時間點又卡的很緊姆钉，認為只是把之前的功能微服務(wù)化而已，又不需要做業(yè)務(wù)的變更抄瓦，導(dǎo)致那段時間加班巨多潮瓶。

原因4：雖然在生產(chǎn)環(huán)境和測試的測試環(huán)境中搞了部署的自動化，但是很多開發(fā)人員還是使用很少量的環(huán)境進行功能的驗證和問題單的回歸驗證钙姊，在過程中可能會發(fā)生文件替換沖突等問題毯辅，導(dǎo)致大量的時間花費在部署問題的定位上。

原因5：有的領(lǐng)導(dǎo)要求每周一個小版本煞额，每一個月一個大版本思恐，但是軟件交付過程中的自動化程度又不足以支撐這樣一個目標沾谜，導(dǎo)致測試每次基本上都要去做全量測試，測試加班也非常嚴重胀莹。

原因6：現(xiàn)有系統(tǒng)使用的技術(shù)都比較老舊基跑，基本上還停留在六七年前的時代，特別是對于前臺界面還是jsp+div+css+jquery的技術(shù)棧嗜逻，導(dǎo)致前臺代碼越來越臃腫涩僻，加之對前臺代碼的重視程度不夠，代碼越來越腐爛栈顷，功能的增加和修改都極其痛苦。

......

我相信上面的問題在國內(nèi)很多的公司都存在嵌巷，這可能也是國內(nèi)目前很多公司IT人員加班多的原因的一部分萄凤。下圖是高德公司2016年發(fā)布的年度加班多的公司TOP10：

上面這些問題都是軟件交付過程中出現(xiàn)的問題，那軟件交付過程應(yīng)該怎么做才是比較理想的呢搪哪？要回答這個問題靡努，我們先來看一下軟件交付過程包括哪些步驟。

三晓折、軟件的交付過程包括哪些步驟惑朦？

下面是筆者認為的軟件交付過程所涵蓋的步驟：

下面就對各個步驟做一個簡單的描述：

（1）版本開發(fā)：這個過程主要是開發(fā)人員把代碼編寫完，并把自驗后的代碼提交到代碼庫中漓概。

（2）版本構(gòu)建：當代碼都提交完后漾月，需要進行版本的構(gòu)建，目的是要構(gòu)建出版本的軟件安裝包胃珍，當然也包括執(zhí)行一些代碼質(zhì)量檢查梁肿、自動化測試等。

（3）版本部署：當版本安裝包構(gòu)建完后觅彰，就可以在測試環(huán)境進行版本的部署吩蔑。

（4）版本測試：部署完后，就可以進行進一步的自動化測試填抬，也就是系統(tǒng)集成測試烛芬。測試人員可以選擇幾個關(guān)鍵功能進行人工測試覆蓋。

（5）版本發(fā)布：當測試沒有問題飒责，就可以把版本發(fā)布出去赘娄，發(fā)布出去的版本就可以部署到生產(chǎn)環(huán)境了。

四读拆、軟件交付過程中加班多的問題分析

從分析的結(jié)果來看擅憔，軟件交付過程加班多主要是以下三大原因：

（1）軟件交付過程中自動化程度不夠，人工參與過多檐晕，導(dǎo)致交付效率不高暑诸。

（2）軟件交付過程中領(lǐng)導(dǎo)的干涉太多蚌讼，安排額外的工作以及不切實際的規(guī)定完成時間點。

（3）使用的技術(shù)已經(jīng)不適用个榕，導(dǎo)致可擴展性和可維護性難篡石，開發(fā)效率低。

第二個問題是領(lǐng)導(dǎo)的管理方式問題西采，第三個問題是技術(shù)選型的問題凰萨，在本文中不做展開。

下面主要針對第一個問題闡述以下筆者認為的理想的軟件交付過程到底是什么樣子的械馆。

五胖眷、傳統(tǒng)的軟件交付過程

為了說明怎么解決第一個問題，下面讓我們總結(jié)一下目前軟件交付過程中的傳統(tǒng)做法（按照敏捷中的概念進行說明）：

（1）開發(fā)人員接到story開發(fā)任務(wù)后霹崎，進行story的分析和設(shè)計珊搀，并和測試人員一起溝通澄清該story的具體細節(jié)刃榨，包括story的范圍糕档、規(guī)格等。

（2）澄清完后咆槽，開發(fā)人員進入編碼階段劳淆，測試人員進行story的測試用例設(shè)計輸出（一般都通過文字描述的方式）以及測試環(huán)境的搭建，待story的測試用例設(shè)計完后默赂，開發(fā)人員和測試人員再進行測試用例的澄清沛鸵，至此對于該story的交付內(nèi)容和規(guī)格，開發(fā)和測試人員達成了一致放可。

（3）開發(fā)人員編碼完成后谒臼，構(gòu)建軟件安裝包，部署到開發(fā)人員測試環(huán)境中耀里，并根據(jù)測試用例進行人工驗證蜈缤，如果驗證都通過，則把此軟件安裝包作為該story的轉(zhuǎn)測試包冯挎。

（4）開發(fā)人員的story轉(zhuǎn)測試后底哥，測試人員把提供的軟件安裝包部署到測試人員測試環(huán)境中進行驗證，如果出現(xiàn)安裝無法進行或者story基本功能不可用的情況房官，則進行story轉(zhuǎn)測試的打回趾徽，要求開發(fā)人員重新進行該story的驗證和轉(zhuǎn)測試。如果安裝成功并且story基本功能可用翰守，則測試人員根據(jù)測試用例以及一些發(fā)散測試來驗證story孵奶，發(fā)現(xiàn)問題則用提問題單的形式來要求開發(fā)進行修改。

（5）開發(fā)人員接到問題單后蜡峰，進行修改了袁，并且進行問題單的驗證以及走給測試進行回歸朗恳。

（6）測試人員進行問題單的回歸，如果問題單已經(jīng)修改好载绿，則關(guān)閉問題單粥诫，如果沒有，則打回重新修改崭庸。

（7）全部story測試完成之后進入系統(tǒng)集成迭代測試階段怀浆，測試人員會根據(jù)測試用例以及一些發(fā)散的測試來驗證系統(tǒng)的功能（這個階段可能大部分測試用例可以用自動化的方式來跑了）。這個過程往往會重復(fù)好幾次怕享，因為每一次幾乎都會有新的問題單提出执赡，而這些新提的問題單只能等到下一個系統(tǒng)集成迭代測試階段進行回歸驗證。

（8）如果問題單修改的質(zhì)量高（都修改好了并且沒有引入其它的問題）或者“運氣好”（測試人員沒有發(fā)現(xiàn)存在的問題）函筋，那最后一輪系統(tǒng)集成迭代測試會以無遺留問題的方式通過搀玖。如果運氣不好，有新問題出現(xiàn)驻呐，則需要看問題的影響，如果問題影響不大芳来，則通過“灰度”的方式進行發(fā)布含末。如果問題影響大，則可能臨時還得出一個轉(zhuǎn)測試的盤來解決該問題即舌。

......

至此整個傳統(tǒng)的軟件交付的過程結(jié)束了佣盒。從上述過程中存在以下明顯的問題：

（1）測試人員需要用文字的方式來輸出測試用例。文字方式的測試用例價值很低顽聂，因為只有人才能看到肥惭，根本沒法自動化。況且人要根據(jù)文字描述來測試需要有一個很重要但是基本上很難做到的前提：測試用例要描述的精確紊搪、沒有歧義蜜葱，并且還要保證看的人在看的時候不會出錯。

（2）開發(fā)人員需要對測試用例進行測試耀石，測試人員也需要對測試用例進行測試牵囤，造成了明顯的工作量浪費。

（3）開發(fā)和測試的測試環(huán)境基本上都是靠人來搭建滞伟，需要抽調(diào)專人來負責揭鳞。

（4）開發(fā)需要對問題單進行驗證，測試也需要對問題單進行回歸驗證梆奈，造成了工作量的浪費野崇。

（5）整個過程中開發(fā)和測試的心理壓力會非常大，因為組織對于story交付進度延遲亩钟、story測試打回乓梨、問題單回歸不通過鳖轰、問題單的修改引入以及發(fā)布后出現(xiàn)問題等有嚴厲的懲罰措施，但是每個人對于這些問題的出現(xiàn)又沒有一個有效的防范手段督禽，所以幾乎可以肯定每一次軟件交付過程中都會出現(xiàn)上述的問題脆霎，當這些問題出現(xiàn)的時候很大程度都會影響整個版本的交付計劃。

六狈惫、理想的軟件交付過程

理想的軟件交付過程筆者認為總結(jié)起來就一句話：關(guān)注長遠價值睛蛛，更少的人工參與，更高的效率胧谈。

關(guān)注長遠價值就是不要為了應(yīng)付某個版本的快速交付而對系統(tǒng)的可維護性忆肾、擴展性等方面帶來負債，現(xiàn)在欠的債未來總是要還的菱肖，而且只會還的更多而不是更少或相等客冈。心理學(xué)上有一個著名的破窗效應(yīng)，也就是說如果某個開發(fā)人員發(fā)現(xiàn)系統(tǒng)中某塊代碼為了應(yīng)付進度等寫的很爛稳强，后面這個開發(fā)人員也很有可能為了其它的短期利益也寫出爛的代碼场仲，久而久之這個系統(tǒng)就沒有辦法維護了。

人的穩(wěn)定性很差退疫，總是處于不斷地波動中渠缕，心理學(xué)里有一個回歸均值理論，就是說人的表現(xiàn)好和表現(xiàn)差是交替出現(xiàn)的褒繁，中國也有盛極必衰亦鳞，否極泰來的說法，說明事物總是在曲折中前進的棒坏。如果人工對于軟件交付過程參與的太多燕差，只能祈禱這個參與的人最近的狀態(tài)比較好，不會出現(xiàn)很大的問題坝冕。

在軟件交付過程中徒探，如果我們發(fā)現(xiàn)某個地方需要人參與的太多，并且出錯的幾率也比較大徽诲，那這個時候得重新思考下目前這種操作方式是否合理刹帕？是否能讓機器代替人自動化地來完成這些事情？

那理想的軟件交付的做法應(yīng)該是什么樣呢谎替？

理想的軟件交付過程應(yīng)該是流式的偷溺，像管道中的流水一樣，即從代碼的檢入到最后軟件包的ready都是自動進行的钱贯，中間如果某一步出現(xiàn)了問題挫掏，則會及時反饋詳細信息給對應(yīng)的人員進行處理。

（1）當開發(fā)人員完成story的編碼后提交代碼秩命，一系列的自動化測試就會運行尉共，這些測試將會測試這個系統(tǒng)的基本功能褒傅。如果發(fā)現(xiàn)哪里有問題，則會馬上把問題的詳細信息包括日志等反饋給開發(fā)袄友，開發(fā)立即就可以根據(jù)這些信息進行修改殿托。

（2）基本功能測試通過后，則會自動開始構(gòu)建軟件安裝包以及自動搭建測試環(huán)境剧蚣，并把軟件自動部署到搭建的測試環(huán)境里支竹。

（3）更進一步的系統(tǒng)集成測試會自動運行，這些測試會更加基于最終使用用戶的立場來進行鸠按。這些測試通過后就說明版本可以發(fā)布了礼搁。

（4）全部的測試都完成后，會自動構(gòu)建軟件包目尖，并在構(gòu)建完成之后放到指定待發(fā)布的目錄下馒吴。

上面就是筆者認為的理想的軟件交付過程。在這個過程中所有人員的角色分工有點模糊了瑟曲，開發(fā)人員饮戳、測試人員以及軟件構(gòu)建人員等都是為了一個統(tǒng)一的目標：怎么在保證軟件交付質(zhì)量的前提下讓整個軟件交付過程實現(xiàn)完全自動化。

要實現(xiàn)完全自動化洞拨，筆者認為需要做到以下幾件事：測試用例即代碼莹捡、構(gòu)建即代碼、部署即代碼扣甲、軟件發(fā)布即代碼以及怎么把這幾個部分串聯(lián)起來，使得整個軟件交付過程是流式的齿椅。當然這里有很多的技術(shù)細節(jié)需要再深入下琉挖，也請關(guān)注筆者后面的文章，會嘗試對這幾方面做一些思考涣脚。