軟體開發之極限編程(極限開發) eXtreme Programming, XP


淺談 eXtreme Programming, XP (極限開發/編程)

eXtreme Programming, XP 極限開發最早由 Kent Beck, Ward Cunnungham 與 Ron Jeffries 所提出,這樣的方法首次在 C3 (Chrysler Comprehensive Compensation System) 克萊斯勒綜合報酬系統的開發上使用,這個專案的負責人就是 Kent Beck。雖然 C3 這個專案並沒有獲得最後的成功,但是他們所提出的方法卻一直活躍在軟體開發的領域中。

XP 極限開發可以說是敏捷開發 (Agile Software Development) 中最受歡迎的一項手法。如果我們敏捷開發形容為絕世武功的心法,那麼 XP 就是練武的招式,這樣的概念也可以套用在CMMI(心法)這樣的軟體哲學上,更確切的說 XP 是一種軟體開發模式

CMMI 適合在需求發展完整的軟體開發環境下執行,而 Agile 比較適合低成本與需求發展薄弱的環境 (像是台灣這樣的環境,客戶常常要求改東改西),雖兩者間許多概念背道而馳,但目的卻是一致的,就是想把事情做好!!

以目前的經驗來看,我實在沒能見過照著合約精神來完成開發的專案,同常為了要結案總有些拉扯,因此這樣的 XP 手法更符合多數開發者的需求。多說無益,親自體會比較重要。

XP 說實在蠻抽象的,就像是高喊民主自由的意識與主義,這樣的軟體開發哲學常常說了沒人懂,懂的人卻說不清楚。要導入這樣的開發理念,潛移默化會是比較好的方式,用體會來傳遞真理!?

XP Activities, 價值與核心概念介紹

XP 要傳遞的教義似乎有點抽象,可不是一本可蘭經或聖經就能夠表達,個人也不是體會很深,僅能帶給大家思考的動力。

首先先介紹 XP 定義的軟體開發的四種 Activities (基本行為)

  • Coding
    程式編碼,軟體開發的基本產出就是程式碼,而程式碼也是唯一重要的。這樣的定義似乎說明文件的地位是很低的,實際上我認為這是一種資訊隱藏技術,因為好的程式碼就是文件。
  • Testing
    軟體測試是非常重要的,如果沒有測試程式測過的程式碼,那就等於沒有程式碼。我想這是目前最缺乏的有效制度之一。
  • Listening
    頃聽客戶的實際需求,了解業務邏輯 (Business Logic) 需求背後的故事,持續地在程式設計師與客戶間進行溝通。我認為主要可以強化需求發展與需求變更。
  • Designing
    系統設計,你必須在系統設計上花心思,就算只把上述的工作做好,沒有好的系統設計,失敗將會是這個系統的命運。經過分析與設計的系統,子系統之間不會存在過多的相依性,我想這也是我們積極朝向的目標。

XP Values, 價值介紹

了解 XP 定義的軟體開發行為後,接這說明 XP 所帶來的 Values (價值)。

  • Communication (溝通)

傳統的系統開法手法常需要定義許多需求規格文件 (所謂的需求規格書),但 XP 倡導程式設計師與需求提供者應該常常溝通 (口頭開會最好),透過簡單的文件與設計進行溝通,並且即時回饋。

  • Simplicity (簡單就是美!?)

XP 鼓勵我們用簡單的方式完成工作,並且鼓勵不斷重構你的系統 (當然是在有完整單元測試的條件下)。我們將系統設計為簡單且容易理解,僅把今天的需求進行實作,而不要花時間去實做未來的需求,因為未來含有太多的變化風險。

XP Say : One is the commandment to always design and code for today and not for tomorrow.

sj Say : 今日事今日畢,明日事今不可畢!! (早點下班好....... ^^)

  • Feedback (反饋機制)

Feedback from the system (來自系統的反饋)
透過單元測試,系同將能夠自動告訴你,當你修改程式碼後發生了甚麼事?

Feedback from the customer (來自客戶的反饋)
透過功能性測試讓客戶了解系統的開發進度,同常2, 3個禮拜進行一次評估 (類似專案管理中的專案會議)。

