濟南軟件開(kāi)發(fā)—軟件開(kāi)發(fā)方法需要理論的支持

     對(duì)于正在尋找軟件開(kāi)發(fā)方法的人來說，問題不在于是否能(néng)找到答案，而是确定答案是否滿足要求。下面(miàn)來論述一下軟件開(kāi)發(fā)方法學(xué)必須經(jīng)曆深刻的變革。應該放棄當前依賴于新詞和政治式宣傳的狀況，轉向(xiàng)基于理論和實驗驗證的嚴肅的科學(xué)工作。
　　軟件方法學(xué)是一個特殊的領域。按原理它應該是基于科學(xué)的工程學(xué)科，但目前的實踐中它卻時而像時裝業，時而又像搞政治。
　　時裝業每年都(dōu)要有一種(zhǒng)新潮流，在匆忙跟風中，人們將(jiāng)好(hǎo)的和壞的一起(qǐ)抛棄。人們不是從自己的經(jīng)驗中學(xué)習，而是跟著(zhe)自認爲更好(hǎo)的走，因爲其他人都(dōu)說這(zhè)樣(yàng)更好(hǎo)。創新者們常常抱怨，大公司擁抱變化非常緩慢，但事(shì)實上并非如此，許多大公司非常渴望嘗試新事(shì)物。真正的問題在于，他們也會(huì)更快地放棄，還(hái)沒(méi)等認真用起(qǐ)來呢，在過(guò)程和工具上的不菲投入就(jiù)打水漂了。
　　在政治中，重點不是放在難題的切實解決，而是口号、宣傳和煽情。理念不是通過(guò)對(duì)利弊仔細的讨論來提出，而是像品牌那樣(yàng)進(jìn)行營銷，借助一些大師的一些金口玉言來傳播。每一種(zhǒng)方法都(dōu)試圖忽略自己的同類，如果不得不承認它們的存在，通常也會(huì)惡意貶低，這(zhè)弄得一線人員無所适從。
　　最終，很少有新思想能(néng)運用在大規模的項目裡(lǐ)，因此對(duì)大系統開(kāi)發(fā)中的質量、生産力和上市時間等等都(dōu)沒(méi)有産生什麼(me)影響。過(guò)去四十年中軟件開(kāi)發(fā)方法中出現的所有新概念裡(lǐ)，隻有少數大的創新——結構化編程、對(duì)象技術、設計模式和UML等對(duì)行業産生了真正的影響。
　　這(zhè)些都(dōu)是不成(chéng)熟的表現。我們的學(xué)科該長(cháng)大了。
　　席卷業界的最新一波浪潮是“敏捷”。敏捷方法的确做出了許多貢獻，并使我們再次注意到人在軟件工程中的中心地位。一些敏捷的經(jīng)驗很可能(néng)仍然會(huì)在未來的方法中繼續存在。與此同時，敏捷領域也爲上面(miàn)談到的現象提供了活例子。作爲一個重視人甚于過(guò)程和工具的運動，敏捷卻提出了許多被(bèi)宣傳爲“新的”過(guò)程和工具，而且沒(méi)有說清楚其中哪些是真正新的，哪些隻是已有概念的重述。很多一線人員很自然地就(jiù)被(bèi)弄暈了。先不說這(zhè)些“新”概念的價值如何，對(duì)它們的推廣方式就(jiù)頗爲引人注目：先是爲這(zhè)個方法精心編寫了一份基礎性文獻的—個宣言，更多的是第一人稱複數的情感訴求，而缺少事(shì)實依據。這(zhè)種(zhǒng)風格對(duì)于吸引眼球可能(néng)有效，但随著(zhe)概念日益成(chéng)熟，還(hái)是應該采用更傳統闡釋形式。
　　在工程和科學(xué)中，一種(zhǒng)新技術的提出者與任何人一樣(yàng)都(dōu)急于推廣自己的發(fā)明，但是也會(huì)很小心地确定應用這(zhè)項新技術在什麼(me)地方存在不足或者未經(jīng)證實。然而，很少有軟件方法學(xué)者會(huì)提供這(zhè)樣(yàng)的警示信息。太多人誇大了自己的方法與前人的差異。每一次變革（比如對(duì)象技術）中，有多少突破其實是已知概念的調整？逐漸改進(jìn)當然沒(méi)有錯，科學(xué)和工程中大量進(jìn)展都(dōu)是如此實現的。但是，將(jiāng)每一次改進(jìn)都(dōu)包裝成(chéng)革命，就(jiù)沒(méi)意思了。
　　我們目前軟件開(kāi)發(fā)的方法，無論是商業還(hái)是公司内部，新還(hái)是舊，需求已知還(hái)是不清，實際上都(dōu)隻是來自方法文獻中各種(zhǒng)元素的組合，加上一些特定于領域或者業務的擴展。基本的成(chéng)分是一個個實踐。
　　如果我們將(jiāng)這(zhè)些基本成(chéng)分從大雜燴中分離出來，大家就(jiù)可以建立自己所需的方法。這(zhè)種(zhǒng)方法是以模塊的方式設計的，能(néng)夠在不斷總結經(jīng)驗的基礎上快速演進(jìn)，響應我們快速變化的行業的需求。
　　經(jīng)濟壓力是當前的時代特征，與時裝業的跟風和政治宣傳一樣(yàng)都(dōu)不會(huì)完全消失。但是，所有關注軟件工程價值的方法學(xué)者都(dōu)理應爲學(xué)科找到存在的理由。
　　我們所缺乏的是作爲一門科學(xué)和工程學(xué)的基礎：理論及其驗證。我們應該采取以下步驟，將(jiāng)軟件方法學(xué)轉變爲一種(zhǒng)嚴謹的工作。
　　軟件開(kāi)發(fā)是一種(zhǒng)人的活動，但它也是由若幹明确定義的步驟組成(chéng)的，而且我們對(duì)這(zhè)些步驟之間關系已經(jīng)有了充分認識。至少，在有經(jīng)驗的從業人員腦中，對(duì)這(zhè)些概念的定義和理解都(dōu)是不言自明的。但這(zhè)還(hái)不夠，我們需要堅實的軟件開(kāi)發(fā)理論。形式化方法爲我們提供了進(jìn)行建模的正确工具，含有約定構造（contract）的面(miàn)向(xiàng)對(duì)象語言也可以實現同一目的。如果軟件開(kāi)發(fā)的任務和限制沒(méi)有精确的、無歧義的模型，我們就(jiù)無法顯著地進(jìn)行改善。模型應該獨立于具體方法（隻描述問題，而非解決方案）；模型應該不僅包含定義和公理，而且還(hái)應該包括描述所有系統和可行方法的定理——這(zhè)恰恰是形式化模型經(jīng)常缺失的部分。
　　所有方法在被(bèi)過(guò)度宣傳的差異之外，都(dōu)有許多共同的屬性。而以理論作爲基礎，我們將(jiāng)描述出任何有效的開(kāi)發(fā)高質量軟件的方法都(dōu)應該滿足的屬性。畢竟，它們都(dōu)是用來開(kāi)發(fā)軟件的，而且都(dōu)承認軟件開(kāi)發(fā)中有一些東西總是需要。我們總是要寫代碼，用某種(zhǒng)方式進(jìn)行測試，總是要考慮需求（無論要不要文檔），總是有backlog（無論顯式還(hái)是隐式），總是需要計劃。
我們需要找到軟件開(kāi)發(fā)本質的不能(néng)再簡化的内核。例如，通過(guò)研究大約50種(zhǒng)方法包括XP和Scrum，我們已經(jīng)找到了一個包含超過(guò)15個元素的内核，其中的元素是我們總要做的事(shì)情或者總要生成(chéng)的東西。
　　有了内核之後(hòu)，所有方法都(dōu)可以進(jìn)行描述和比較。我們可以從所有廣泛使用和經(jīng)過(guò)驗證的方法或者過(guò)程中采集隐含的實踐，比如架構、組件、叠代等等。有些實踐是重疊的，比如用例驅動開(kāi)發(fā)和特性驅動開(kāi)發(fā)。有些是互相補充的，比如用例驅動開(kāi)發(fā)和按約定設計。
内核清除了方法之間表面(miàn)存在的差異，比如不同方法中隻是稱呼不同的相同事(shì)物。比如，RUP所說的叠代在Scrum中稱爲sprint，但是它們基本上說的是一回事(shì)。通過(guò)這(zhè)種(zhǒng)清理，可以明顯地看出不同方法之間真正的差異。
因爲内核對(duì)于任何具體的實踐都(dōu)是中立的，我們可以簡單地分辨出不同實踐之間的實際區别，不是表面(miàn)上的，而是深層次的。這(zhè)將(jiāng)減少各種(zhǒng)方法中包含的“宗教”成(chéng)分。