1. 程式人生 > >極限開發與敏捷開發

極限開發與敏捷開發

一、簡介

2001年,為了解決許多公司的軟體團隊陷入不斷增長的過程泥潭,一批業界專家一起概括出了一些可以讓軟體開發團隊具有快速工作、響應變化能力的價值 觀和原則,他們稱自己為敏捷聯盟。敏捷開發過程的方法很多,主要有:SCRUM,Crystal,特徵驅動軟體開發(Feature Driven Development,簡稱FDD),自適應軟體開發(Adaptive Software Development,簡稱ASD),以及最重要的極限程式設計(eXtreme Programming,簡稱XP)。極限程式設計(XP)是於1998年由Smalltalk社群中的大師級人物Kent Beck首先倡導的。

二、極限程式設計

設計和程式設計都是人的活動。忘記這一點,將會失去一切。      

      — Bjarne Stroustrup      

極限程式設計(XP)是敏捷軟體開發中最著名的一個,它是由一系列簡單卻互相依賴的實踐組成。這些實踐結合在一起形成了一個勝於部分結合的整體。

極限程式設計 是一門針對業務和軟體開發的規則,它的作用在於將兩者的力量集中在共同的、可以達到的目標上。它是以符合客戶需要的軟體為目標而產生的一種方法論,XP使開發者能夠更有效的響應客戶的需求變化,哪怕是在軟體生命週期的後期。它強調,軟體開發是人與人合作進行的過程,因此成功的軟體開發過程應該充分利用人的優勢,而弱化人的缺點,突出了人在軟體開發過程中的作用。極端程式設計屬於輕量級的方法,認為文件、架構不如直接程式設計來的直接。XP實際上是一種經歷過很多實踐考驗的一種軟體開發的方法,它誕生了大概有5 年,它已經被成功的應用在許多大型的公司,如:Bayeris che Landesbank,Credit Swis s Life,DaimlerChrysler,First Union National Bank Ford Motor Company and UBS.XP 的成功得益於它對客戶滿意度的特別強調,XP 是以開發符合客戶需要的軟體為目標而產生的一種方法論,XP 使開發者能夠更有效的響應客戶的需求變化,哪怕在軟體生命週期的後期。同時,XP 也很強調團隊合作。團隊包括:專案經理,客戶,開發者。他們團結在一起來保證高質量的軟體。XP 其實是一種保證成功的團隊開發的簡單而有效的方法。XP 強調四種價值:交流,簡易,回饋,勇氣。XP 程式設計師之間緊密的相互交流,XP 程式設計師也和客戶緊密的交流。他們總是保持他們的設計簡單明瞭。專案一開始,XP 就強調通過對軟體的不斷測試來獲得反饋,程式設計師儘可能早的把軟體交給客戶,並實現客戶對軟體需求提出的變化,有了這些基礎,XP 程式設計師就可以自信的面對需求和軟體技術的變化。
XP 是與眾不同的,它有點象快步的舞蹈。XP 開發過程包括許多的小卡片,獨立的看,這些小卡片沒有什麼意義,但是當它們組合在一起,一幅完整的美麗的圖片就可以看見,XP方法有別於傳統軟體開發,它是軟體開發的一種新的重要的發展。它改變了我們開發程式的傳統思維方式。下面我們將介紹它帶給我們那些改變。
XP屬於輕量開發方法中較有影響的一種方法。輕量開發方法是相對於傳統的重量開發方法而言。簡單地理解,“量”的輕重是指用於軟體過程管理和控制的、除程式量以外的“文件量”的多少。XP等輕量開發方法認識到,在當前很多情況下,按傳統觀念建立的大量文件,一方面需要消耗大量開發資源,同時卻已失去幫助“預見、管理、決策和控制的依據”的作用。因此必須重新審視開發環節,去除臃腫累贅,輕裝上陣。

1、XP的核心思想
從長遠看,早期發現錯誤以及降低複雜度可以節約成本。極限程式設計強調我們將任務/系統細分為可以在較短週期解決的一個個子任務/模組,並且強調測試、程式碼質量和及早發現問題。通常,通過一個個短小的迭代週期,我們就可以獲得一個個階段性的進展,並且可以及時形成一個版本供使用者參考,以便及時對使用者可能的需求變更作出響應。

