Ivar Jacobson：我們為什麼需要軟體工程理論

      由於Sunny最近主要從事一些軟體工程理論及應用方面的研究，接下來將陸續轉載和翻譯幾篇有關軟體工程理論方面的文章，希望從事軟體工程研究和開發的童鞋們能從中受益！

      本文轉自http://www.programmer.com.cn/4310/，來自《程式設計師》雜誌10年11期，特此說明！

      Semat計劃於2009年12月由軟體工程三位大師（合稱“Troika”）Ivar Jacobson（UML、RUP、元件和元件架構、用例等技術之父），Bertrand Meyer（Eiffel和按約定設計之父）和Richard Soley（OMG主席）正式發起，倡導以堅實的理論、已經證明的原理和最佳實踐為基礎，重新發現軟體工程的本質。Jacobson等撰寫了三篇文章詳細闡述Semat思想，本刊（《程式設計師》）將陸續刊載，本文是其中第二篇。

      幾個星期前，Bertrand和我發表了一篇簡短的文章，簡單介紹了我們認為軟體方法需要理論指導的原因。這篇文章中，Ian Spence和我將在上一篇文章的基礎上擴充套件開來，更詳細地討論為什麼這樣一個基礎理論的建立能夠令我們受益。
 
      我們最大的挑戰：理解如何構造優秀的軟體
 
      我們真的知道如何開發優秀的軟體嗎？對大部分人來說，很顯然是這樣的。但是我們是否知道如何交流，以及不斷改進我們開發軟體的方式？我們真的瞭解交流和分享知識的最佳方式麼？就我們在之前文章中的所見而言，顯然沒有！
 
      我們站在流沙上還是巨人的肩膀上？
 
      你是否曾經花時間研究新的方法或實踐，最後卻發現它只是你已經見過無數次的某種思想的改頭換面？
 
      你是否曾經煩惱過，每個軟體開發新思路似乎都以過去的一切為代價，都與過去的一切水火不容？
 
      在你看來，追逐最新的軟體開發趨勢是否已經變得比生產優秀的軟體更重要？
 
      你是否注意到，急著要取得進展的人們似乎丟棄了好的部分而留下壞的？他們沒有從自己的經驗中學習，在自己優秀的工作上更進一步，而選擇將一切棄之不顧，重新開始他們認定的新事物。他們好像沒有什麼牢固的知識好依靠。
 
      這種行為可以從很多地方看出來，很多團隊草率地丟棄昂貴的過程和工具的投資，甚至在嘗試它們之前。每個專案都採用新方法。每次工作發生變化，在手頭真正的工作取得進展前，他們必須學習新方法。這是沒有效率的，人們不能從經驗中學習，因為他們永遠從頭開始。底線是，沒有什麼新事物能夠被適當地固定下來——即使經過幾種“現代”軟體開發趨勢，最流行的軟體開發方法仍然是規範型的瀑布開發或自由hacking。作為一個行業，我們沒有什麼真正可以堅守的東西，而且一切似乎沒有什麼變化。
 
      但現在我們能肯定敏捷會解決所有問題嗎？
 
      最新橫掃行業的趨勢是“敏捷”。現在，我們可以很明確地說，“敏捷”運動對軟體產業做出了非常積極的 [1] 貢獻。它提醒我們，軟體開發中，人是第一位的，也是最重要的。事實上，這不是什麼新觀念，但這是重要的，而且這一點似乎被以前更加技術導向的趨勢所忽視，比如說物件導向和Java程式設計。通過展現一系列優點，敏捷宣言創造了某種強健和適應力強的東西，可以抵擋下一次趨勢帶來的變革風浪。[2]許多聲稱支援敏捷哲學的敏捷方法，卻沒能做到這一點，這是非常讓人遺憾的。對一項將人的價值放在過程和工具之上的運動來說，這確實帶給了我們很多“新”的過程和工具。其中的大部分已經顯示出效率，通過將團隊帶回到之前完成的開發軟體工作。但在重新聚焦到這上面之前，許多人已經迷失或迷茫，因為將新術語引入舊事物後，讓人覺得這一切似乎是全新的。這個對舊思想的不斷重新包裝和品牌重樹讓軟體開發團隊的工作方式劇烈搖擺。對他們的工作和產品任意命名，而不是讓人們遠離浪費時間的工作，將精力重新聚焦在對高質量軟體的開發上。
 
      即使有些方法能夠像敏捷哲學一樣正確、有益，但相關的資訊可能會在搖擺和炒作中丟失。我們已經開始看到對敏捷的反彈，我們擔心的是利益將會丟失，當早期使用者投入下一個趨勢，而晚期大眾則重新主張自己的權利，拒絕採納這些顯然不再流行的東西。
 
      有可能會發生的事情是，我們增加更多時髦的詞彙和相互衝突的名詞，最終為這一切喧囂所累！
 
      應對挑戰：發展基本理論，描述軟體工程究竟是什麼
 
      很顯然，我們需要停止對流行和永遠令人失望的簡單答案的追逐，同時不能阻礙創新和新想法。為了做到這一點，人們需要停止對舊思想不斷重新包裝和品牌重樹。相反，他們應側重於幫助人們瞭解如何建立優秀的軟體。但我們如何才能重點推動這一變化？我們認為，這個理論就在眼前——我們要做的只是抓住它。首先，我們應該從所有流行的方法、過程和實踐開始，並從中提煉出軟體工程的“真理”。然後，我們可以描述和捕捉一個最小集合的基本概念，以最小獨立過程的形式——我們將這個本質物的最小集合稱之為核心。
 
      然後以這個核心為出發點，我們可以分析現有的過程和方法，並確定它們所包含的實踐。從核心開始，我們可以找到一種描述實踐的方式，使它們能夠進行比較和結合。
 
      現在所說的這種創造理論的方法本身並不是理論。這是我們已經做過的事情。通過研究一些方法，包括XP、Scrum和統一過程，我們的團隊已經確定了20多個核心元素，我們總是做的事情或產生的東西。從表面上看，在這些被研究的方法和我們的工作方式中，有可能會出現很大差異；但在實質上，它們有相同的DNA。舉例來說，你可以捕捉功能或用例或使用者故事的條件，你可以在沒有生命週期與統一過程的生命週期，甚至瀑布生命週期（就像有些人仍然在堅持的那樣）的情況下使用這些條件。這些方法肯定有一個共同基礎，能夠以小的簡單的核心要素集的形式被捕獲。
 
      現在，還不能冒失地聲稱，我們的核心提供了必要的理論。需要有比我們更多、更大的頭腦來做到這一點。但是，我們會將它作為一項證據，證明它的能力和我們需要的理論就近在眼前。
 
      但理論會帶來什麼影響呢？
 
      它不僅會影響方法論、流程愛好者和學者，而且將會有利於軟體開發涉及的每一個人。但是，它究竟會帶來什麼影響呢？
 
      軟體行業從中得到什麼？
 
      許多大公司都有自己的方法或過程，也就是一系列標準方法，搭配自己對更具體業務的想法。這些過程通常要用一本厚書或網站來介紹，大量資金被投入到歸檔工作中。有時，人們被訓練使用這些過程，有時只是被簡單告知它們在哪兒。在現實中，過程常常被忽視；僅有的被實際使用的部分是，組織中形成了“口頭傳統”的那些。這被解釋成重新發現的自然法則：人們不看過程的書籍。新的思路引入到組織中，舊過程退出流行，而有關它們的書成為擺設。
 
      在某些大公司甚至會出現多個過程。例如，大型系統整合商可能有十個或二十個不同的過程。有時它們很相似，但相似性背後隱藏著差異。
 
      如果貴公司採用這種實踐觀，你就不需要因為一些新的性感的東西正成為流行，而拋棄整個工作方式。相反，你只需要對現有的工作方式進行改進，一次改進一個實踐。你甚至可以採取那些被其他公司使用的實踐，而不用丟掉似乎運作良好的現有實踐。作為開始，你需要將現在的工作方式看作一個實踐集合。然後尋找你的痛點，然後修補目前的工作方式，通過刪除沒用的實踐，代之以解決這些薄弱環節的實踐。一旦你理解了核心和它的使用，就很容易做到這一點。在具有多種不同工作方式的大型組織，你可以使用此方法先後改進每個工作方式，而不必強迫大家使用相同的方法或過程。
 
      這種做法將使新實踐更容易被採納，而無須改變其他實踐。想象一下，幾年前，你已經引入了核心，並描述你的實踐。然後，你將能夠輕鬆引入Scrum，通過用Scrum取代專案管理中現有的實踐，而無須對其他實踐進行任何重大修改。展望未來，Scrum將很有可能被新的實踐代替，你將能夠很容易地做到這一點了。
 
      學術和教育界從中得到什麼？
 
      如果我們的技術學院或大學教授學生軟體工程基礎知識，然後訓練學生在一系列良好的實踐中使用該基礎，那將是非常棒的。教育將會更合乎邏輯，因為它著重以獨特的想法，而不是特定的思想，來形成每個方法、過程或方法論。我相信學生們會喜歡的。這裡也為相關研究留下了很多空間。記住Kurt Lewin的話：“沒有什麼比一個好的理論更實用了。”一個好的理論使得學習和開發你的知識更容易，而不會帶來過分的崇拜。這將是聰明的。大多數大學教授們在學術生涯中，從來沒有真正的機會來實踐大規模的軟體開發。但是他們仍然不得不教授軟體工程，這當然是不容易或者只是依葫蘆畫瓢。他們只能這樣做，因為這門課在課程表上，而不是因為他們確實有什麼可教的。他們沒有傳授理論，只是一套想法或一個特定的方法。當被問及此事時，一名成功的電腦科學家、教授軟體工程課程的教授說：“令人驚訝的是，學生們喜歡沐浴在我們交給他們的爛泥塘裡”。我知道這麼說並不嚴肅，但是可以肯定這位老師並不為他做的事情而感到自豪。
 
      一個理論，將從根本上改變這種局面。學生將學習軟體的基礎知識。他們將得到一種語言，來溝通軟體過程、實踐、模式，等等。可以想象，他們將會得到一種以核心為語法的語言和描述過程構成成分的時間的語言結構。這樣的語言需要是可執行的，這樣實踐才會變得生動。我說這些是為了表明這些實踐不僅是規範，而且也可執行。當一個專案進行時，這些實踐將開始執行，而且活動例項、工作產物，例項、技能角色將被真實物創造和填充。這些方面似乎能與實踐模式很好地吻合，有非常有趣的語義規則需要確定和定義。向學生開啟了一個全新的世界，可以幫助他們瞭解軟體工程的基本原理。更不用說，為對實踐和理論感興趣的研究人員開啟了一個全新的世界。
 
      方法論從中得到什麼？
 
      回顧自己1987年後的職業生涯，許多人建議我寫一本有關方法論的書。當時Objectory有一些新的想法，比如說用例、用例驅動的開發（這是一個測試驅動設計、合作、序列圖、元件和基於元件的開發）。其餘的大部分內容都沒什麼特別的。實施、單元測試、系統測試、效能測試、配置、規劃都是相當傳統的。當然，我有整個生命週期的經驗，但我不是所有事情的世界級專家。然而，為了寫書，我不得不包含整個生命週期的內容，即使其中很多不是我的專長。隨著我們尋找的新理論，沒有任何必要再說明不包含創新的內容。你不需要寫一本書來發布新想法，然後把軟體開發團隊需要做的一切都放進去，而只需要描述你的新實踐或新模式，也許第二天你就能向全世界釋出了。全世界的任何好點子都可以貢獻出來並獲得成功。
 
      軟體開發團隊從中得到什麼？
 
      終於，軟體團隊將能夠擺脫亦步亦趨地追隨潮流所造成的無休止的搖擺，成為嚴格意義上的軟體工程團隊。團隊在堅實的基礎上通過優秀的軟體開發實踐建設和擴充套件知識。這個基礎不會頻繁變化，不會強迫你一遍又一遍學習同樣的事情。它可以讓你通過自己的總結，而不是出席的課程來展示專業。它可以讓你輕鬆和無縫地引進新思路和新隊友，而不會造成效能驟降或精力浪費。團隊最終能夠不斷改進和適應他們的工作方式，迎接他們每天面對的挑戰。他們將能夠開發自己的知識和技能，以一種能夠讓他們順利地和來自不同背景、團隊和組織的其他人合作的方式，而不必一遍又一遍地重複學習同樣的事情了。
 
      最後的話
 
      我們對軟體工程的瞭解缺乏一個基本理論。因此，我們不斷用略有不同的詞再造舊方法，掩蓋了真正的創新，同時讓拋棄舊的不好的部分，利用新的好的部分變得困難。該理論將幫助我們大大改進軟體工程教育。這將幫助我們在面對身邊湧現的新想法時的反應不那麼天真。最後，它也將幫助我們更快地接受新的思想。這一理論的真正受益者將是軟體行業，這一點已經在許多公司得到證明。我們將能夠方便地教育我們的人員，讓他們加快速度；改進我們生產產品的方式；系統地重新設計（比重構程度更強）我們的產品；不斷改進我們的工作方式。其結果將是更好的軟體、更快的速度和大幅降低的成本。正如上面提到的，我們需要齊心協力才能做到這一點。從Scott Ambler最近的一篇文章“理論需要戰略”中可以看到這種勢頭已經開始，但仍有許多工作要做。
 
      我們已經證明它的有效性，但我們仍然要做許多工作才能建立一個公認的標準，必須在一組專家和權威之間建立共識才能完成這點。我們期待著與這些專家的合作。
 
      要了解更多參與的方式 ，請訪問www.ivarblog.com 或者在部落格“軟體工程需要一個理論”上給我們留言或者發電子郵件到a_theory@ivarjacobson.com。
 
      [1] 如果你已經在世界各地的會議上看到我們最近的發言，你應該瞭解，我們是敏捷的狂熱粉絲，是敏捷宣言的支持者。
      [2] 新的趨勢一定要跟隨敏捷趨勢，就像黑夜要跟隨白天一樣。

【作者：劉偉 http://blog.csdn.net/lovelion】