Semat計劃于2009年12月由軟件工程三位大師（合稱“Troika”）Ivar Jacobson（UML、RUP、組件和組件架構(gòu)、用例等技術(shù)之父），Bertrand Meyer（Eiffel和按約定設(shè)計之父）和Richard Soley（OMG主席）正式發(fā)起，倡導(dǎo)以堅實(shí)的理論、已經(jīng)證明的原理和最佳實(shí)踐為基礎(chǔ)，重新發(fā)現(xiàn)軟件工程的本質(zhì)。Jacobson等撰寫了三篇文章詳細(xì)闡述Semat思想，本刊將陸續(xù)刊載，本文是其中第一篇。佛羅里達(dá)大西洋大學(xué)黃詩虹教授另撰有《Semat: 軟件開發(fā)的又一次革命》一文，刊載于雜志官網(wǎng)，推薦閱讀。

　　對于正在尋找軟件開發(fā)方法的人來說，問題不在于是否能找到答案，而是確定答案是否滿足要求。是的，我們已經(jīng)有了很多方法——每年都會出來一茬新的，但是這讓可憐的一線開發(fā)人員感到奇怪，為什么去年的招兒又不夠好了，為什么他們必須接受今年的新法子。為了尋找嚴(yán)格的概念性論據(jù)，必須看透炒作之詞，找到其中少
量行之有效的真知灼見。

　　在本文中，我們將論述軟件開發(fā)方法學(xué)必須經(jīng)歷深刻的變革。應(yīng)該放棄當(dāng)前依賴于新詞和政治式宣傳的狀況，轉(zhuǎn)向基于理論和實(shí)驗驗證的嚴(yán)肅的科學(xué)工作。

　　時裝業(yè)，政治還是工程學(xué)科？

　　軟件方法學(xué)是一個特殊的領(lǐng)域。按原理它應(yīng)該是基于科學(xué)的工程學(xué)科，但目前的實(shí)踐中它卻時而像時裝業(yè)，時而又像搞政治。

　　時裝業(yè)每年都要有一種新潮流，在匆忙跟風(fēng)中，人們將好的和壞的一起拋棄。人們不是從自己的經(jīng)驗中學(xué)習(xí)，而是跟著自認(rèn)為更好的走，因為其他人都說這樣更好。創(chuàng)新者們常常抱怨，大公司擁抱變化非常緩慢，但事實(shí)上并非如此，許多大公司非常渴望嘗試新事物。真正的問題在于，他們也會更快地放棄，還沒等認(rèn)真用起來呢，在過程和工具上的不菲投入就打水漂了。

　　在政治（或者說得更準(zhǔn)確些是壞的政治）中，重點(diǎn)不是放在難題的切實(shí)解決，而是口號、宣傳和煽情。理念不是通過對利弊仔細(xì)的討論來提出，而是像品牌那樣進(jìn)行營銷，借助一些大師的一些金口玉言來傳播。每一種方法都試圖忽略自己的同類，如果不得不承認(rèn)它們的存在，通常也會惡意貶低，這弄得一線人員無所適從。

　　最終，很少有新思想能運(yùn)用在大規(guī)模的項目里，因此對大系統(tǒng)開發(fā)中的質(zhì)量、生產(chǎn)力和上市時間等等都沒有產(chǎn)生什么影響。過去四十年中軟件開發(fā)方法中出現(xiàn)的所有新概念里，只有少數(shù)大的創(chuàng)新——結(jié)構(gòu)化編程、對象技術(shù)、設(shè)計模式和UML等對行業(yè)產(chǎn)生了真正的影響。

　　這些都是不成熟的表現(xiàn)。我們的學(xué)科該長大了。

　　敏捷

　　席卷業(yè)界的最新一波浪潮是“敏捷”。敏捷方法的確做出了許多貢獻(xiàn)，并使我們再次注意到人在軟件工程中的中心地位。一些敏捷的經(jīng)驗很可能仍然會在未來的方法中繼續(xù)存在。與此同時，敏捷領(lǐng)域也為上面談到的現(xiàn)象提供了活例子。作為一個重視人甚于過程和工具的運(yùn)動，敏捷卻提出了許多被宣傳為“新的”過程和工具，而且沒有說清楚其中哪些是真正新的，哪些只是已有概念的重述。很多一線人員很自然地就被弄暈了。先不說這些“新”概念的價值如何，對它們的推廣方式就頗為引人注目：先是為這個方法精心編寫了一份基礎(chǔ)性文獻(xiàn)的——一個宣言（http://agilemanifesto.org/），更多的是第一人稱復(fù)數(shù)的情感訴求（我們必須……），而缺少事實(shí)依據(jù)。這種風(fēng)格對于吸引眼球可能有效，但隨著概念日益成熟，還是應(yīng)該采用更傳統(tǒng)（也更枯燥的）闡釋形式。

