軟件業發展了幾十年，軟件人們一直在摸索著軟件設計的完美方案。從早期的無序開發到瀑布式流程，再到現在的rup和xp，軟件人們一直奮斗著。前段時間的老新聞了，vista的發布日再次推遲，本來計劃會趕在今年暑期之前，現在至少要到明年了?。記得初識vista是02還是03年，那時候還叫longhorn，有次看朋友的電腦裝了個內部測試版，感覺界面很眩，挺開心的，想想等不了多久久就能爽爽新系統了，然而這一等卻是五年。據報道vista已經花了M$50－60億美元了，這次的推遲發布造成了5億損失，也只有Gates玩的起。對比下IBM的office軟件，浪費了9億美元，vista估計肯定能坐軟件失敗的頭把交椅了。

極限編程是最近一些年來軟件人們經常討論的話題，它以其另類性而獨領風騷。傳統的軟件設計比如RUP迭代開發是先計劃，然后細化，接著編碼測試，到最后的安裝交貨；極限編程更注重于程序員本身。它提倡在計劃初期就構建代碼，結對編程，測試先行，簡單設計，現場用戶等等。XP注重的核心是溝通，簡明，反饋和勇氣。因為知道計劃永遠趕不上變化，XP并不需要軟件開發人員在軟件開始初期做出很多的document，寫出很多的report；提倡只制定一個大致的plan，此時編碼測試等工作已經開始了，然后隨著各種需求的出現逐步完善plan。XP提倡結對編程即1個小組2個人員共同書寫代碼，甚至這兩人坐在一臺桌子旁共用一臺電腦。XP提倡測試先行，為了將以后出現bug的幾率降到最低···

先說說結對編程（pair-programming）。去年有機會嘗試了一下結對編程，體驗了XP在實際project中的作用。當時臨時準備用JSF做web層的開發，所用到的開發工具為IBM的RAD（rational application developer）。之前對JSF的了解純粹只是概念上知道這么一個MVC框架，而公司里面并沒有任何人很精通JSF，之前我們做的一些project都是基于JWS的胖客戶端。選擇JSF是因為研究了JSF和STRUTS的架構，感覺JSF更加合理，且其將會是J2EE 5.0的標準。

確定需求之后制定了個大致的流程，畫了一張簡單的流程視圖便開始了編碼。當時公司實際寫此軟件的人分處香港和深圳，其中深圳的4人，香港的10人。分配工作之后深圳這邊2個用JSF寫UI，1個做需求測試，一個負責文檔；香港那邊2個做JSF層，1個美工，4個邏輯層編碼及數據庫，1個整合各層，2個測試。理所當然，我和深圳這邊還有個同事組成了一個subgroup，受極限編程影響，我們選擇了結對編程。開始的5天為學習熟悉JSF時期，我們采取的方法是分頭學習，遇到想不明白的地方即提出討論。為了使討論盡可能便宜，我們選擇了2張緊靠的辦公桌。實際證明這種方法不錯，大概用了3，4天我們就熟悉了JSF的實際使用方法。有時候人是存在思維障礙的，有些簡單的東西可能想錯方向而導致時間資源的浪費。一個禮拜后接到了新的UI之后我們便開始了實際的編碼操作。初期我們決定先分開各自寫頁面，因為此時的工作比較簡單，任何涉及到提交請求的先做成空鏈接，遇到比較困難的組件，則先寫在紙片上，在每天固定的時間討論具體的實現方法并在不同的web瀏覽器進行了一些實際的測試。在我們兩人均無法解決的時候則通過jabber跟在香港的同事進行交流，共同尋求處理方法，包括尋找網絡資源等等。頁面的jsf化處理進行的很順利，比預定日期提前了2天。隨后我們開始了BackingBean的具體編寫，包括虛擬一些數據進行單元測試。這時候我們更多的是在一起進行開發，輪流編碼。結對編程客觀上減少了我們實際編碼期間的片面性，從而減少了以后進行debug工作時候所花費的時間。還有個注意的就是注釋的使用，因為我們并不打算專門寫開發的文檔，為了以后查閱，我們為每個方法都寫了比較詳細的注釋。結對編程還有個很顯然的好處就是可以使程序員更全面的掌握應用軟件，學習同伴的技巧，我就通過這次的結對編程知道了更多RAD工具的一些小技巧。最后，在UI完成的時候我們比在香港的同事快了3天，他們是采用傳統的各自編碼進行的。提個注意點，如果兩個程序員都比較喜歡聊天還是不要結對編程比較好。

慣例，幫自己的網站宣傳下 www.jsfchina.org