引言

軟件開發(fā)到底是更像工程還是更像藝術(shù)一直是業(yè)界爭論的焦點(diǎn)問題，不管這個問題的結(jié)論如何，它都反映了人們實(shí)現(xiàn)軟件開發(fā)的工程化的愿望。但是在這個工程化過程中卻被若干問題困擾著，以至于人們產(chǎn)生了軟件開發(fā)本身就是一種藝術(shù)創(chuàng)作，無法用工程化的方法對其進(jìn)行管理的想法。

軟件開發(fā)真的不能工程化嗎？軟件工程真的不能擺脫"藝術(shù)創(chuàng)作"的陰影嗎？首先讓我們來分析軟件工程和其他工程發(fā)展的差異。

軟件工程與建筑工程之對比

《營造法式》可以說是中國版的建筑工程"設(shè)計模式"，而人類關(guān)于建筑工程的實(shí)踐則可以追溯到數(shù)千年前。古埃及的金字塔，古巴比倫的空中花園，中國的萬里長城都是古代的巨型建筑工程的代表。金字塔、空中花園、萬里長城絕對是人類歷史上最璀璨的結(jié)晶，但是他們都是成功的項目嗎？我想這個問題誰也不能回答，因?yàn)闆]有一個標(biāo)準(zhǔn)來衡量這些偉大的項目是否是成功的。這些項目在建造的時候是否有投資控制，是否有進(jìn)度要求，是否有質(zhì)量目標(biāo)，這些我們都不得而知。因此，雖然這些都是偉大的建筑，但是我們不能說他們就是建筑工程的成功實(shí)踐。

有大量的數(shù)據(jù)表明能夠同時滿足質(zhì)量、成本、進(jìn)度要求的軟件項目，即成功的軟件項目是少之又少，那么是不是所有的成功的建筑工程項目就是完全滿足了質(zhì)量、成本、進(jìn)度的要求呢？這個問題我們不得而知。

建筑工程相比軟件工程來說，其投資預(yù)算的準(zhǔn)確性要比軟件工程高的多，而質(zhì)量有標(biāo)準(zhǔn)可以衡量，并且那個標(biāo)準(zhǔn)還是相當(dāng)?shù)膶捤伞Ｔ谶M(jìn)度方面，軟件工程不能采用建筑工程中使用的那種增加施工人員和機(jī)械臺班的方法來使進(jìn)度按比例加快。種種原因足以讓軟件工程有充分的理由來讓他的成功率低于建筑工程。但是這不是將軟件工程的較低成功率歸結(jié)于"軟件是藝術(shù)創(chuàng)作"的理由。

另外建筑工程之所以能夠獲得廣泛認(rèn)可的原因關(guān)鍵在于兩樣?xùn)|西：建筑模型（表現(xiàn)圖）和施工圖紙。這兩樣?xùn)|西的存在將最終用戶、設(shè)計單位和施工單位徹底的劃分開來。建筑模型（表現(xiàn)圖）聯(lián)系著用戶和設(shè)計院，是他們的共同語言，設(shè)計院用建筑模型（表現(xiàn)圖）來描述并確認(rèn)用戶的需求。施工圖紙則能夠指導(dǎo)具體施工，雖然它沒有規(guī)定施工的過程和采用的技術(shù)，但是它確定了施工的結(jié)果，施工單位根據(jù)施工圖紙進(jìn)行施工就能夠建造出符合設(shè)計的建筑。這兩種技術(shù)清晰、無二義的表達(dá)了雙方的意圖，這就是建筑工程成功的訣竅。

在軟件工程中，軟件企業(yè)目前只需要和客戶打交道，設(shè)計和編碼并沒有分開由不同的企業(yè)來實(shí)施（軟件編碼外包除外）。那么這第一條鴻溝就出現(xiàn)在用戶和軟件企業(yè)中間的需求理解和如何由需求導(dǎo)出設(shè)計中。遺憾的是軟件工程中的需求確認(rèn)不能像建筑工程中那樣將建筑用筆畫出來，軟件是無法用藝術(shù)家的筆來描繪的。