2、XP的十二種方法
      規劃策略(The Planning Game);
      結對程式設計(Pair programming)
      測試(Testing)
      重構(Refractoring)
      簡單設計(Simple Design)
      程式碼集體所有權(Collective Code Ownership)
      持續整合(Continuous Integration)
      現場客戶(On-site Customer)
      小型釋出(Small Release)
      每週40小時工作制(40-hour Week)
      編碼規範(Code Standards)
      系統隱喻(System Metaphor)

3、XP的四個核心價值
極限程式設計中有四個核心價值是我們在開發中必須注意的:溝通(Communication)、簡單(Simplicity)、反饋(Feedback)和勇氣(Courage)。
XP用“溝通、簡單、反饋和勇氣”來減輕開發壓力和包袱;無論是術語命名、專著敘述內容和方式、過程要求,都可以從中感受到輕鬆愉快和主動奮發的態度和氣氛。這是一種幫助理解和更容易激發人的潛力的手段。XP用自己的實踐,在一定範圍內成功地打破了軟體工程“必須重量”才能成功的傳統觀念。
XP精神可以啟發我們如何學習和對待快速變化、多樣的開發技術。成功學習XP的關鍵,是用“溝通、簡單、反饋和勇氣”的態度來對待XP;輕鬆愉快地來感受XP的實踐思想;自己認真實踐後,通過對真實反饋的分析,來決定XP對自己的價值;有勇氣接受它,或改進它。

4、XP 帶給我們的變化

通過軟體工程設計的簡單而優美的軟體並不比那些設計複雜而難以維護的軟體有價值。這是真的嗎?XP認為事實並非如此。

一個典型的專案花在人力上的金錢是花在硬體上的時間的20 倍,這意味著一個專案每年要花200 萬美元在程式設計師身上,而僅僅花10 萬美元在電腦裝置上。很多聰明的程式設計師說:“我們如此聰明,發現一種方法可以節省20%的硬體開銷”,然後他們使得源程式大而且難懂和難以維護,他們會說:“但是我們節省了20%或者2萬美元每年,很大的節省”。反之,如果我們寫我們的程式簡單而且容易擴充套件,我們將至少節省10%的人力開銷,一筆更大的節省,這是你客戶一定會注意到的一些事情。

另外一個對客戶來說很重要的問題就是程式的BUGS 。XP 不只是強調測試,而且要求正確的測試。測試必須是能自動進行的,以便為程式和客戶提供一個安全的環境。在編碼的所有階段,我們不斷增加測試用例。當找到 bug 時,我們就新增新的測試,一個緊密的安全網就這樣產生了。同一個BUG 不出現兩次,這些一定會引起使用者的注意。你的客戶必須注意的另外一件事情:XP 開發者擁抱需求變化。XP 使我們能夠接受需求的變化。

一般情況下,客戶只有在系統被開發完成以後能真正去體會它。XP 卻不一樣,它通過加強客戶的反饋來縮短開發的週期,同時獲得足夠的時間來改變功能和獲得使用者的認同。在XP 中,你的客戶應該明確的知道這一點。

XP開發過程的大多的革命是在軟體開發的方法上,程式碼質量的重要程度超出人們一般所認為的。僅僅因為我們的客戶不能明白我們的原始碼並不意味著我們可以不努力去管理程式碼的質量。

5、我們什麼時候用XP

XP方法的產生是因為難以管理的需求變化,從一開始你的客戶並不是很完全的知道他們要的系統是怎麼樣的,你可能面對的系統的功能一個月變化多次。在大多數軟體開發環境中不斷變化的需求是唯一的不變,這個時候應用XP 就可以取得別的方法不可能取得的成功。XP 方法的建立同時也是為了解決軟體開發專案中的風險問題。假如你的客戶在特定的時間內,需要一個相當難開發的系統,而且對於你的專案組來說,這個系統是一個新的挑戰(從來沒有做過),那風險就更大了,如果這個系統對於整個軟體行業來說都是新的挑戰,那麼它的風險就更大了,採用XP 將可以減少風險,增加成功的可能。

XP方法是為小團體開發建立的,在2-10 個人之間。假如你的團體恰好合適,你就不需要用其他的軟體工程方法了,就用XP ,但是要注意你不能將XP 方法應用於大團體的開發專案中。我們應該注意,在需求一慣呈動態變化或者高具有高風險的專案中,你就會發現XP 方法在小團體的開發中的作用要遠遠高於在大團體的開發。

XP方法需要一個擴充套件的開發團體,XP 團體不僅僅包括開發者,經理、客戶也是其中的一員,所有的工作一環扣一環,問問題,商討方法和日程,增加功能測試,這些問題的解決不僅僅涉及到軟體的開發者。

