歪歪凍的細細私語

XP(eXtreme Programming，極致軟體製程)是敏捷軟軟開發的方法論的其中之一，之所以被取名為「極致」，主要因素為它的基本概念認為只要是對軟體開發有益處的做法，就應該要努力地實現，並且做到最佳，甚至做到「極致」的境界。比方說如果做Code review是有益的，那麼我們就應該實施搭檔編程，讓所有的程式碼都被兩個人檢驗過。如果撰寫Unit test的測試代碼是有益的，那麼我們就應該實施測試先行，讓所有的程式都保證通過測試代碼的檢驗。如果開發團隊和客戶頻繁地互動是有益的，那麼我們就應該讓客戶代表駐點在開發團隊當中，使團隊能隨時確認需求。

XP一共列出了4項範圍及12項核心的最佳實務做法，並且將之推向極限。

1. 小規模回饋
   • 測試驅動開發
   • 策劃遊戲
   • 全隊
   • 結對程式設計
2. 反覆性程式而不是批次的
   • 持續整合
   • 設計最佳化
   • 小型發佈
3. 共同認識（共識）
   • 簡單的設計
   • 系統隱喻
   • 集體程式碼所有
   • 程式設計標準
4. 程式設計師的利益
   • 恆定速度/可反覆性速率

 

測試驅動開發(Test-driven development)

傳統的程式開發方式通常是等到程式開發完畢後，再來撰寫相關的單元測試程式碼。因此會經常聽到沒時間撰寫測試程式或是偷懶僅測試Happy path的藉口，使得程式的品質無法獲得保證，也無法對其重構。

測試驅動開發指的是先撰寫Unit test測試程式，再來寫測試程式所要測的程式。如此一來，不僅保證程式一定會有對應的測試程式，並且程式在撰寫的同時也會先考慮到如何能讓程式可以被測試。除了以上基本的好處外，測試驅動開發是一種系統設計分析的方法，與敏捷方法強調「射擊再瞄準」的精神相同，測試驅動開發要求的是程式僅需撰寫足夠通過測試的部分就好，藉由逐漸完備測試的範圍，同時也確保系統維持在單純，沒有過度設計的情況發生。

策劃遊戲(Planning game)

策劃遊戲分為兩個部分：發佈計畫(Release Planning)及反覆計畫(Iteration Planning)。發佈計畫用於規劃整個產品的發佈次數及時程，而反覆計畫則在規劃每次反覆的工作內容。發佈計畫跟反覆計畫又包含了以下三個階段：探索階段(Exploration phase)、承諾階段(Commitment phase)和監督階段(Steering phase)。基本上這些活動就是在探索需求，承諾完成時間並且監督掌握開發時程。

全隊(Whole team)

全隊在之前版本的XP當中原本是客戶駐點，也就是要求客戶需派代表駐點在開發團隊當中，以接受團隊隨時能詢問需求的細節及解答問題。不過這點實在是太難做到了 XD，因此之後便改用全隊的觀點來包裝。除了將客戶駐點的概念隱藏在全隊外，另外更加強調開發工作是全體團隊一同努力的，並且應將整個團隊視為一體。

結對程式設計(Pair programming)

結對程式設計指的是兩個開發人員坐在一起，共用一組鍵盤螢幕，一起輪流協同開發同一份程式。這種看似讓兩個人做一個人的事會白白浪費一個人的時間，實則會大幅提升效率及節省時間的浪費。原因是通常一個人在工作時，通常不會乖乖地進入到全速的工作狀態，會過個5分鐘就看一下FB、回個MSN或是被其他干擾打斷，8小時的工作小時有5小時是在工作就已經非常厲害了。但是如果是兩個人坐在一起時情況便會不同了，沒辦法沒事再開個網頁看個塗鴉牆，只能專心地在工作上。除了這種互相監視(誤)的效果外，由於這段程式碼至少被兩個人所檢視過，因此BUG發生的機率會相對比較少，亦能減少日後除錯時浪費的重工時間。以長期來看，結對程式設計的投資報酬率是相當高的。

持續整合(Continuous integration)

當系統的規模變大，便需要將系統細分成各區塊已降低設計及開發難度，但是往往各區塊整合在一起時，又會引發整合上的問題，一旦在開發後期才發現整合有問題，會使得修改的困難度相對的提升。因此XP強調不要到開發後期才做整合及整合測試，應該隨時在小幅度的變動完成時就要持續地做自動化的整合測試，才能早期發現早期冶療。

設計最佳化(Design improvement)

在XP快速開發的流程下，很多時候都會選擇先能動就好的捷徑來開發，導致整個系統可能會有重覆的程式碼或是不良的架構設計。當程式碼越寫越髒，壞味道越聞越臭時，就該重構程式碼以保持設計的最佳化。

小型發佈(Small releases)

為快速得到客戶的回饋及信任，XP強調用短週期的開發將可運行的功能實作出來，好可以小規模的更新系統並發佈。藉由這種小規模的「射擊再瞄準」來快速得到回饋及修正，好確保生產出來的是客戶確實需要的產品。

簡單的設計(Simple design)

由於系統會不斷地因為需求改變而調整，因此XP建議系統的設計要維持在最簡單明白的狀態，不做任何未來不確定會不會用到這類假設性的過度設計。由於設計保持簡單的狀態，一旦需要做出架構設計上的調整時，也能在最小的邊際效應下進行變更。為了要達到這個目的，便需要一直施行重構，將設計調整在最簡單的狀態。

系統隱喻(System metaphor)

XP並不使用正式的規格或系統分析文件，取而代之的，是用現實世界的比喻來描述系統，即為所謂的系統隱喻。如此的好處是可讓客戶和開發團隊能有個簡單一致的語言來溝通，確保雙方沒有誤解，並且不需要要求客戶得學習Use case或其他需求分析文件的表示方式。

集體程式碼所有(Collective code ownership)

所有的程式碼都是整個開發團隊共有共享的，意思是你所寫的程式碼會被其他人更動，其他人的程式也能讓你隨意更動，這麼做的好處是一旦手頭上的工作忙不過來，大家都能互相地幫忙，一同解決問題。

程式設計標準(Coding standard)

為了達到集體程式碼所有的目標，其中之一要搭配的策略即是確定所有人寫的程式都有相同的風格。團隊需要討論出每個人都能接受並遵守的單一程式設計標準，這樣互相修改程式時才能更快速的了解及上手。

恆定速度/可反覆性速率(Sustainable pace)

XP反對死亡行軍的狀況，短期的加班能暫時地增加生產力，但是若超過一個禮拜便會對生理、心裡甚至是整個團隊的士氣都有嚴重的負面影響。因此XP強調要讓開發團隊的工時固定，不允許加班趕工，以持久穩定的步調，維持團隊生產力的高效率。