關(guān)于軟件需求的獲取與確認(rèn)一直是軟件工程中的大問題，但是隨著UML中用例圖的引入而使得需求獲取技術(shù)得到了長足的進(jìn)步，用例技術(shù)讓需求分析簡單并且真實(shí)，客戶也比較容易接受這種圖文并茂的方式，解釋一堆"小人"的工作讓整個需求工程充滿了樂趣。

UML很好的解決了需求工程中需求獲取和確認(rèn)的問題，但是卻沒有給出如何將需求轉(zhuǎn)換成設(shè)計的方法，序列圖和活動圖都不足以正確的將需求轉(zhuǎn)換成軟件模型，在這個中間我們?nèi)鄙僖环N方法讓需求轉(zhuǎn)換成軟件設(shè)計。

軟件的設(shè)計和編碼不進(jìn)行分離是產(chǎn)生"軟件開發(fā)是藝術(shù)"、"編碼是藝術(shù)"的論點(diǎn)的根本原因。設(shè)計本來就是一種藝術(shù)創(chuàng)作，服裝設(shè)計是藝術(shù)，建筑設(shè)計是藝術(shù)，軟件設(shè)計同樣也是藝術(shù)。但請不要將設(shè)計和開發(fā)混為一談，開發(fā)描述的實(shí)現(xiàn)過程，即編碼過程，而設(shè)計在軟件工程中最具代表性的是軟件架構(gòu)設(shè)計。

將藝術(shù)創(chuàng)作性的工作剔除除去，將設(shè)計與實(shí)施分離是任何行業(yè)工程化的基礎(chǔ)。

鴻溝存在的原因

這兩條鴻溝就如同長江和黃河將我國劃分為華北、華中和華南一樣將軟件開發(fā)劃分為需求、設(shè)計與實(shí)現(xiàn)三個階段。如果能夠架起這三個階段鴻溝上的橋梁，我們就完全能夠真正的貫徹軟件工程的思想。但是這樣的兩座橋梁為什么遲遲沒有出現(xiàn)呢？

1、需求-架構(gòu)之鴻溝

需求與架構(gòu)沒有一對一的關(guān)系，他們雖然相互牽連影響，但是關(guān)系卻比較模糊。就如同一個酒店投資者告訴設(shè)計師他需要建一棟100間客房的酒店，設(shè)計師只知道客戶需要100間客房，并不知道客戶是要10層、每層10間，還是要5層、每層20間一樣。投資者也并不知道自己是需要10層還是5層，他只能告訴設(shè)計師，他要?dú)馀梢稽c(diǎn)還是需要節(jié)約投資，或者是兩個綜合考慮取最佳方案。這就是需求，相當(dāng)模糊的需求，設(shè)計師需要依據(jù)自己的經(jīng)驗(yàn)來為客戶做決定，然后他會在自己的頭腦中構(gòu)筑一下整個建筑的模型，最后告訴自己的客戶："10層、每層10間的成本太高，沒有性價比；5層的性價比比較合適；另外如果改成6層、每層20間，即增加20間房間的話，投資只會增加5%，并且外觀上更有氣勢。"

軟件架構(gòu)的設(shè)計如同建筑方案設(shè)計一樣充滿著創(chuàng)造性，并且需要經(jīng)驗(yàn)來支撐。建筑設(shè)計師理解客戶的需求，在頭腦中思考，然后用手中的素描筆勾畫出來。軟件架構(gòu)師根據(jù)客戶需求，選擇適合的軟件架構(gòu)模型，然后用原型告訴客戶我們將做一個什么樣的軟件，客戶并不會要求設(shè)計師采用什么樣的架構(gòu)，實(shí)際上客戶也不可能懂得軟件架構(gòu)，不要給客戶太多的自由選擇機(jī)會，架構(gòu)師必須指導(dǎo)客戶選擇正確的軟件架構(gòu)，而不要讓客戶來主導(dǎo)這一切。