另一個需要是可測試性,你必須能增加自動的單元測試和功能測試,然而在你進行這個需求的時候,你會發現有許多的問題很難測試,這需要充分發揮你的測試的經驗和智慧,而且你有時還要改變你的設計以便它可以更容易的進行測試。記住:那兒有需求,那兒就應該有測試的方法。

在XP方法的好處的清單上,最後一條是生產力。在同樣的合作環境下,XP 專案都一致的表現出比使用其他方法高的多的生產力。但這從來不是XP 方法學的真正目標。XP 真實追求的目標是:在規定的時間生產出滿足客戶需要的軟體。假如對於你的開發來說,這是很重要的方面,你就可以選擇XP 了。

下面是極限程式設計的有效實踐:

  1. 完整團隊:XP專案的所有參與者(開發人員,客戶,測試人員)一起工作在一個開放的場所中,他們是同一個團隊的成員,這個場所的牆壁上隨意懸掛著大幅的,顯著的圖表以及其它一些顯示他們進度的東西。
  2. 計劃遊戲:計劃是持續的,循序漸進的,每兩週,開發人員就為下兩週估算候選特性的成本,而客戶則根據成本和商務價值來選擇要實現的特性。
  3. 客戶測試:作為選擇每個所期望的特性的一部分,客戶可以根據指令碼語言來定義出自動驗收測試來表明該特性可以工作。
  4. 簡單設計:團隊保持設計恰好和當前的系統功能相匹配,它通過了所有的測試,不包含任何重複,表達出了編寫者想表達的所有東西。並且包含儘可能少的程式碼。
  5. 結對程式設計:所有的產品軟體都是由兩個程式設計師,並排坐在一起在同一臺機器上構建的。
  6. 測試驅動開發:編寫單元測試是一個驗證行為,更是一個涉及行為。同樣,他是一種編寫文件的行為,編寫單元測試避免了相當數量的反饋迴圈,尤其是功能驗證方面的反饋迴圈。程式設計師以非常短的迴圈週期工作,他們先增加一個失敗的測試,然後使之通過。
  7. 改進設計:隨時利用重構方法改進已經腐化的程式碼,保持程式碼儘可能的乾淨,具有表達力。
  8. 可持續的速度:團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作,他們儲存精力,他們把專案看作是馬拉松長跑,而不是全速短跑,極限程式設計是一組簡單、具體的實踐,這些實踐結合在形成了一個敏捷開發過程,極限程式設計是一種優良的,通用的軟體開發方法,專案團隊可以拿來直接採用,也可以增加一些實踐,或者對其中的一些實踐進行修改後再採用。

三、敏捷開發

人與人之間的互動是複雜的,並且其效果從來都是難以預期的,但卻是工作中最重要的方面。

— Tom DeMacro和Timothy Lister

      
敏捷軟體開發宣言:

  • 個體和互動          勝過     過程和工具
  • 可以工作的軟體 勝過     面面俱到的文件
  • 客戶合作               勝過     合同談判
  • 響應變化               勝過     遵循計劃

雖然右項也有價值,但是我們認為左項具有更大的價值。

  • 我們最優先要做的是通過儘早的、持續的交付有價值的軟體來使客戶滿意。
  • 即使到了開發的後期,也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
  • 經常性地交付可以工作的軟體,交付的間隔可以從幾個星期到幾個月,交付的時間間隔越短越好。
  • 在整個專案開發期間,業務人員和開發人員必須天天都在一起工作。
  • 圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援,並且信任他們能夠完成工作。
  • 在團隊內部,最具有效果並富有效率的傳遞資訊的方法,就是面對面的交談。
  • 工作的軟體是首要的進度度量標準。
  • 敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持一個長期的、恆定的開發速度。
  • 不斷地關注優秀的技能和好的設計會增強敏捷能力。
  • 簡單是最根本的。
  • 最好的構架、需求和設計出於自組織團隊。
  • 每隔一定時間,團隊會在如何才能更有效地工作方面進行反省,然後相應地對自己的行為進行調整。