Feedback from the team (來自團隊的反饋)
來自客戶的新需求透過開發小組的討論後,即可評估出新需求所需要的工作時間,並且回饋給客戶。

  • Courage (勇氣)

勇氣,這是我最欣 賞的一項作風,也是優異的系統能夠付予的優點。什麼是勇氣呢?我認為勇氣就是信任,你必須信任這一套機制而不會讓你在改寫程式碼後遭到客 戶追殺,你必須勇敢的 Refactoring (重構) 你的系統,而隨時可以用更好的設計來改寫你的系統。也呼應上述提到的 Simplicity,避免程式設計師掉入系統設計架構的迷失。更確切的說,假設你今天為了給一個功能,一直思考這樣改可能會影響到其他功 能,那樣改又覺得程式碼很骯髒,想了半天卻還在這樣處理過程中徘徊,又想起當初根本不應該這樣設計系統,如果當初將系統設計成另一種優異的架構,我現在就 不會這麼煩惱了。如果你有這種想法,那提起勇氣 Refactoring (重構)吧!Refactoring 重構並不是 Reworking 重工,重構將能夠改善與提升你的系統品質(如果設計正確的話.......-_-)。

sj : 相信自己,勇敢的改寫你的系統吧!(改壞了別怪我.......)

  • Respect (尊重)

這個項目是 eXtreme Programming 第二版才提出的項目,其中談到程式設計師的尊重與自重。XP 雖然倡導程式是團隊的,歡迎任何成員進行修改,但程式設計師應該為自己 commit 到版本控制系統中的程式碼負責,不應該 commit 會造成測試失敗的程式碼。

我個人倒是覺得在開發階段造成測試案例失敗是正常的,但是利用自動化的系統反饋機制 (Feedback from the system) 來掌控缺失也是一個好方法,不然因為硬碟壞掉又沒有 commit 造成的煩惱而吐血可就得不償失了,因此開發階段多多 Commit 吧。

XP Principles, 原則要領

  • Feedback 快速反饋

    在如此的開發環境下,對於需求所進行的程式碼修改,須能夠透過單元測試快速地反饋,所謂的反饋就是這樣的程式變更對系統會造成什麼樣的影響。當然反饋的過程中為了達到快速,而採用自動化的測試機制是必要的,因此在實做的過程中會導入 Continuous Integration (持續整合) 來輔助進行。
  • Assuming simplicity 極簡風格

    在這個原則中倡導每個需求都用最簡單的方式完成,而不需要考慮未來的擴充性。但是我認為這是不容易達成的,因為我們在撰寫程式碼的同時都會很直覺性的思考設計的問題,好的設計可以獲得更容易維護的系統是不變的道理。
  • Embracing change 包容變化

    所謂的包容變化指的是對於客戶需求變更我們應該接受,但當然在成本不得提升或另行報價的情況來看會比較實際,總不能需求無限創意無限。不然這樣的話 RD 將會加班無限,生命有限!

XP Practices, 實踐要領

上述提了這麼多抽象裡面,總該講些實際應用的手法吧?畢竟只有心法是不夠的,諸如此類的軟體工程總要 "說的一套,做的一套" 。所謂說的一套是指概念,做的一套是指做法,就像很多公司花大錢請  CMMI 導入顧問來指導實際做法,其目的通常是為了取得那張紙。

XP 說明了實踐的4項範圍,其中包含了12項作業,主架構有點類似 CMMI 的做法,我們就來繼續介紹吧,至少這邊的內容比起上面算是最實際的,也是花大錢請來的顧問在指導的方針。

1. Fine scale feedback

  • Pair programming 結隊程式設計

這個翻譯實在 很.......阿六仔,其實就是兩個人一起寫code啦。通常公司聽到這點就怕了,原本一個人做的事現在要兩個人做,大多出來的成本誰負 責!? 其實這個概念很有趣,XP 相信兩個人寫出來的 Code 會相當完美,且品質很高,通常可以一個寫程式一個負責監督(笑他或電他),無形中就在測試了。而兩個人的角色也可以互換,甚至 Team 中的成員輪流替換。這樣的概念其實有很多好處,也可以讓大家都知道程式的細節,避免開發人員流失對專案造成過大的風險。

