。直到20世紀40—50年代
，甚至20世紀60—70年代，業(yè)內(nèi)開發(fā)軟件時往往是先在腦海中設(shè)想軟件跑通的情景
，然后再調(diào)試部署到計算機上。那時的軟硬件規(guī)模很小
，從第一步到最后一步如何執(zhí)行都可以在腦海中預(yù)演
。但是隨著數(shù)字計算機的出現(xiàn)，軟件開發(fā)的效率和質(zhì)量成為突出問題
。例如
，20世紀60年代，為了推動IBM360系列計算機在商業(yè)領(lǐng)域應(yīng)用時可以適應(yīng)各種外部硬件的需求
，IBM開發(fā)出可移植
、適應(yīng)不同設(shè)備的操作系統(tǒng)
。計算機操作系統(tǒng)的研發(fā)和應(yīng)用在軟件史上具有里程碑意義，給軟件界留下了影響至今的操作系統(tǒng)關(guān)鍵技術(shù)
；同時，也給軟件開發(fā)變革帶來一個重要啟示
，即軟件開發(fā)所消耗的人力資源遠遠超出預(yù)期
，軟件質(zhì)量的可靠性、可控性遠遠超出軟件架構(gòu)師和程序員的預(yù)期
。人們發(fā)現(xiàn)，原來軟件也是如此復(fù)雜和不可控的
。所以在那個時代
，處于工業(yè)化生產(chǎn)浪潮中的人們普遍認為西方成熟的工業(yè)化流程能夠保證工業(yè)品的質(zhì)量
，于是順勢形成用保證工業(yè)品批量化大規(guī)模生產(chǎn)的方法來組織新軟件開發(fā)的發(fā)展思路
，這就是所謂的工程范式。
1968年，北大西洋公約組織在一次工作會議上提出“軟件工程”的概念。北約是軍事組織，冷戰(zhàn)時期為應(yīng)對軍事挑戰(zhàn)、爭取在軍事領(lǐng)域地位而積極尋求新型信息技術(shù)的支持
，因而對軟件的復(fù)雜性以及保證軟件開發(fā)的效率和質(zhì)量有著迫切的需求
。在此背景下，北約投資并組織了一批計算機專家
，研究如何解決或提高軟件開發(fā)的質(zhì)量問題，于是就有了工程范式基本理念的產(chǎn)生和實踐
。
我們將軟件工程所遵循的軟件開發(fā)理念和方法，稱為軟件開發(fā)的工程范式。理解這個范式理念，要從工業(yè)化大生產(chǎn)出發(fā)，首先是從工程技術(shù)中借鑒有效的產(chǎn)品開發(fā)組織模式，把人組織好，按照可控制、可預(yù)期的流程來設(shè)計和生產(chǎn)軟件；其次是參照工業(yè)化帶來自動化的經(jīng)驗，盡可能地研發(fā)軟件開發(fā)工具，使軟件開發(fā)的質(zhì)量和效率得以保證。由此，軟件開發(fā)有了各類V模型，從需求分析開始，然后進行系統(tǒng)設(shè)計、程序設(shè)計、模塊測試、單元測試、集成測試、確認測試，最后再交付給用戶一個滿足需求的軟件。與此同時，一個機構(gòu)能不能有效地開發(fā)軟件，對機構(gòu)的軟件開發(fā)能力成熟度該如何評估
，軟件能力成熟度模型（CMM）就出現(xiàn)了，這是一種用于評價軟件承包能力并幫助其改善軟件質(zhì)量的方法
。
再以自動化為例。20世紀60年代，高級語言逐步成熟
，業(yè)內(nèi)人員可以用更接近于人類學習或者訓(xùn)練成本較低的高級語言寫程序
，然后通過編譯器將其自動轉(zhuǎn)變?yōu)闄C器可執(zhí)行的代碼
。在那一時間段，產(chǎn)生了源代碼和目標代碼
，源代碼和目標代碼的變換過程就是由計算機工具
，即我們所熟悉的編譯器完成的
。這些如今司空見慣的技術(shù)工具
，在20世紀60年代
，是巨大的技術(shù)突破
。更進一步的是
，軟件質(zhì)量行不行的問題，直接拉升了軟件測試的工作量
，通過自動測試
，可以評估軟件是不是能夠確保某一個特定的功能性和非功能性的實現(xiàn)
，這就促進了用自動驗證方法進行軟件驗證等一系列技術(shù)的發(fā)展。
可以從以下三方面理解工程范式的理念。一是要把一個軟件的需求說清楚，以確保軟件開發(fā)的過程和質(zhì)量。IBM360計算機就是為解決工程師頭腦中的技術(shù)沒有被描述，因而無法保證軟件開發(fā)質(zhì)量的問題。所以，給出明確的用戶需求描述，是保證軟件開發(fā)過程和質(zhì)量的前提。二是軟件質(zhì)量
，就是開發(fā)出來的軟件能夠滿足需求規(guī)格說明的程度，滿足的程度越
質(zhì)量越好。三是軟件開發(fā)效率，就是在需求確定的情況下
，用更少的投資
、更少的人力、更少的時間
，更快地開發(fā)軟件。那么
，實現(xiàn)上述理念的方法是什么
？就是組織工程師按照一個規(guī)范流程開發(fā)一套軟件技術(shù)，并用支持工具保證軟件開發(fā)所有階段的自動化
。更進一步，當時提高軟件開發(fā)效率的一個重要手段
，是用計算機來幫助開發(fā)軟件
。
隨著IBM360計算機的廣泛使用，軟件開發(fā)效率大幅提升，改進能力逐漸提高
，激發(fā)了計算機應(yīng)用在更多領(lǐng)域的推廣
。但當人們對開發(fā)軟件的復(fù)雜程度和質(zhì)量有了更高要求時
，突然發(fā)現(xiàn)按照這種方法開發(fā)軟件，與制造一輛汽車等其他有形工業(yè)產(chǎn)品并不一樣
，工程范式軟件開發(fā)方法在開發(fā)效率和質(zhì)量上面臨一系列問題。1995年
，IT研究咨詢公司Standish Group對美國境內(nèi)8000個軟件項目進行調(diào)查分析發(fā)現(xiàn)
，83%的項目無法在既定時間內(nèi)開發(fā)完成，開發(fā)周期平均超222%
，52.7% 的項目預(yù)算超出原計劃的189%，31.1%的項目在執(zhí)行過程中因無法控制質(zhì)量和成本而被取消
。隨著軟件復(fù)雜程度變得更高
，互聯(lián)網(wǎng)時代到來了，軟件開發(fā)面臨著更大的挑戰(zhàn)
。
出現(xiàn)上述情況，業(yè)界有以下四點分析 。一是工程范式遇到理論瓶頸
。軟件開發(fā)需要我們明確需求，但當軟件需要應(yīng)對越來越多的問題
、互聯(lián)網(wǎng)時代迅猛到來的時候，我們突然發(fā)現(xiàn)自身把一個問題說清楚的能力十分有限
，過去把一個問題說清楚要以數(shù)學形式來表達
，但實現(xiàn)這個能力在理論上存在界限；還有將需求用工具自動轉(zhuǎn)化為可執(zhí)行代碼
，同樣有計算性和可判定性的瓶頸問題；此外
，還存在變換的復(fù)雜性問題
。大家發(fā)現(xiàn)，這一系列問題在理論上是不可逾越的
。二是工程范式的效率問題
。實踐證明，軟件開發(fā)效率怎么也趕不上“摩爾定律”帶來的計算基礎(chǔ)設(shè)施硬件發(fā)展的速度（處理器的性能大約每兩年翻一倍
，同時價格下降為之前的一半）
。三是協(xié)同瓶頸。面對越來越復(fù)雜的軟件
，使用更多人力并不
能效率提高，可能還會降低效率，甚至可能導(dǎo)致軟件開發(fā)失敗
。四是網(wǎng)絡(luò)時代到來后，業(yè)內(nèi)在開發(fā)
系統(tǒng)軟件時發(fā)現(xiàn)，過去開發(fā)軟件需要先確認需求，但在互聯(lián)網(wǎng)時代 ，開發(fā)軟件并不知道面對的用戶是誰。只有當軟件開發(fā)完成面世后被用戶所接受
，才可以驗證出軟件適合的用戶群體
。這些新情況
，都給原有的軟件開發(fā)方式帶來巨大挑戰(zhàn)
。
二 、開源范式：自下而上
，關(guān)聯(lián)涌現(xiàn)
互聯(lián)網(wǎng)時代的到來 ，給軟件開發(fā)也帶來了重要變化
。20世紀90年代，乃至過去的20年
，促進軟件迅速發(fā)展的方法不是我們所期待且矚目的工程化方法
，而是一個不被學術(shù)界甚至產(chǎn)業(yè)界關(guān)注的“下里巴人”狀態(tài)。它帶來了從群體化生產(chǎn)到大規(guī)模群體創(chuàng)作的變化
，我們稱之為開源范式。這種范式的起因是1974年貝爾實驗室向大學免費開放Unix源代碼系統(tǒng)
。美國政府為保護在新興計算機市場和軟件市場的競爭優(yōu)勢
，于是支持Unix操作系統(tǒng)免費授權(quán)給大學或研究機構(gòu)做研究使用。隨著Unix的自由發(fā)展
、版本變多
，AT&T開始重視Unix的商業(yè)利益，因此就出現(xiàn)版權(quán)回收問題
，比如IBM等被授權(quán)的Unix商業(yè)版本代碼不再能被自由傳播
，就出現(xiàn)了所謂的開源狀態(tài)，出現(xiàn)了開放軟件基金會
。
20世紀90年代的軟件系統(tǒng)格局由兩部分組成，一是個人計算機占統(tǒng)治地位后，商業(yè)閉源軟件成為主流，而另一個支流是在學術(shù)界傳播和發(fā)展的Linux開源軟件。開源范式支持在不確定的網(wǎng)絡(luò)世界通過眾多的開發(fā)者帶來豐富變化和競爭，并自然演化出得到用戶歡迎的軟件制品。Linux正是通過開源范式帶來的易變性和多樣性，才更能應(yīng)對未來操作系統(tǒng)發(fā)展的不確定性，當智能手機、云計算、物聯(lián)網(wǎng)等新的需求涌現(xiàn)時，Linux的眾多衍生系統(tǒng)就具有更強大的生存能力和市場競爭力。
開源時代的到來，主要是因為開源在互聯(lián)網(wǎng)時代成為科技領(lǐng)域創(chuàng)新的主要驅(qū)動力。開源領(lǐng)域代碼生長迅速，到1993年，Linux已經(jīng)從當初只有一個代碼，增長到大概10萬行代碼；再到現(xiàn)階段，僅華為開放參與的代碼規(guī)模就已經(jīng)超過3300萬行，涉及的工程師超過3萬人 ，僅去年一年提交的代碼就有120多萬個。這種聚集起如此廣泛的開發(fā)者和貢獻者的開源狀態(tài)
，支撐起至少500個版本的開源操作系統(tǒng)被商業(yè)化使用
。超級計算機TOP500強幾乎均采用Linux作為其操作系統(tǒng)，而云計算操作系統(tǒng)也無一例外都使用開源系統(tǒng)
。如今的智能手機、機器學習、大模型同樣是開源系統(tǒng)狀態(tài)
。大模型領(lǐng)域中開源軟件的應(yīng)用非?div id="m50uktp" class="box-center"> ；钴S，由此帶動了中國大模型不斷涌現(xiàn)
。開源之所以取得成功，是因為它通過多樣性來應(yīng)對不確定性
。
20世紀80年代，在個人計算機時代，計算機發(fā)展的確定性使得微軟以給企業(yè)操作系統(tǒng)發(fā)放閉源許可證的方式，獲得對操作系統(tǒng)和軟件的定義權(quán)。作為當時生產(chǎn)力的代表，微軟以其確定性視野定義了當時的互聯(lián)網(wǎng)時代，也正因如此，無論操作系統(tǒng)版本如何演化，都完全由這家公司來控制。考慮控制成本，市場主導(dǎo)者就不會開發(fā)更多的版本分支，一個操作系統(tǒng)版本就能解決所有問題。當軟件、操作系統(tǒng)的每個分支均由微軟一家開發(fā)時，那么這家公司以企業(yè)化的方式組織數(shù)千個工程師，耗時幾年全力開發(fā)一個新版本即可控制市場。還好，這種情況在互聯(lián)網(wǎng)時代發(fā)生了變化。按照GPR模型，每個人都可以基于軟件內(nèi)核進行修改，修改后再反饋回來，這是一種雙性范式。GPR下的內(nèi)核可由軟件下載方按照自己的理解書寫新的版本，如此就可以產(chǎn)生相當多的分支，在不確定性的互聯(lián)網(wǎng)時代，開源給軟件、操作系統(tǒng)等在各個領(lǐng)域的探索提供了巨大的可能。也就是說，適應(yīng)互聯(lián)網(wǎng)不確定性的軟件可能版本數(shù)量變多了
，可成本卻降低了，這或許就是開源成功背后的邏輯
。
相較于工程范式，開源范式有很多理念上和方法上的革命性變化。一是從需求看，開源軟件沒有明確的用戶
。在互聯(lián)網(wǎng)時代
，互聯(lián)網(wǎng)軟件并不知道自己的用戶在哪里，用戶就是開發(fā)者自己
，開發(fā)者基于他所理解的世界進行創(chuàng)作
，而不以明確需求為開發(fā)前提，這不像過去工程范式要求的那樣
，開發(fā)軟件之前要明確它的用戶群體。
二是從質(zhì)量看，什么是好的軟件，開源社區(qū)中反響熱烈的軟件就是好的軟件。三是從效率看
，什么是效率
，開源社區(qū)中有人提出問題后，響應(yīng)快就是效率高
。
不過，開源模式同樣有其問題。開源時代的組織模式是自組織模式，工具主要是版本控制。實踐中，軟件開發(fā)的版本控制很復(fù)雜，而如此多的版本控制更是災(zāi)難性問題。另一個問題就是軟件發(fā)布?div id="d48novz" class="flower left">，
，由少數(shù)人、學術(shù)界走向全社會
，成為一種通過互聯(lián)網(wǎng)傳播的開發(fā)模式
。這個模式是適應(yīng)變異和競爭的軟件開發(fā)范式，可以稱之為自下而上的開發(fā)方式
，和自上而下的開發(fā)方式形成了鮮明對照
。開源對中國軟件發(fā)展產(chǎn)生了巨大的影響，也就是在開源大發(fā)展的階段
，中國軟件終于獲得了觸達基礎(chǔ)軟件核心技術(shù)實現(xiàn)的機會
。工程范式和開源范式都存在各自的問題
。工程范式強調(diào)確定性
，需要有確定的需求和確定的用戶，按照給定的時間和預(yù)算
，最終提交給軟件使用者
。工程范式強調(diào)的是要聚焦交付給用戶的軟件產(chǎn)品，而開源范式是一個自組織甚至是無組織的群體
，最終實現(xiàn)的是程序員或者程序設(shè)計者的個人作品
，軟件發(fā)布不對最終結(jié)果做確定性承諾
。
工程范式更加強調(diào)圍繞質(zhì)量和需求這樣一個匯聚開發(fā)者智力的生產(chǎn)控制過程，而開源范式則是一個鼓勵自由創(chuàng)作的過程
。當然，確定性和不確定性沒有好壞之分
，當我們能夠看到確定性的時候應(yīng)該用工程化的方法來達成
，當我們的目標不那么明晰時可以鼓勵更多的可能性探索。那么
，實踐中如何平衡軟件需求的確定性和不確定性之間的矛盾
，進而更有效地
、可預(yù)期地組織軟件開發(fā)群體的智力？這就需要探索一個更加平衡的方式——群智范式
網(wǎng)站地圖
XML
備案號:遼ICP備19014743號-1