Jack Greenfield

Microsoft Corporation

摘要：簡要介紹 Microsoft 開發軟件工廠這種方法的動機。所謂軟件工廠就是指為了支持某種特定應用程序的快速開發而配置的開發環境。軟件工廠從邏輯上講就是軟件開發方法和實踐的下一個發展階段。然而，通過引入產業化模式，軟件工廠勢必會改變軟件行業的現狀。

擴大軟件開發的規模

從目前的情況來看，軟件開發的速度緩慢、代價高昂而又極易出錯，常常會生產出存在大量缺陷的產品，在可用性、可靠性、性能、安全以及其他服務質量方面造成嚴重的問題。

根據 Standish Group [Sta94] 的統計，美國公司每年投資約 175,000 個軟件開發項目，投資額約為 2,500 億美元。這些項目中只有 16％ 能夠在預算內按計劃完成。另有 31％ 的項目主要由于質量問題而被取消，經濟損失約為 810 億美元。另外 53％ 的項目平均超出預算 189％，經濟損失約為 590 億美元。完成的項目平均只實現了原來規劃的功能的 42％。

這些數字客觀地印證了我們根據經驗所做出的判斷，那就是軟件開發是一項勞動密集型的產業，它創造每一美元的價值所消耗的人力資本超過了我們對于一個現代化行業的期望值。

當然，除了這些缺點以外，軟件開發的成果顯然為消費者帶來了巨大的價值，正如需求增長的長期趨勢所表明的那樣。但這并不意味著消費者已經非常滿意，不管是對我們提供的軟件，還是對我們提供軟件的方式。這只是說明他們確實看好軟件的前景，愿意承擔巨大的風險和損失，以此來獲得軟件所帶來的好處。然而，正如軟件開發的外包越來越受歡迎所表明的，這種情況顯然不是最好的，因為它似乎不能推動軟件行業在軟件開發方法和實踐方面作出重大的改變。

在過去十年中，生產率只獲得了有限的提高，最重要的原因可能是采用了字節編碼的語言、模式和靈活的方法。除了這些進步，我們開發軟件的方法與十年前沒有什么不同。我們的方法和實踐實際上沒有太大的改變，相應的成本和風險同樣也沒有太大的改變。

然而，這種情況就要被改變。據預測，全球對軟件的總體需求將在下一個十年中以數量級的速度增長，這是由于受到全球經濟中的新生力量（例如中國的崛起）的推動，以及由于新的應用類型（例如商業集成和醫學信息科學）和新的平臺技術（例如 Web 服務、移動設備和智能產品）而使軟件在社會基礎結構中的作用日益加大。

如果軟件開發能力沒有相應的增長，那么十年后勢必出現總體軟件開發能力大大低于總體需求的局面。當然，如果市場力量能夠自由運作，這種情況不會真正出現，因為受到啟發的軟件提供商將出于個人利益而提供足夠多的軟件來滿足這種需求。

再次面對新的挑戰

那么，怎樣才能提供足夠多的軟件開發能力呢？不用太多的分析就可以看出，必須對軟件開發的方法和實踐進行顯著的改變。

因為行業的生產能力取決于合格開發人員的數量以及開發人員的工作效率，因此提高行業生產能力的方法是，或者繼續采用現有的方法和實踐而投入更多的開發人員，或者保持相當數量的開發人員而采用不同的方法和實踐。

盡管過去十年間培育起來的學徒制似乎已經成功地增加了合格開發人員的數量并提高了開發人員的平均水平，但至少有兩個理由可以說明學徒制不大可能使軟件行業的生產能力滿足預期的需求水平：

• 經驗告訴我們，沒有什么比擁有一些杰出的程序員更重要。杰出開發人員比蹩腳開發人員的工作效率高一千倍，但蹩腳開發人員的數量也幾乎是杰出開發人員的一千倍 [Boe81]。

• Brooks [Bro95] 指出，增加項目人數最終會導致邊際收入減少。通過招募和培訓新開發人員而獲得的生產能力將逐漸下降。

因此解決問題的出路應是改變我們的方法和實踐。我們必須通過各種途徑提高開發人員的工作效率。

創新曲線與模式轉變

作為一個行業，我們從一開始就需要共同面對這種情況。軟件開發的歷史是一個與復雜和變化作斗爭的過程，時而盈利時而虧損，隨著時代的進步而產生更多的需求。雖然僅僅半個世紀就取得了不少輝煌的成績，然而道路并不平坦。相反，軟件開發一直沿著著名的創新曲線模式在前進，如圖 1 所示 [Chr97]。