可惜的是，我們十分缺少優(yōu)秀的架構(gòu)師。那些不合格的架構(gòu)師無法為客戶進(jìn)行正確的選擇，不能對客戶提供正確的指導(dǎo)，他們能夠做的就是抄襲類似項目的架構(gòu)設(shè)計，誰知道別人的架構(gòu)是否適合自己的項目呢？試想一下，你將你的酒店設(shè)計交給一個有10年建筑施工經(jīng)驗(yàn)的工程師來做將會是什么樣的后果。在軟件設(shè)計階段，我們需要選擇優(yōu)秀的軟件架構(gòu)設(shè)計師，而不是選擇優(yōu)秀的程序員。

2、設(shè)計-編碼之鴻溝

在沒有將設(shè)計和編碼完全劃分開的軟件企業(yè)是無法體會到設(shè)計和編碼之間的鴻溝的，因?yàn)橥粋€人同時兼了兩種不同的工作，但是一旦將這兩種不同的工作交由不同的人來負(fù)責(zé)的話，溝通就成為了設(shè)計與編碼之間最大的障礙。設(shè)計與編碼之間的溝通問題在實(shí)施外包項目的公司中最為突出，很多軟件公司只做設(shè)計和核心編程，而將外圍或者那些不是很重要的軟件模塊外包給其他公司來做，這樣就出現(xiàn)了設(shè)計與實(shí)現(xiàn)分離的情況。為了保證外包出去的軟件模塊完全按照要求被開發(fā)出來，設(shè)計必須要做得很仔細(xì)并且不會產(chǎn)生歧義。

采用面向接口的設(shè)計和編程很好的保證了開發(fā)出來的模塊符合設(shè)計的要求，設(shè)計師不僅需要提供模塊實(shí)現(xiàn)的功能要求和接口，還需要提供模塊內(nèi)的類的詳細(xì)設(shè)計。只有這樣才能夠保證最終開發(fā)出來的模塊不僅能夠?qū)崿F(xiàn)功能，還能夠保證模塊的穩(wěn)定性、安全性、可維護(hù)性等達(dá)到軟件的整體要求。

負(fù)責(zé)編碼的外包業(yè)務(wù)承接公司只需要按要求進(jìn)行編碼，不需要對設(shè)計上面任何問題負(fù)責(zé)，就如同建筑施工企業(yè)只需要按照施工圖紙施工，由于設(shè)計問題而導(dǎo)致的責(zé)任事故是不需要施工單位負(fù)責(zé)的。編碼方只需要將設(shè)計中的所有類按要求實(shí)現(xiàn)并組裝成為待提交的模塊，進(jìn)行充分的測試，保證提交的軟件模塊是按照設(shè)計的要求實(shí)現(xiàn)的即可。這樣將設(shè)計與編碼的責(zé)、權(quán)、利進(jìn)行分開，很好的保證了各司其職，不會導(dǎo)致設(shè)計和編碼方互相埋怨和推委。

既然設(shè)計和實(shí)現(xiàn)可以分離，為什么目前的軟件開發(fā)還是采取這種"一鍋粥"的開發(fā)模式呢？我想這與設(shè)計與實(shí)現(xiàn)由同一家公司來承擔(dān)有著決定性的關(guān)系。由于設(shè)計和編碼由同一個團(tuán)隊負(fù)責(zé)，因此設(shè)計師在編碼階段還能夠回過頭去修改設(shè)計甚至是軟件架構(gòu)，這種寬松的環(huán)境使得設(shè)計師不會全心的投入到設(shè)計中，因?yàn)樗篮竺孢€有機(jī)會彌補(bǔ)。而建筑設(shè)計一旦將設(shè)計發(fā)布，將要對設(shè)計負(fù)法律責(zé)任，這樣給設(shè)計師形成了必須要將設(shè)計做好、做到位，否則就可能要對自己的設(shè)計錯誤做經(jīng)濟(jì)賠償，嚴(yán)重的甚至可能會惹上法律官司。

