（浙江工商大學(xué)信息學(xué)院，杭州 310018）

摘 要：平臺技術(shù)是為了大規(guī)模提高軟件的開發(fā)效率和更好的進(jìn)行開發(fā)過程控制的基礎(chǔ)技術(shù)，它就好比傳統(tǒng)行業(yè)中的流水線。一般說來，流水線上有三個重要組成部分：技術(shù)框架、自動化設(shè)備、手工工具。按照產(chǎn)品生產(chǎn)的物理順序，把重型自動化設(shè)備和輕型的手工工具架設(shè)起來，就是技術(shù)框架。在流水線上，人和重型設(shè)備分工合作，那些機械的重復(fù)的，消耗體力比較大的工作交給重型設(shè)備處理，而機動靈活的、消耗體力較小的工作分給各個環(huán)節(jié)的技術(shù)工人。在生產(chǎn)過程中，零部件會從生產(chǎn)線的不同的入口進(jìn)入，在機器和人的共同努力下，向同一個出口不斷進(jìn)行各種組合，最終形成合格的產(chǎn)品。本文嘗試按照傳統(tǒng)工業(yè)流程的特色設(shè)計一套適合軟件設(shè)計和制造過程的技術(shù)平臺。當(dāng)然，技術(shù)架構(gòu)和技術(shù)管理是不可分割的，在這里也對管理問題提出一些建議。

關(guān)鍵詞：軟件技術(shù)；技術(shù)框架；生產(chǎn)線；開發(fā)過程；技術(shù)架構(gòu)

中圖分類號：TP31 文獻(xiàn)標(biāo)識碼：A 文章編號：1007-9599 （2013） 09-0000-03

由于軟件技術(shù)的發(fā)展，技術(shù)框架和開發(fā)平臺的概念已經(jīng)為人所熟悉，毫無疑問，平臺技術(shù)是為了大規(guī)模提高軟件的開發(fā)效率和更好的進(jìn)行開發(fā)過程控制的基礎(chǔ)技術(shù)。技術(shù)平臺好比傳統(tǒng)行業(yè)中的流水線，在流水線中，體現(xiàn)了產(chǎn)品的裝配和制造的邏輯，也決定了技術(shù)工人的分工方式以及對生產(chǎn)過程管理的基本方法。

1 傳統(tǒng)技術(shù)背景

一般說來，流水線上有三個重要組成部分：技術(shù)框架、自動化設(shè)備、手工工具。按照產(chǎn)品生產(chǎn)的物理順序，把重型自動化設(shè)備和輕型的手工工具架設(shè)起來，就是技術(shù)框架。在流水線上，人和重型設(shè)備分工合作，那些機械的重復(fù)的，消耗體力比較大的工作交給重型設(shè)備處理，而機動靈活的、消耗體力較小的工作分給各個環(huán)節(jié)的技術(shù)工人。在生產(chǎn)過程中，零部件會從生產(chǎn)線的不同的入口進(jìn)入，在機器和人的共同努力下，向同一個出口不斷進(jìn)行各種組合，最終形成合格的產(chǎn)品。

從上述分析，我們不難看出，傳統(tǒng)的生產(chǎn)線有幾個特點：

1.1 生產(chǎn)的源動力：在流水線上，生產(chǎn)過程是由重型設(shè)備的生產(chǎn)效率驅(qū)動的。因為機械的生產(chǎn)效率高于人，而且機械不知疲倦，會按照一個預(yù)設(shè)的速度，不斷的組織零部件，推動下一個環(huán)節(jié)的進(jìn)行。這個生產(chǎn)過程不是由測試和缺陷檢查驅(qū)動的。因為，第一、在分工合理的條件下，次品的生產(chǎn)率是比較低的；第二、人不如機器可靠，我們無法保證測試檢測環(huán)節(jié)的工作人員不會因為某種原因消極怠工。