　　在工程和科學(xué)中，一種新技術(shù)的提出者與任何人一樣都急于推廣自己的發(fā)明，但是也會很小心地確定應(yīng)用這項新技術(shù)在什么地方存在不足或者未經(jīng)證實(shí)。然而，很少有軟件方法學(xué)者會提供這樣的警示信息。太多人夸大了自己的方法與前人的差異。每一次變革（比如對象技術(shù)）中，有多少突破其實(shí)是已知概念的調(diào)整？逐漸改進(jìn)當(dāng)然沒有錯，科學(xué)和工程中大量進(jìn)展都是如此實(shí)現(xiàn)的。但是，將每一次改進(jìn)都包裝成革命，就沒意思了。

　　目前的方法：多種實(shí)踐的大雜燴

　　我們目前軟件開發(fā)的方法，無論是商業(yè)還是公司內(nèi)部，新還是舊，需求已知還是不清，實(shí)際上都只是來自方法文獻(xiàn)中各種元素的組合，加上一些特定于領(lǐng)域或者業(yè)務(wù)的擴(kuò)展。基本的成分是一個個實(shí)踐。

　　如果我們將這些基本成分從大雜燴中分離出來，大家就可以建立自己所需的方法。這種方法是以模塊的方式設(shè)計的，能夠在不斷總結(jié)經(jīng)驗的基礎(chǔ)上快速演進(jìn)，響應(yīng)我們快速變化的行業(yè)的需求。

　　構(gòu)建理論

　　經(jīng)濟(jì)壓力是當(dāng)前的時代特征，與時裝業(yè)的跟風(fēng)和政治宣傳一樣都不會完全消失。但是，所有關(guān)注軟件工程價值的方法學(xué)者都理應(yīng)為學(xué)科找到存在的理由。

　　我們所缺乏的是作為一門科學(xué)和工程學(xué)的基礎(chǔ)：理論及其驗證。我們應(yīng)該采取以下步驟，將軟件方法學(xué)轉(zhuǎn)變?yōu)橐环N嚴(yán)謹(jǐn)?shù)墓ぷ鳌?strong>

　　對方法的本質(zhì)進(jìn)行建模

　　軟件開發(fā)是一種人的活動，但它也是由若干明確定義的步驟組成的，而且我們對這些步驟之間關(guān)系已經(jīng)有了充分認(rèn)識。至少，在有經(jīng)驗的從業(yè)人員腦中，對這些概念的定義和理解都是不言自明的。但這還不夠，我們需要堅實(shí)的軟件開發(fā)理論。形式化方法為我們提供了進(jìn)行建模的正確工具，含有約定構(gòu)造（contract）的面向?qū)ο笳Z言也可以實(shí)現(xiàn)同一目的。如果軟件開發(fā)的任務(wù)和限制沒有精確的、無歧義的模型，我們就無法顯著地進(jìn)行改善。模型應(yīng)該獨(dú)立于具體方法（只描述問題，而非解決方案）；模型應(yīng)該不僅包含定義和公理，而且還應(yīng)該包括描述所有系統(tǒng)和可行方法的定理——這恰恰是形式化模型經(jīng)常缺失的部分。

　　尋找內(nèi)核——所有方法之母

　　所有方法在被過度宣傳的差異之外，都有許多共同的屬性。而以理論作為基礎(chǔ)，我們將描述出任何有效的開發(fā)高質(zhì)量軟件的方法都應(yīng)該滿足的屬性。畢竟，它們都是用來開發(fā)軟件的，而且都承認(rèn)軟件開發(fā)中有一些東西總是需要。我們總是要寫代碼，用某種方式進(jìn)行測試，總是要考慮需求（無論要不要文檔），總是有backlog（無論顯式還是隱式），總是需要計劃（無論是寫在紙上，還是留在腦子里）。