典型的情況是，一個不連續的創新為一個新的技術時代奠定基礎。新基礎之上的發展一開始是快速的，但隨著基礎的穩固和成熟，發展速度逐漸慢下來。最后，這個基礎失去了繼續創新的能力，達到發展的頂峰。同時，另一個不連續的創新為另一個新技術時代的到來奠定基礎，于是上述模式得以重復。Kuhn 稱上述基礎為模式，稱它們之間的轉變為模式轉變 [Kuh70]。模式轉變發生在需要改變現狀以繼續前進的交匯時刻。我們現在正處在這樣一個交匯時刻。

提高抽象水平

在歷史上，模式的轉變曾經成功地提高了開發人員的抽象水平，為在平臺和語言中獲得知識并重復利用知識提供了強大的概念。例如，在平臺方面，我們從批處理開始，經歷了終端/主機、客戶機/服務器、個人計算、多層系統和企業應用集成，再到異步、松散耦合的服務。在語言方面，我們從數字編碼語言開始，經歷了匯編語言、結構化語言和面向對象的語言，再到字節編碼的語言和模式，這可以看作是基于語言的抽象。Smith 和 Stotts 對此進步作了意味深長的總結 [SS02]：

編程的歷史是在體系結構抽象方面的一種鍛煉。在每個時代，語言設計人員通過總結上一代的經驗教訓創造出結構，然后體系結構設計師使用這些結構創造出更復雜，更強大的抽象。

他們還指出，新的抽象一般先出現在平臺上，然后移植到語言中。我們現在的情況是，基于語言的抽象已遠遠落后基于平臺的抽象。換句話說，現在是工具遠遠落后于平臺。我們現在正在使用最新的平臺技術（例如，通過采用配樂法編寫服務，我們現在能夠使位于這個星球上任何位置的多個企業間的進程自動化），但我們仍然在手動編寫每個應用程序，好象這是首選的方法一樣。我們從小的具體概念（例如循環、字符串和整數）入手來創造大的抽象概念（例如保險索賠和證券交易）。我們勤勤懇懇一絲不茍地工作，將上百萬小的相關源代碼片段和資源組合在一起，形成巨大而復雜的結構。如果半導體行業也采用類似的做法，他們需要用手焊接晶體管來建立起支持這些應用程序的巨大而復雜的處理器。相反，他們通過組裝稱為特定用途集成電路 (ASIC) 的預定義組件，使用如圖 2 所示的工具來完成實現。

難道我們不能采用類似的方式來實現軟件開發的自動化嗎？當然能，而且實際上我們已經在這樣做。例如，數據庫管理系統通過 SQL 實現數據訪問自動化，提供了諸如數據集成和獨立性等優點，使數據驅動的應用程序更易于創建和維護。與此類似，Widget 框架和 WYSIWYG 編輯器使得創建和維護圖形用戶界面更容易，提供了諸如設備獨立性和可視化組裝等優點。仔細分析這些做法，我們可以發現一個反復出現的模式。

• 在給定問題領域開發出大量系統之后，我們為該領域確定一組可以重復利用的抽象，然后我們制訂一組模式，規定如何使用這些抽象。

• 然后我們開發一個運行時（例如框架或服務器），將這些抽象和模式代碼化。這樣，我們可以通過對運行時所定義的組件實例化、調整、配置和組裝，從而在該領域中創建系統。

• 然后我們定義一種語言并創建支持該語言的工具（例如編輯器、編譯器和調試器），使組裝過程自動化。這樣可以幫助我們對不斷變化的要求做出快速響應，因為部分實現已經完成，而且可以輕松地加以修改。

這就是 Roberts 和 Johnson [RJ96] 所描述的著名的“語言框架”模式。一個框架可以按數量級降低開發一個應用程序的成本，但只使用一個框架則很困難。一個框架定義一種具有某種典型體系結構的產品（例如應用程序或子系統），這些產品可以通過各種方式進行完善和專門化的處理，以滿足不同的要求。將每種產品的要求映射到框架中絕不是一個小問題，通常需要借助于體系結構設計師或高級開發人員的專業技能。通過使用語言表達式捕獲各種要求，然后生成框架完成代碼，基于語言的工具可以自動完成此過程。

實現軟件開發的產業化