1.2 分工合理、職能簡單：在生產(chǎn)過程中，無論是機器還是人，他所負(fù)責(zé)的工作都是適合它的特點的單一職責(zé)的工作，這樣做有三個好處，一是可以發(fā)揮各自的優(yōu)勢；二是職責(zé)單一，可以保證這一工作不需要技術(shù)工人掌握太多東西，上手很快；三是可以在不斷操作中不斷熟悉，從而提高自己的工作效率。

1.3 流程清晰、管理透明：生產(chǎn)的流程是嚴(yán)格按照產(chǎn)品的裝配順序展開的，流程清晰不僅表現(xiàn)在技術(shù)上，也表現(xiàn)在實際過程中，在生產(chǎn)線上，無論哪一個環(huán)節(jié)出了問題，該環(huán)節(jié)的操作平臺上立刻會出現(xiàn)大量的半成品堆積，這一現(xiàn)象無論是管理人員還是普通員工大家都會看得到，也正因為如此，所有的技術(shù)工人才不得不嚴(yán)格要求自己，避免出現(xiàn)積壓。

1.4 缺陷檢測準(zhǔn)確、處理及時：在生產(chǎn)過程中，無論是機器還是人都難免出現(xiàn)問題，但問題出現(xiàn)后，下一個生產(chǎn)環(huán)節(jié)馬上會發(fā)現(xiàn)，并及時反饋給上一環(huán)節(jié)，不會等到產(chǎn)品生產(chǎn)出來后再最后檢測。

應(yīng)該說，在傳統(tǒng)的生產(chǎn)線中，人和機器的配合是很默契的，當(dāng)然，這也是因為我們在傳統(tǒng)的生產(chǎn)制造行業(yè)已經(jīng)積累了太多的經(jīng)驗。但通過上述分析，我們也不難看出，生產(chǎn)過程的順暢是有其客觀原因的。

本文嘗試按照傳統(tǒng)工業(yè)流程的特色設(shè)計一套適合軟件設(shè)計和制造過程的技術(shù)平臺。當(dāng)然，技術(shù)架構(gòu)和技術(shù)管理是不可分割的，在這里也會對管理問題提出一些建議。

2 技術(shù)問題分析

在軟件開發(fā)過程中，普遍存在著大量的技術(shù)問題和管理問題，同傳統(tǒng)的生產(chǎn)線對比，不難發(fā)現(xiàn)問題主要包括以下幾個方面：

2.1 動力不足：一個大型的軟件項目接下來后，分配到每個開發(fā)人員手中，開始的時候，大家都積極的應(yīng)對各種問題，彼此之間也會展開討論，可是后來隨著問題的深入，討論開始不能進(jìn)行下去，開發(fā)過程也受到影響，開發(fā)人員自己普遍失去動力，開始消極怠工。此時，作為管理人員就只能通過對測試人員增加壓力，指出軟件中存在的問題，通過問題列表的多少來擠壓開發(fā)人員。顯然，由于沒有一個機械固定的運轉(zhuǎn)模式，這種對測試人員采取高壓的處理方式明顯顯得動力不足。

2.2 職責(zé)不清：在軟件設(shè)計過程中，沒有百分之百正確的設(shè)計方法。很多功能點無論放在什么位置都可以實現(xiàn)，很多缺陷也是不是說只有一種辦法解決。在這樣的前提下，無論是工作分配還是缺陷處理，都存在大量扯皮，互相推脫任務(wù)或者責(zé)任的現(xiàn)象。職責(zé)不清楚，意味著分工也不能明確，這樣一來使開發(fā)人員不能精心的關(guān)注與某一份確定的工作，他隨時需要學(xué)習(xí)大量的東西，隨時需要處理大量的問題，他所負(fù)責(zé)的模塊的功能也隨時發(fā)生著改變，導(dǎo)致他的工作效率也無法在工作中很好的提升，這同時更意味對他工作考量也存在問題。

