雖然我沒能去參加BEA的活動，但是相關(guān)的資料已經(jīng)下載并且瀏覽過了，確實收獲不少。所以，對于莊兄的這些想法我很理解。
相信不只你我，大部分的人都比較認同敏捷化的過程，希望使過程變得敏捷。的確，這是個好東西，之前我也說過“敏捷過程是三贏的”這樣的話。
我所關(guān)心的問題是“如何能夠用好XP？”。
莊兄認為“湯的味道，不需要什么過程控制”，我也會認同。為什么？因為你我都是中國人。大部分中國人不會認為湯的味道需要什么過程控制。但是想想看，如果你在不同地方買到的肯德基炸雞味道各異；同一批次生產(chǎn)的同型號的汽車形狀各異；銀行里取出來的一疊百元大鈔大小不一，你不會覺得奇怪么或是有那么一點點憤怒么？
西方人（甚至學習西方的日本人）對品質(zhì)的重視程度卻完全不同。他們不允許肯德基炸雞的味道有很大偏差（即便你覺得無所謂）；“2毫米工程”不允許整車的總裝長度發(fā)生2毫米以上的偏差（即便你覺得無所謂）；百元大鈔……（我想誰都不會無所謂）。
所以，一切質(zhì)量都有標準，一切標準都應(yīng)該被度量！這就是工程學的目標之一，為了實現(xiàn)更嚴格的質(zhì)量標準，就需要過程控制和度量。
莊兄所說，用測試用例保證代碼的質(zhì)量其實還是采用了“測試用例”作為度量的標準。唯一的問題是：“如何確保測試用例的質(zhì)量”。顯然，我們不能把一把不直的尺子度量出來的結(jié)果作為可靠的參考依據(jù)。怎么解決呢？“結(jié)對編程”么？嗯，這是一個不錯的方式，那么最終該信賴誰呢？是Pair中的A還是B呢？或者，是Leader么？那么又是誰提出的要求呢？是老板么？還是客戶？政府？法規(guī)？市場？……問題沒有終結(jié)了。
不要學習哲學家的方法，提出一層又一層無法解決的問題。我們是工程師，應(yīng)該試圖解決問題才對！解決問題的關(guān)鍵在于，XP同樣需要標準！為了制定標準，必要的文檔是不可以少的。而且，標準本身的質(zhì)量是嚴苛的。因為，作為標準，他不可以含糊其辭、模棱兩可。在標準的基礎(chǔ)之上，我們才可以談什么TDD、Pair Programming之類的實踐。
回到爭論的開端。我引用了林先生的話“UP是正楷；XP是草書。要先學好UP才能學好XP，先學XP會亂套。”我對這句話的理解如下：這句話并沒有批判UP或是XP，只是指出了一個學習的順序。我認為這句話是有實踐依據(jù)的，因為UP強調(diào)的是一種經(jīng)典的工程方法。軟件工程本來就源于其他行業(yè)的工程實踐經(jīng)驗。UP利用大量的文檔對開發(fā)活動進行約束和記錄。正是這種重量級的過程規(guī)范了規(guī)范了從PM到Coder的所有活動，有問題可以參照文檔，看看自己應(yīng)該怎么做。文檔也可以作為日后評估這個過程的依據(jù)。隨著整個團隊和每個個人的經(jīng)驗不斷積累，開發(fā)活動中的日常行為漸漸形成了一種職業(yè)習慣。然后可以通過對UP的配置，逐漸減少文檔的使用量，一些沒有必要的文檔就可以省去，更具團隊的實際能力調(diào)整過程。UP是可配置的，不必要的文檔沒有存在的理由，這一點UP和XP沒有什么兩樣。當然，隨著大家的職業(yè)習慣越來越好，經(jīng)驗越來越豐富，個人和團隊就可以采用更敏捷更輕便的過程，逐漸過渡到XP上去。
反過來，如果一開始就沒有詳盡的文檔，很多活動（比如設(shè)計、版本控制）往往會脫離控制，進入一種無序的、混亂的狀態(tài)。沒有文檔可參考，就意味著很多問題只能問人，而不同人的回答可能各異，同一個人對同一個問題的兩次回答也可能不同！當然，如果整個團隊的工程素養(yǎng)和個體的職業(yè)習慣都比較好的情況下可能不會發(fā)生類似的情況。但是這種工程素養(yǎng)和職業(yè)習慣從哪里來，可能單靠的XP是不足以培養(yǎng)出來的。
“UP是正楷；XP是草書。要先學好UP才能學好XP，先學XP會亂套。”這句話表明了UP和XP在一定程度上是存在沖突的，并且提出了一條路線去降低和避免這個沖突。
再次需要強調(diào)的是莊兄所提到的“XP是一種思想”，這點我認同。但是我認為這個除了思想之外，還是一種“文化”。這種思想和文化也是出于軟件工程多年來的實踐，其中也不免有UP等其他過程。不能簡單地認為“我們只要吸取歷史的教訓，提出新的思想和文化就不會再犯同樣的錯誤了。”很多時候歷史總是一次又一次地重演著。新的思想和文化如果不能被準確地理解和運用，它所帶來的可能仍然是它原本想解決的問題。只有我們具備了引入這種文化的基礎(chǔ)，才能把它變成自己的文化，否則這仍然是掛在嘴邊行于表面的一種不求精髓只求模仿的偽文化、偽思想。這一點對于UP和XP的實踐者來說沒有什么兩樣。