當軟體開發需求的變化而變化時,軟體設計會出現壞味道,當軟體中出現下面任何一種氣味時,表明軟體正在腐化。

  • 僵化性: 很難對系統進行改動,因為每個改動都會迫使許多對系統其他部分的其它改動。
  • 脆弱性: 對系統的改動會導致系統中和改動的地方在概念上無關的許多地方出現問題。
  • 牢固性: 很難解開系統的糾結,使之成為一些可在其他系統中重用的元件。
  • 粘滯性: 做正確的事情比做錯誤的事情要困難。
  • 不必要的複雜性: 設計中包含有不具任何直接好處的基礎結構。
  • 不必要的重複性: 設計中包含有重複的結構,而該重複的結構本可以使用單一的抽象進行統一。
  • 晦澀性: 很難閱讀、理解。沒有很好地表現出意圖。

敏捷團隊依靠變化來獲取活力。團隊幾乎不進行預先設計,因此,不需要一個成熟的初始設計。他們更願意保持設計儘可能的乾淨、簡單,並使用許多單元測試和驗 收測試作為支援。這保持了設計的靈活性、易於理解性。團隊利用這種靈活性,持續地改進設計,以便於每次迭代結束生成的系統都具有最適合於那次迭代中需求的 設計。 為了改變上面軟體設計中的腐化味,敏捷開發採取了以下面向物件的設計原則來加以避免,這些原則如下:

  • 單一職責原則(SRP)
    就一個類而言,應該僅有一個引起它變化的原因。
  • 開放-封閉原則(OCP)
    軟體實體應該是可以擴充套件的,但是不可修改。
  • Liskov替換原則(LSP)
    子型別必須能夠替換掉它們的基型別。
  • 依賴倒置原則(DIP)
    抽象不應該依賴於細節。細節應該依賴於抽象。
  • 介面隔離原則(ISP)
    不應該強迫客戶依賴於它們不用的方法。介面屬於客戶,不屬於它所在的類層次結構。
  • 重用釋出等價原則(REP)
    重用的粒度就是釋出的粒度。
  • 共同封閉原則(CCP)
    包中的所有類對於同一類性質的變化應該是共同封閉的。一個變化若對一個包產生影響,則將對該包中的所有類產生影響,而對於其他的包不造成任何影響。
  • 共同重用原則(CRP)
    一個包中的所有類應該是共同重用的。如果重用了包中的一個類,那麼就要重用包中的所有類。
  • 無環依賴原則(ADP)
    在包的依賴關係圖中不允許存在環。
  • 穩定依賴原則(SDP)
    朝著穩定的方向進行依賴。
  • 穩定抽象原則(SAP)
    包的抽象程度應該和其穩定程度一致。

上述中的包的概念是:包可以用作包容一組類的容器,通過把類組織成包,我們可以在更高層次的抽象上來理解設計,我們也可以通過包來管理軟體的開發和釋出。目的就是根據一些原則對應用程式中的類進行劃分,然後把那些劃分後的類分配到包中。

下面舉一個簡單的設計問題方面的模式與原則應用的示例:

問題:
選擇設計執行在簡易檯燈中的軟體,檯燈由一個開關和一盞燈組成。你可以詢問開關開著還是關著,也可以讓燈開啟或關閉。

解決方案一:
下面圖1是一種最簡單的解決方案,Switch物件可以輪詢真實開關的狀態,並且可以傳送相應的turnOn和turnOff訊息給Light。

解決方案二:
上面這個設計違反了兩個設計原則:依賴倒置原則(DIP)和開放封閉原則(OCP),DIP原則告訴我們要優先依賴於抽象類,而Switch依賴了具 體類Light,對OCP的違反是在任何需要Switch的地方都要帶上Light,這樣就不能容易擴充套件Switch去管理除Light外的其他物件。為 瞭解決這個方案,可以採用ABSTRACT       SERVER模式,在Switch和Light之間引入一個介面,這樣就使得Switch能夠控制任何實現了這個介面的東西,這也就滿足了DIP和OCP 原則。如下面圖2所示:

解決方案三:
上面圖2所示解決方案,違返了單一職責原則(SRP),它把Switch和Light繫結在一起,而它們可能會因為不同的原因而改變。這種問題可以採用ADAPTER模式來解決,介面卡從Switchable       派生並委託給Light,問題就被優美的解決了,現在,Switch就可以控制任何能夠被開啟或者關閉的物件。但是這也需要會出時間和空間上的代價來換取。如下面圖3所示:

敏捷設計是一個過程,不是一個事件。它是一個持續的應用原則、模式以及實踐來改進軟體的結構和可讀性的過程。它致力於保持系統設計在任何時間都儘可能得簡單、乾淨和富有表現力。