2.3 管理困難：軟件的生產(chǎn)流程不是一個機械的過程，因此不會像生產(chǎn)線一樣透明，某個人那里出現(xiàn)了工作或者缺陷的積壓，他也完全有理由推脫給別人。嚴(yán)重的是這種彼此推脫也會帶來其他人的懈怠，很快使整個團(tuán)隊缺乏有效的組織和管理。

2.4 缺陷處理不及時：由于管理過程中的問題沒有得到很好的解決，因此，問題往往到了最后才會發(fā)現(xiàn)，這樣就會大大增加測試人員的工作量，并同時增加調(diào)試的工作量，以及解決問題的時間和效率。

以上問題，不完全是由于軟件開發(fā)的特點所決定的，本文試圖從技術(shù)架構(gòu)的角度去解決上述問題。

3 開發(fā)過程分析

首先，我們看一下軟件的生產(chǎn)過程，在下圖中，需求、設(shè)計、開發(fā)、測試是四個主要的環(huán)節(jié)，工作由左向右依次推動，當(dāng)發(fā)現(xiàn)缺陷時，再由測試向上一環(huán)節(jié)依次提出缺陷的反饋。

以上過程，是開發(fā)的整體過程，并不是開發(fā)人員在技術(shù)架構(gòu)上進(jìn)行部件組裝的過程，也就是說技術(shù)架構(gòu)在部件組裝的過程中發(fā)揮不到任何作用。真正的生產(chǎn)線要在設(shè)計和開發(fā)的階段展開，也就是說，本文中所提到的生產(chǎn)線，應(yīng)該是由設(shè)計人員給開發(fā)人員搭好的一個工作平臺，如果搭建的好，則工作可以順利高效的完成，搭建的不好，則會出現(xiàn)問題?，F(xiàn)有的生產(chǎn)過程如下所示：

從上圖中，不難看出，需求部門、設(shè)計部門、開發(fā)部門的任務(wù)和工作都是比較清晰的，但在開發(fā)階段，所有的需求、組件、工具、模型、框架，全部都被推到開發(fā)人員的面前，他們需要在很短的時間內(nèi)學(xué)會這些工具，并迅速分層組織出所需要的產(chǎn)品，還要接受測試的檢查。這個工作，技術(shù)難度雖然不大，但是工作量非常大，而且，這樣的模式根本不像生產(chǎn)線，而像一個一堆工人聚合在一起的手工作坊。

我們知道，生產(chǎn)線的任務(wù)，不是生產(chǎn)某個零件，而是組織人、機器、工具等生產(chǎn)元素來組裝零件。有了生產(chǎn)線才有了有效的管理，目前上述架構(gòu)中，正是缺乏一個負(fù)責(zé)組裝的技術(shù)架構(gòu)。被組裝的業(yè)務(wù)模塊C和D，實際上需要幾十個組件和工具才能組裝而成，而組裝C的過程和組裝D的過程，實際上有很重復(fù)的和相似的勞作。下圖能夠更清晰的展現(xiàn)開發(fā)人員的工作：

用一句話來描述現(xiàn)有的開發(fā)過程就是：開發(fā)過程是按照業(yè)務(wù)邏輯在技術(shù)架構(gòu)上進(jìn)行的技術(shù)組件的組合過程。這樣就會自然產(chǎn)生三個方面的副作用：（1）業(yè)務(wù)開發(fā)需要等待技術(shù)開發(fā)完成后才能開展，不能同步進(jìn)行；（2）技術(shù)組件和框架的缺陷會自然而然的帶到業(yè)務(wù)開發(fā)過程中；（3）業(yè)務(wù)邏輯需要在全部組合完成后才能得到驗證。

但我認(rèn)為，業(yè)務(wù)邏輯本身是一種組合，也是一種單純的技術(shù)，也是可以被組件化的，只不過這個組件可能復(fù)用性比較低。但把業(yè)務(wù)邏輯組件化會有三個好處：（1）業(yè)務(wù)開發(fā)可以和技術(shù)開發(fā)同步進(jìn)行并且不會相互牽制；（2）業(yè)務(wù)邏輯的問題和平臺組件的問題彼此不相關(guān)；（3）業(yè)務(wù)邏輯做成組件后，就可以獨立于產(chǎn)品而進(jìn)行單元測試。業(yè)務(wù)邏輯組件化后，產(chǎn)品組成關(guān)系如下所示：