外包企業(yè)的設(shè)計和編碼分離得就很好，因?yàn)樵谕獍鼧I(yè)務(wù)中，設(shè)計的錯誤最終引起的是自己的損失，而這種設(shè)計錯誤很容易追查設(shè)計者的責(zé)任。分工明確、責(zé)任清晰的企業(yè)中，越容易進(jìn)行設(shè)計與實(shí)現(xiàn)的分離。

跨越鴻溝，實(shí)現(xiàn)軟件開發(fā)工程化

"一橋飛架南北，天塹變通途"，這是毛澤東對南京長江大橋的評價。

不管是多么難以逾越的鴻溝，只要找到了溝通的方法，就等于架起了一座橋梁。軟件工程中缺乏的就是這樣的橋梁，一座是將需求轉(zhuǎn)換成軟件模型的橋梁，另一座是軟件設(shè)計與軟件編碼之間描述的橋梁。如何才能架設(shè)這兩座橋梁不是技術(shù)的問題，而是人和管理的問題。第一座橋梁需要具有豐富經(jīng)驗(yàn)和行業(yè)知識的軟件架構(gòu)師來擔(dān)當(dāng)，需要能夠?qū)I(yè)務(wù)領(lǐng)域模型正確的映射成軟件架構(gòu)，要清晰的掌握軟件架構(gòu)中的優(yōu)點(diǎn)與缺點(diǎn)，為客戶提供正確的決策服務(wù)。第二座橋梁需要在管理上將設(shè)計和實(shí)現(xiàn)分離，采用不同的隊伍進(jìn)行這兩種工作，明確各自的責(zé)任、權(quán)力和義務(wù)，采用面向接口的設(shè)計和編碼，定義好設(shè)計表示和理解的標(biāo)準(zhǔn)，要形成整個行業(yè)的標(biāo)準(zhǔn)，才能夠真正實(shí)現(xiàn)工程化。

在這里，我提到的是實(shí)現(xiàn)"軟件開發(fā)工程化"。因?yàn)檐浖こ痰恼麄€過程不僅僅是制造的過程，他也包括了設(shè)計的過程。藝術(shù)創(chuàng)作的過程是無法實(shí)現(xiàn)工程化的，這個過程更多的不是需要流水線的生產(chǎn)，而是需要靈感和創(chuàng)新。因此，軟件的架構(gòu)設(shè)計無法納入工程化的范圍。而軟件的編碼則十分適合工程化的管理流程，每個程序員針對已經(jīng)定義好的類的結(jié)構(gòu)和功能進(jìn)行填空式的開發(fā)，程序員不需要知道他編寫的代碼用在什么軟件，實(shí)現(xiàn)什么功能，不需要了解任何業(yè)務(wù)方面的知識。如何快速的編寫符合要求的代碼就是他們的使命，從這點(diǎn)來看，程序員有點(diǎn)類似于機(jī)器化大生產(chǎn)的生產(chǎn)機(jī)器，但是程序員懂得思考，懂得如何以最優(yōu)化的方法來實(shí)現(xiàn)已經(jīng)定義好的類。

總結(jié)

軟件總是以一種神秘的形態(tài)讓人琢磨不定，軟件開發(fā)過程同樣讓人無法完全駕馭。在磕磕碰碰中前進(jìn)，在探索中發(fā)展，是軟件工程這幾十年的艱辛過程。軟件工程中，既有嚴(yán)格定義的瀑布開發(fā)模型，又有小巧敏捷的編程，這些不同的方法論都有著他們各自生存的環(huán)境。軟件工程不僅僅是方法論，更多的是管理方法，那些不改變企業(yè)和項目的管理方式而抱怨某種軟件工程方法不正確的人，根本就沒有真正理解軟件工程。在實(shí)踐中查找問題并進(jìn)行解決，才是軟件工程發(fā)展的原動力。(csai)