甲工程師 (拼命寫程式)

乙工程師笑他:你這樣寫不好,你應該這樣寫比較聰明。

上述的過程就是測試Code Review

  • Test-driven development 測試驅動開發

這個好啊,但是很 難做。第一次有人叫我這樣寫程式的時候,我心想 "我程式都寫不完了你還叫我寫測試!!我寫測試的時間比我寫程式還久!!莊孝維......." ,但是現在看到別人程式有問題自己都不知道的時候就可以問他:你都沒有測試嗎?他就會回答:我那時候是好的啊,不知道改到什麼,也不知道什麼時候功能不運 作了。這樣的故事告訴我們:羅馬不是一天造成的。但是講到寫測試的痛苦,實在一言難盡。要推行 TDD 是很不容易的,首先要建立完善的測試環境,還要熟悉一套好用的測試框架,最重要的一點:你要能夠透過測試帶給程式設計師愉快的心情!(我稱為反饋的喜悅,或者失敗反饋的恥辱)

要怎麼實行,透過持續整合的便利性是最好的途徑,先想辦法讓你的團隊成員慢慢體會測試吧,拿著棍子鞭打是沒用的,測是必須發自內心撰寫出來(我也還在努力中.......-_-)。

兩句測試殺人口訣:

A. 沒有測試程式的程式不是程式

B. 不寫測試不寫程式

  • Whole team 全隊

指的是需要客戶與開發團隊一起共同進行開發 (敏捷開發也提到了這項要素),這個也是很多情況下無法實踐的項目,客戶通常只會在開會的時候電你。

  • Planning game 策劃遊戲

策劃遊戲主要分成 兩個部分,Release Planning (發佈計畫) 與 Iteration Planning (反覆計畫)。這項工作其實骨子裡就是 RD, Requirement Development (CMMI的最愛!?) 需求發展,XP 所提到的 Planning Game 相當複雜,但有助於專案管理的進行,為什麼會這樣說呢?因為在這個工作完成後會產生許多工作項目(像是WBS工作包),在 XP 中稱為 Story,然而在傳統的 SA/SD 終究是交給 Use-Case 來扮演的角色。我只能大致以外行的角色介紹一下:

Release Planning (發佈計畫)

  • Exploration phase (探索階段)
    • Write a Story : 設計與撰寫情境,比如登入系統這樣的功能。
    • Estimate a Story : 使用您豐富的經驗估計這個 Story 需要多少時間才可以完成。
    • Split a Story : 如果某些 Stroy 工時過長,那麼請切割它吧。

 

  • Commitment phase (承諾階段)
    • Sort by Value : 將每一個 Story 進行權重分配 (做的事與CMMI的規格需求差不多),可分為 Critical, Significant Business Value, Nice to have 三項 (CMMI可以分的更細)。
    • Sort by Risk : 就是專案管理的風險定性分析囉,XP 期望我們對 Story 進行 Completeness, Volatility, Complexity 三項以 0-2 的數字來設定,最後再計算風險索引 (專案管理人員一定不陌生)。
    • Set Velocity : 決定用什麼樣的速度來開發。
    • Choose scope : 講好下一次 Release 要完成哪些 Story。

    這裡要做的事情其實就是將 Story 進行量化。

  • Steering phase (監督階段)

    對我來說就是專案執行與控制,當初估算的工期可能有出入,或者你的客戶需求每日一變,這些都是可以接受的 (如果不虧錢!!),好好的監督吧。我認為這的階段的重點就是:掌握好軟體開發節奏