在上圖中，技術(shù)框架由粗的CDE可插入模型，變?yōu)榱薈DE通過AB接口可插入的模型，其中CDE不再是獨立的可運行的業(yè)務(wù)模塊，而是使用了AB接口的一個組件，同時，負(fù)責(zé)開發(fā)CDE的開發(fā)人員不需要保證CDE可運行，只需要保證其對AB的使用邏輯沒有問題，而對CDE的調(diào)試和檢測統(tǒng)統(tǒng)由技術(shù)框架負(fù)責(zé)。同時要說明的是AB接口不是原來的AB組件直接的接口，而是由業(yè)務(wù)部門和技術(shù)部門共同約定的一個組件接口，在這里技術(shù)框架看起來更像一個集成框架，因為它真正負(fù)擔(dān)起了生產(chǎn)線的職責(zé)。而改進(jìn)后的過程如下圖所示：

在作出上述改進(jìn)后，生產(chǎn)的流程清晰了很多，但是這里面還存在一個問題，就是最后的一步組裝由誰來完成。顯然，無論是設(shè)計還是技術(shù)部門都可以做這個工作，但如果這個工作仍然是手工作業(yè)，就仍然存在很多問題，所以這個工作的必須主要是由開發(fā)框架來完成的，至少最后的組裝需要用工具來完成，而不能用手工編碼來完成，一起手工編碼的工作都必須分解到足夠簡單。因此這要求技術(shù)框架要包含下面一些組成部分。

4 技術(shù)框架組成

我們普遍認(rèn)為，技術(shù)框架包括組件、工具、手冊、規(guī)范四部分組成，從這四個組成部分就不難看出，我們要求開發(fā)人員參考手冊的說明、使用工具生成一部分元數(shù)據(jù)和源代碼，再使用組件開發(fā)出符合規(guī)范的代碼。但是很明顯，這四個部分中有三個部分都有嚴(yán)重的人為的痕跡，手冊、組件、規(guī)范都是需要學(xué)習(xí)和遵守的，只有工具比較機械化一點，但又常常為開發(fā)人員帶來很多限制。

為了實現(xiàn)把技術(shù)框架打造成生產(chǎn)線的理想模式，必須要求技術(shù)框架包含如下的組成部分：

4.1 技術(shù)框架需要獨立于任何業(yè)務(wù)運行：從界面到服務(wù)到序列化，技術(shù)架構(gòu)要遍布每個技術(shù)環(huán)節(jié)，這個要求看起來很高，但實際上也是很基本的，無論是通過工具生成的，還是手工編寫的，技術(shù)框架要提供一套包含增刪改查的最基本的技術(shù)環(huán)節(jié)的界面，并為技術(shù)組件和業(yè)務(wù)組件提供接口。當(dāng)業(yè)務(wù)組件沒有插入框架的時候，框架可以獨立運行并可接受測試人員的測試。這也是為了保證業(yè)務(wù)和技術(shù)可以分離測試。獨立于業(yè)務(wù)邏輯運行起來并不復(fù)雜，復(fù)雜的應(yīng)該是如何讓業(yè)務(wù)代碼能夠順利嵌入進(jìn)來，這需要對各方面做全面的設(shè)計，對于接口做充分的預(yù)留，在設(shè)計模式上做出松耦合的設(shè)計等等。