　　我們需要找到軟件開發(fā)本質(zhì)的不能再簡化的內(nèi)核（Kernel）。例如，通過研究大約50種方法包括XP和Scrum，我們已經(jīng)找到了一個包含超過15個元素的內(nèi)核，其中的元素是我們總要做的事情或者總要生成的東西。

　　使用內(nèi)核描述各種有價值的方法

　　有了內(nèi)核之后，所有方法都可以進(jìn)行描述和比較。我們可以從所有廣泛使用和經(jīng)過驗證的方法或者過程中采集隱含的實(shí)踐，比如架構(gòu)、組件、迭代等等。有些實(shí)踐是重疊的，比如用例驅(qū)動開發(fā)和特性驅(qū)動開發(fā)。有些是互相補(bǔ)充的，比如用例驅(qū)動開發(fā)和按約定設(shè)計。

　　內(nèi)核清除了方法之間表面存在的差異，比如不同方法中只是稱呼不同的相同事物。比如，RUP所說的迭代在Scrum中稱為sprint，但是它們基本上說的是一回事。通過這種清理，可以明顯地看出不同方法之間真正的差異。

　　因為內(nèi)核對于任何具體的實(shí)踐都是中立的，我們可以簡單地分辨出不同實(shí)踐之間的實(shí)際區(qū)別，不是表面上的，而是深層次的。這將減少各種方法中包含的“宗教”成分。

　　行動起來！

　　本文是一篇行動呼吁書，我們希望它能夠被所有同意軟件業(yè)應(yīng)該進(jìn)入成熟階段的同仁所接納（當(dāng)然，還需要進(jìn)行適當(dāng)?shù)男抻啠?/p>

　　最重要的一步，可能是認(rèn)識到不同學(xué)派應(yīng)該求同存異。具體而言，要認(rèn)識到以下兩點(diǎn)。

　　敏捷與過程：這兩者之間的差異被夸大了。它們的目標(biāo)其實(shí)是一樣的：流暢地開發(fā)出優(yōu)秀的軟件。所有過程都需要敏捷，因為與其他領(lǐng)域相比，軟件中變化是規(guī)則，穩(wěn)定則是例外。與此同時，所有敏捷方法如果要應(yīng)用于關(guān)鍵的企業(yè)項目，還是需要過程，包括規(guī)格說明和設(shè)計。

　　形式化與非形式化：軟件開發(fā)人員必須認(rèn)識到，任何進(jìn)展都會多多少少包含一些形式化方法，沒有必要畏之如虎。所有工程都要依賴數(shù)學(xué)：我們能夠想象電氣或者機(jī)械工程師不愿意學(xué)習(xí)和運(yùn)用數(shù)學(xué)工具嗎？形式化方法當(dāng)然有其局限——沒人說它們能解決任何問題，但是形式化方法絕不是純理論，它們的價值早已經(jīng)被不斷證明了。無論我們是否能認(rèn)識到這一點(diǎn)，它們都已經(jīng)在一些領(lǐng)域（現(xiàn)代編程語言中的類型檢查就是一種證明形式，而硬件設(shè)計也越來越依靠數(shù)學(xué)工具）廣泛應(yīng)用了。隨著IT業(yè)向更專業(yè)的運(yùn)營方式發(fā)展，有選擇的數(shù)學(xué)工具的運(yùn)用將與日俱增。

　　僅僅通過忽略表面上的差異，并充分利用已有的概念，我們將能夠為業(yè)界提供曾經(jīng)只能從專家們那里得到的東西：科學(xué)上堅實(shí)、而且實(shí)用的方法和工具。

　　這就是我們的看法。我們是否像堂吉訶德那樣在挑戰(zhàn)風(fēng)車呢？還是有可能就此對現(xiàn)在開發(fā)方法中混亂的局面正本清源，開發(fā)出業(yè)界所需要的堅實(shí)基礎(chǔ)？有一點(diǎn)是肯定的：進(jìn)步只能來自許多人的通力合作。已經(jīng)有許多論壇在討論這些問題，請從我們的博客（http://ivarblog.com/， http://bertrandmeyer.com）開始。歡迎將你的想法告訴我們，幫助軟件工程學(xué)科進(jìn)入成熟階段。

it知識庫：軟件開發(fā)方法需要理論，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。