在其他行業，提高生產能力的途經是從手工作業過渡到機械生產。在手工作業階段，所有產品都是由個人或小組從無到有制造出來的，而在機械生產階段，各種產品通過組裝多家供應商生產的可重復利用的組件迅速生產出來，在這個過程中，許多機械瑣碎的任務都是由機器自動完成的。這些行業對工藝、設計和包裝進行標準化，借助產品線實現系統性重復利用，并通過供應鏈分擔成本和風險。現在已有部分行業可以實現大規模定制，根據需求快速而經濟地制造出各種產品，以滿足不同客戶的特定要求。

軟件能夠實現產業化嗎？

人們對軟件與實物之間的類比進行過熱烈的討論。這些產業化模式能夠應用于軟件行業嗎？難道軟件行業沒有因其產品性質的不同而比其他行業特殊嗎？Peter Wegner 對它們之間的異同總結如下 [Weg78]：

軟件產品在某些方面與傳統工程學科中的有形產品（如橋梁、建筑物和計算機）存在相似之處。但也存在某些重要的區別，使得軟件開發與眾不同。由于軟件是邏輯概念而非實物，因此其成本集中在開發過程中而不是生產過程中。又因為軟件不會磨損，因此其可靠性取決于邏輯質量（如正確性和穩健性）而非物理質量（如硬度和韌性）。

有些討論將實物的生產與軟件的開發比作“蘋果與桔子”。理清這些困擾的關鍵是理解生產和開發之間的不同，以及規模經濟與范圍經濟的不同。

為了獲得投資回報，必須盡最大可能重復利用那些可重復利用的組件而不僅僅是收回開發成本，無論是直接通過降低成本，還是間接通過降低風險、縮短進入市場的時間或改進質量來實現。從投資角度講，可重復利用的組件屬于金融資產。由于為使組件可重復利用而耗費的成本通常非常高，很難達到可獲利的重復利用程度，因此需要有一種系統的方法來實現重復利用。這通常包括確定一個要開發多個系統的領域，找出該領域中重現出現的問題，開發出一套解決該問題的集成生產資產，然后將這些資產應用到在該領域中開發系統的過程中。

規模經濟與范圍經濟

系統性重復利用可以同時產生規模經濟和范圍經濟的效應。這兩種效應在其他行業廣為人知。盡管二者都是通過集中而非單獨生產多個產品來減少時間和降低成本并提高產品質量，但二者在產生這些優點的方式上卻存在著不同。

當集中而非單獨生產一個設計的多個相同實例時，就產生了規模經濟，如圖 3 所示。規模經濟可能出現在生產機器螺釘等產品時，在這種生產過程中，可以使用機床等生產資產生產出多個相同的產品實例。工程師通過一種資源密集的過程（稱為開發）完成設計與最初的實例（稱為原型）。然后通過另一個由機器和/或低成本勞動力完成的過程（稱為生產）創造出更多實例（稱為復制品），以滿足市場需要。

范圍經濟通過集中而非單獨生產多個相似但不同的設計和原型而實現，如圖 4 所示。例如在汽車制造業，多個相似但不同的汽車設計通常是通過組合子部件（如底盤、車體、內部裝飾及傳動裝置）的現有設計來開發的，而不同的款式或型號通常是通過改變現有設計中的某些功能（如發動機和裝飾水平）來產生的。換言之，可以使用相同的方法、工藝、工具和材料設計出多個相似但不相同的產品，并制作出相似但不相同的原型。商業建筑同樣如此，很少看到多座橋梁或多幢摩天大樓采用同一種設計。但商業建筑領域存在一個有趣的現象，即每個成功的設計通常只會產生一兩個實例，因而規模經濟幾乎從未真正實現過。在汽車制造業，通常會從成功的設計產生出許多不同的實例，通過復制每個原型，范圍經濟與規模經濟形成互補，如圖 4 所示。

當然，軟件無論與汽車制造還是與商業建筑之間都存在重要區別，但它們常常有著相似的地方。

• 在諸如用戶桌面產品之類的市場中，操作系統和工作效率應用程序等產品通過復制形成批量生產，軟件行業呈現出規模經濟的特點，如同在汽車制造業中一樣。

• 而在諸如企業用戶產品之類的市場中，為獲得競爭優勢而開發的商業應用程序很少能夠進行批量生產，軟件僅呈現出范圍經濟的特點，如同在商業建筑領域中一樣。

現在我們可以清楚地看到蘋果與桔子之間的區別了。將實物行業的生產與軟件開發進行比較未免有些天真。不管是軟件還是實物，在任何類型的開發中尋求規模經濟效果都是沒有意義的。但是，我們卻可以期待軟件開發的產業化能夠帶來范圍經濟的效果。

產業化會帶來什么樣的結果？