4.2 全自動裝配的工具：當(dāng)業(yè)務(wù)模塊開發(fā)完成后，技術(shù)框架需要提供一種非編程的方式，把業(yè)務(wù)組件嵌入框架內(nèi)，并使其良好的運行。我們現(xiàn)有的模式是由平臺的工具生成代碼再讓開發(fā)人員在此基礎(chǔ)上修改，或者由業(yè)務(wù)設(shè)計人員寫好框架代碼，由開發(fā)人員去填空。自動裝配工具就是為了避免這種同一個文件多人負(fù)責(zé)的模式。我們提供全自動裝配的工具就是為了避免裝配過程中可能出現(xiàn)的裝配使用錯誤與組件內(nèi)部錯誤分不清的情況。

4.3 白殼測試系統(tǒng)：無論是技術(shù)組件提交過來還是業(yè)務(wù)組件提交過來，在真正組裝起來之前，技術(shù)框架需要提供一套工具來進(jìn)行白殼測試。這套工具有兩個目的，一是輔助測試，二是輔助管理。我們都知道測試工作不可能完全由機器來運行，必要時候還是需要人的參與，我們提供這套工具要把所有的接口的可能的問題都列舉出來，一部分由工具測試填寫結(jié)果，一部分由白殼測試人員手工測試后填寫。這些測試數(shù)據(jù)將部分的驅(qū)動開發(fā)工作的運行。我們現(xiàn)有的開發(fā)過程與其說是測試驅(qū)動的，不如說是缺陷系統(tǒng)來推動的，但缺陷系統(tǒng)目前僅限于黑客測試人員使用，沒有緊扣開發(fā)過程中的環(huán)節(jié)，因此需要這套測試工具來驅(qū)動。

4.4 過程監(jiān)控系統(tǒng)：有了上面的全自動裝配工具和白殼測試系統(tǒng)，很顯然，就可以有一套全過程的監(jiān)控系統(tǒng)了，這是對整個開發(fā)過程實施過程管理的一套工具軟件。在這個系統(tǒng)上，任何人都可以看到，我們一共需要開發(fā)多少組件、組件難度如何（包括接口數(shù)、代碼數(shù)、依賴關(guān)系組合成的一個參數(shù)）、現(xiàn)在已經(jīng)開發(fā)了多少、還有多少存在問題、哪些組件在等待裝配、裝配好的界面運行效果如何等等。這個系統(tǒng)不能憑空建立，如果憑空建立一個這樣的系統(tǒng)，肯定運行不起來，因為大家可能全部忙碌于具體工作而架空了這個系統(tǒng)，但是如果這個系統(tǒng)中包含具體的工作如自動裝配和白殼測試工具，那么這一系統(tǒng)的運行就會非常自然了。這個系統(tǒng)，才是整個開發(fā)過程的源動力所在。

以上四個部分中，可運行是一切的基礎(chǔ)，只有框架隨時可運行，才能充分暴露各方面的問題；全自動裝配技術(shù)是支撐生產(chǎn)線的最基礎(chǔ)的框架，白殼測試系統(tǒng)是使開發(fā)過程權(quán)責(zé)分明、及時發(fā)現(xiàn)問題及時改正的關(guān)鍵，而過程監(jiān)控系統(tǒng)是整個框架的眼睛。它使得軟件開發(fā)過程真的像工廠車間的流水線一樣，可以清晰的看到每個人的工作量和每個人的問題。毫無疑問，這會大大鞭策和鼓勵我們的技術(shù)人員對自己進(jìn)行更進(jìn)一步的嚴(yán)格要求。

整個過程如下圖所示：

參考文獻(xiàn)：

[1]周麗，聶漢軍.虛擬化高可用性架構(gòu)研究[J].計算機光盤軟件與應(yīng)用，2012，21：120-121.

[2]魏喆.ORACLE ERP系統(tǒng)架構(gòu)設(shè)計與應(yīng)用研究[J].計算機光盤軟件與應(yīng)用，2012，06：179-180

[作者簡介]張玉玉（1989-），女，本科生，現(xiàn)就讀于浙江工商大學(xué)信息學(xué)院計算機科學(xué)與技術(shù)專業(yè)，研究方向：計算機科學(xué)與技術(shù)。