XP？我真應該採用嗎？

我閱讀的第一本關於軟體工程的書是講述極限編程（XP）的。當時我還在讀大一，似乎啥都不懂，但卻對XP高度興趣——畢竟它提倡簡略一些我不想學習的東西：文檔、設計……當然，它自身的理論也很吸引人，看上去就像12個實踐的完美結合體。

後來，我又陸續看了很多其他的書，淺略地瞭解了傳統的瀑布式開發、敏捷（Agile）方法等。然而我只是粗淺地瞭解，儘管如此，卻仍不免懷疑以前的看法。

沒錯，XP看上去是很美：它簡單，每個人都能看懂，也符合我這種激進的年輕人的心態，我似乎沒有理由拒絕它。可是，它真的安全嗎？或者說，它比採用其他的方法失敗的危險性更低嗎？

在《解析極限編程：擁抱變化》中那張描述XP的12個實踐緊密相連的圖裡，你看到了什麼呢？XP真的像描述地那麼簡單嗎？不，至少我不這樣看，因為我被這張圖亂七八糟的連線給弄糊塗了。我能想到的只有3個字：緊耦合。沒錯，每個實踐都是如此密切地和其他實踐相關聯，很難想像偏離了一個實踐後，整個XP不會土崩瓦解。

我想，我們確實需要如XP中所說的勇氣，可是光有勇氣是無法編程的。即便有足夠的勇氣去面對XP的脆弱，隨著時間的慢慢推移，失望的次數慢慢增多，我們似乎也沒那麼多信賴給予這個激進的方法。我們也許可以鼓起勇氣接受XP，但不一定能在實踐的過程中，堅定地堅持這12個實踐——而放棄任何一個，也許就意味著項目註定失敗。

XP不是神話，否則怎會沒有成功用XP實現的大型項目呢？即便是神話，那也是神才能做到的，誰有足夠的信念堅定不移地實踐XP呢？人們經曆過很多失敗，自然會對風險大的事物保持懷疑態度——如果現實也趨向如此，則更加。

為什麼XP讓人感覺風險大呢？我認為是它放棄了太多有用的實踐，而過分依賴其他的實踐來彌補。例如採用緊急分析和簡單設計，花上10分鐘來進行分析設計，就開工了；然後為了擴充功能，又得花上不知道多久的時間來重構——1小時，1天，1月，或者直到項目以失敗結束。也許謹慎地花上幾個月來分析和設計，或者至少幾天、幾小時的時間，重構的時間就可以節省1小時、1天、1月，甚至挽救整個項目。重構並沒有錯，但過分依賴重構來彌補設計錯誤，就如同摩天大廣告蓋到一半時，把樓拆了改建地下停車場一樣愚蠢。雖然XP強調擁抱變化，客戶可以在樓蓋到一半的時候想到應該可以在樓下建個停車場，於是XPer欣然地把樓“重構”了。但如果開始設計時就保留了建立停車場的空間，即使後來客戶沒要求建立停車場，又會有多少損失呢？需求確實是變化的，但通過分析，確定大粒度的不變性；再依賴設計，提供可更改的擴充性，不是更好嗎？

沒錯，XP的很多實踐看上去都不錯：結對程式設計、單元測試、重構、持續整合……但這些還不足以決定項目的成功，而過分依賴這些實踐，是否太過極限了？更重要的是，有些實踐是很難做到的，例如現場客戶。另外，對於1個房間容納不下的團隊，也是無法採用XP的。

也許，我們可以讓XP不那麼極限，拆開各個實踐之間的緊密聯絡，對它進行“重構”，形成一個“高內聚、低耦合”的方法。Agile包含了很多方法，除去XP，也許有那麼幾種會更適合軟體開發——只是它們的知名度沒XP高罷了。

只是我仍沒主意，到底應該怎麼重構XP。項目已經開始了，拉了個同學來實踐結對程式設計，花了幾天找了個QQ上能聯絡的客戶，花了幾個小時學習CppUnit的使用（比JUnit麻煩多了；居然在VC2005上很多構建不了，還得回到VC6），可是離其他實踐還遠得很。我也不喜歡寫文檔，那花去我太多時間，我寧願用來寫日記——可我還是得寫，那讓我編程時思路清晰。我喜歡分析和設計，想到一個好的設計會讓我很有成就感——似乎比實現它更多，所以我會在這方面多花些時間。

管它呢，反正年輕不怕失敗。沒有什麼應不應該採用，我該做的就是按自己認為正確的想法去做，失敗了就換個方法再試一次——史泰龍不也在當上男主角前被拒絕了1850次嗎？也許一向運氣很好的我，可以直接嘗試第1851次～～。