Iteration Planning (反覆計畫)

  • Exploration phase (探索階段)
    1. Translate the requirement to tasks : 簡單的說就是派工
    2. Combine/Split task : 處理可能合併或切割的任務
    3. Estimate task : 預測任務的處理時間
  • Commitment phase (承諾階段)
    1. A programmer accepts a task : 程式設計師來接任務
    2. Programmer estimates the task : 既然要接也要聲明交付時間
    3. Set load factor : 設定負載係數,有點像是實際工時 (我覺得沒必要)
    4. Balancing : 就是專案管理中的資源調配
  • Steering phase (監督階段)
    1. Get a task card : 取得工作卡
    2. Find a Partner : 尋找你的另一半 (Pair programming)
    3. Design the task : 與你的伙伴一同設計功能
    4. Write unit test : 撰寫單元測試
    5. Write code : 寫code
    6. Run test : 執行測試
    7. Refactor : 改善你的程式碼
    8. Run Functional test : 執行功能測試 (通常交由QA來執行)

策劃遊戲介紹完了,果然複雜吧,但是這邊的內容也算是包含了許多 XP 的重要概念。

2. Continuous process

  • Continuous integration

持續整合算是結合上述許多 XP 理念的重要實做,目的在於隨時 (當程式Commit) 進行整合測試,提早發現問題。對於持續整合的詳細介紹,可參考另一篇文章【持續整合介紹】。

  • Design improvement

因為 XP 所提倡的 "今日事僅今日畢" 開發做法,如此常常會造成一些現象,例如系統很多不同的 Function 在做同一件事,或者含有很多骯髒的程式碼,甚至缺乏設計的演算法。當你碰到這樣的情況時就開始 Refactor (重構) 你的系統吧。

  • Small releases

小規模的 Release 你的系統,在一定的短週期內將已經可以運作的功能進行 Release,如此能夠有效獲得客戶的信任,客戶會感覺開發團隊一直都有產出。

3. Shared understanding

  • Coding standard

建立良好的程式撰寫標準,這樣的好處為程式碼整齊一致,當別人想要修改的你程式碼也能輕易上手。除了訂定程式撰寫標準外,也盡力維持一貫設計風格與 Design Pattern。

當你在訂定程式撰寫規範時,請務必參考程式語言的慣例,可別自行創造撰寫規範。

  • Collective code ownership

程式碼是大家共有的,每一位程式設計師都要對所有程式負責,當然也可以任意修改程式,儘管這行程式不是你自己寫的。Pair programming 是有助於實現 Collective code ownership 的一項途徑,同時實踐效果更好。

  • Simple design

採用最簡單容易明白的設計,當你撰寫一段程式碼時,你必須承認這是一段容易理解的程式碼,假設不是,那麼請 Refactor 吧。

  • System metaphor

你的系統會說話!這邊的意思就是利用程式語言的特型,讓任何人可以從你的程式碼看出個所以然,更甚者能夠舉一反三。要實踐這樣的理念可以透過一些小技巧,比如類別名稱的命名、函式名稱的定義、變數名稱的定義等等。

4. Programmer welfare

  • Sustainable pace

這邊提到軟體設計師的福利,真是太人性化了,其中提倡每一周工作時數不得超過40小時,採用緩慢的步伐開發系統,可以獲得品質更高與更有創新價值的程式碼。這些前提必須在有良好與完整的軟體測試、持續整合與佈署等等條件下,透過每天晚上或每個週末來進行自動化的工作。

5. 延伸實踐 (在第二版提出的項目)

別鬧了,還有喔.......這些是在第二版才提出的,如果想要走向 X (極致) 可參考一下吧。

  • 開發人員和客戶之間的交互與溝通是有益的
  • 如果學習是好的,那麼就把它做好吧
  • 簡單的程式碼更可以完成工作
  • 如果簡單的程式碼是好的,那麼把變得複雜的程式碼改寫成簡單的
  • 程式碼評審 (Code Review) 是好的
  • 撰寫測試程式是好的

心得

軟體工程門派百百種,我相信沒有一種軟體開發模式是完全符合你的工作環境,取捨實踐會是一個不錯的方式。從眾多門派中歸納出適合自己的法則才是最重要的,避免讓這樣的方法論又邁上一張紙 (CMMI證書) 的命運。

參考資料

Facebook 留言

廣告

樂樂童鞋