假設可以在軟件行業實現產業化，那么結果將會是什么樣子呢？當然，在事情發生之前我們不可能確切地知道。但是，我們可以根據軟件行業的發展道路以及其他行業產業化后的情形作出合理的推測。顯然，軟件開發永遠不會簡單到懶人們所希望的那種純機械化的程度。相反，滿足全球需求的關鍵是不要再把杰出開發人員的時間浪費在機械瑣碎的任務上。我們必須盡一切努力更好地利用這些稀有資源，不要再讓他們把時間花費在手動構造因為下一個主要平臺版本的出現或者市場條件的變化而致使行業需求改變進而導致短短幾個月或幾年內就需要維護甚至替換掉的最終產品上。

實現此目的的方法之一就是為開發人員提供各種途經，使他們能夠將自己的知識轉化成可供他人重復利用的資產。這個目標是否遙遙無期？有些模式已經表現出重復利用知識的有效性，盡管利用程度不高。下一步是使用語言、框架和工具自動生成模式化的應用程序，從而實現從編程到自動化的飛越。

半導體開發為軟件開發實現產業化后的情形提供了預演。這并不是說軟件組件很快就能象 ASIC 那樣易于組裝，ASIC 是經過封裝和接口技術領域二十年的創新和標準化而開發出來的產品。但另一方面，軟件開發可能用不了 20 年。軟件開發的優勢在于只需要處理比特，而半導體行業還需要承擔組件實現所需的物理材料工程的額外負擔。與此同時，比特所固有的短壽特性也為諸如數字知識產權保護等帶來了難題，正如我們在電影和音樂行業所看到的那樣。

結論

本文描述了軟件行業在利用現有方法和實踐來面對預期需求上的無能為力。這里只對許多問題進行了簡要敘述，無疑會引發讀者尋求證據或更多詳細的討論。要獲得更詳細的討論，請參閱此書 Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools，此書的作者為 Jack Greenfield 和 Keith Short，由 John Wiley and Sons 出版社出版。有關詳細信息，也可以訪問 http://msdn.microsoft.com/architecture/overview/softwarefactories 和 http://www.softwarefactories.com/，這里提供了各種文章，介紹了阻止從手工作業向機械生產轉換的長期問題、幫助行業克服這些問題的重大創新以及集成了重大創新的軟件工廠方法。

版權聲明

© 版權所有 2004 Jack Greenfield。© 部分版權所有 2003 Jack Greenfield 和 Keith Short，已從 Wiley Publishing Inc. 獲準再版。保留所有權利。

參考資料

1. [Boe81] B Boehm.Software Engineering Economics.Prentice Hall PTR, 1981

2. [Bro95] F Brooks.The Mythical Man-Month.Addison-Wesley, 1995

3. [Chr97] C Christensen.The Innovator's Dilemma, Harvard Business School Press, 1997

4. [Kuh70] T Kuhn.The Structure Of Scientific Revolutions.The University Of Chicago Press, 1970

5. [RJ96] D Roberts and R. Johnson. Evolving Frameworks:A Pattern Language for Developing Object-Oriented Frameworks.Proceedings of Pattern Languages of Programs, Allerton Park, Illinois, September 1996

6. [SS02] J. Smith and D Stotts.Elemental Design Patterns – A Link Between Architecture and Object Semantics.Proceedings of OOPSLA 2002

7. 本圖利用 Virtuoso® Chip Editor 和 Virtuoso® XL Layout Editor 生成，并得到了 Cadence Design Systems, Inc. 的許可。© 版權所有 2003 Cadence Design Systems, Inc.。保留所有權利。Cadence 和 Virtuoso 是 Cadence Design Systems, Inc. 的注冊商標。

8. [Sta94] The Standish Group.The Chaos Report.http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf

9. [Weg78] P Wegner.Research Directions In Software Technology.Proceedings Of The 3rd International Conference On Software Engineering. 1978

作者簡介

Jack Greenfield 是 Microsoft 公司負責開發企業框架和工具的體系結構設計師。他曾擔任 Rational Software Corporation 公司 Practitioner Desktop Group 小組的主要體系結構設計師，他還是 InLine Software Corporation 公司的創始人和首席技術官。他曾在 NeXT 開發了企業對象框架，現在稱為 Apple Web Object。他是著名的演講者和作家，同時他還對 UML、J2EE 及相關的 OMG 和 JSP 規范做出過很大貢獻。他擁有 George Mason University 物理學學士學位。可通過 jackgr@microsoft.com 與 Jack 獲得聯系。

 

轉自：http://msdn.microsoft.com/zh-cn/library/aa480032.aspx