軟件工程之結對編程親歷記
作為程序員的你，不知道曾經是否嘗試過這樣一種開發模式：你有一個伙伴，你們坐在一起，并肩作戰，面對著同一臺顯示器，使用著同一鍵盤，同一個鼠標，你們一起思考，一起分析，一起編程。如果你嘗試過，那你可以繼續讀下去，看看我們是不是有同樣的感受；如果你沒有嘗試過，那你更應該讀下去，因為這篇文章將會帶你體會這種編程模式，帶你走進結對編程的世界。
下面，我就來講講我所經歷的結對編程吧。
這次結對項目的名稱為“學術會議的展示”，即在原有的微軟學術地圖的基礎上，添加學術會議的信息及地理位置顯示。這是一個不大不小的項目，兩個人共同花了9天的時間，在完成基本功能并保證穩定性的同時，添加了一些華麗的界面元素，總的來講，感覺不錯。
因為是軟件工程，所以我們要從工程的角度出發，在正式開始之前，要制定好自己的計劃。對于一項工程，我們會有一個期望的結果，稱之為Goal。為了實現這個Goal，我們會做許許多多的小工作，將這些小工作全部整合起來，就成了我們的項目。因此，我們首先要做的就是將項目細化為這樣一個一個的小工作，這一步我們稱之為WBS(Work Breakdown Structure)。
對于我們的項目——學術會議的展示，我們把他分成了三個部分，其中每個部分又分成數個小任務。
1、 將會議顯示在地圖上
2、 界面設計及事件
3、 會議搜索
以下是任務的細分及對任務完成的時間估計和實際完成時間。
1、 將會議顯示在地圖上
?。?） 獲取會議基本信息，如舉辦時間，全名，縮寫，地點，學科方向等等。
估計完成時間：2小時 實際完成時間：2小時
?。?） 數據處理，如計算會議的總發表論文數及被引用數，并對其排名
估計完成時間：1小時 實際完成時間：2小時
在這一步中，我們為了方便，并沒有將所有數據都獲取下來，然后離線處理，而是直接編寫SQL語句實現。不過由于數據量還是太大，而且中途遇到過不少bug如數據重復問題，分學科統計問題，前前后后花費了我們兩個小時的時間。
（3） 獲取會議舉辦地點的經緯度
估計完成時間：1小時 實際完成時間：1小時
（4） 編寫WCF通信服務將以上獲取的數據從網站服務器傳送給應用程序端
估計完成時間：1小時 實際完成時間：4小時
在這一步中我們終究還是低估了在編寫Silverlight-WCF通信程序時可能遇到的各種問題，一個簡簡單單的跨域問題足足折騰了我倆四個小時時間，東測試西測試，沒找到問題之所在，最終在網絡上找到解決方案。
（5） 根據第二步所獲取的會議排名，將會議顯示在地圖上
估計完成時間：2小時 實際完成時間：1小時
這一步作為最關鍵的一步，我們分配了兩個小時，其實實現起來無非是按部就班，因此很快便完成了。
2、 界面設計及事件
（1） 設計會議展示界面
估計完成時間：2小時 實際完成時間：5小時
界面設計永遠是沒有***的，因為每個人的看法都是不一樣的。在這一環節上，我與我的partner看法產生了分歧，最終采用的他的設計方法。事實證明做設計也是需要時間的，前后足足花費了我們5個小時，終于設計出了還看的過去的一個面板。
?。?） 從微軟學術搜索API獲取所需數據并在所設計面板上顯示出來
估計完成時間：2小時 實際完成時間：2小時
?。?） 為界面添加超鏈接及鼠標事件
估計完成時間：3小時 實際完成時間：5小時
之前一直使用TextBlock或TextBox，界面難看且不靈活，于是打算自己設計界面。設計到一半，突然發現在Silverlight 4中richTextBox成為了系統組件，這為我們界面的顯示提供了很大的便利，但也豐富了我們的想法，讓我們在上面實現了更多的東西，超過了原有的預期的時間，但結果還是令人較為滿意的。
3、 會議搜索
?。?） 自動補全搜索框的實現
估計完成時間：1小時 實際完成時間：2小時
（2） 根據機構名定位到指定回憶舉辦地并顯示其詳細信息
估計完成時間：1小時 實際完成時間：0.5小時
以上就是我們詳細工作的時間劃分，但實際上我們更多的時間奉獻給了討論與修正bug以及最終與他人項目的合并工作。這是每一個人都可能會遇到的問題，怎么處理好這些問題也是對我們很大的考驗。
上面介紹完了基本的任務，下面就是具體的實施結果了。
項目完成之前的界面，大家可以看這里：http://academic.research.microsoft.com/academicmap
我們的結果：
1、 查看
在左邊欄中，可以選擇Conference，然后我們便可以在地圖上看到看學術會議。每一個圓點代表一個會議，根據這個會議總共發表的論文數，這個會議的原點會有不同的大小和不同的顏色。在左邊可以通過學科方向和會議時間來篩選。
2、 界面
將鼠標移動到會議圓點上，我們可以看到詳細的關于會議的信息，包括全名，縮寫，年份，發表論文數及被引用數，舉辦城市等等信息。
當我們點擊圓點以后，會彈出如下圖所示的面板。這是會議信息展示的主界面，在這上面，我們一個劃分額四個區域。
?。?） 左上角為當前會議信息，當點擊標題后，會打開新頁面跳轉到微軟學術搜索相關會議的界面。
?。?） 右上角為該會議所感興趣的學科領域。
?。?） 左下角為該會議在不同年份的信息，每一條信息都是建立在一個按鈕之上，因此當鼠標點擊時，在地圖我們就會跳轉到相應的位置及顯示相關的信息。
?。?） 右下角同樣是該會議的相關信息，包括會議的主頁，會議的前三條關鍵字，以及會議上最出名的三個作者（按被引用數排名）。每條信息都是一個超鏈接，當你點擊時會打開新頁面顯示相關的信息。
3、 搜索
當進入會議視圖后，我們會看到下面的搜索欄
下面輸入我們想查詢的關鍵字，以IEEE為例
搜索框自動補全了我們想要搜索的信息，當我們選中時，地圖就會跳轉到相應的回憶舉辦地并顯示如2.種所示的界面。
以上就是我們的結果，怎么樣，從效果上看，還不錯吧。
介紹完我們的項目，還是回到結對編程上來。這是我***次體驗這樣的編程模式，這種模式到底好與不好，我只能說，因人而異吧。
不可否認，這樣一種編程模式其好處是顯而易見的。作為一個driver，在編程的同時，你總會想著你旁邊還有一個人，這樣你就會格外的認真，注意每一段代碼的格式，按照統一的規范來寫。作為一個navigator，你會時刻關注你旁邊的人寫的代碼，思維在不停的運作，在寫的同時進行著復審，在起到監督的同時也提高了代碼質量，減少了復審所需要的時間，不用事后再去花大精力閱讀代碼，因為在寫的時候你已經對代碼非常了解了。每當一個人獨自寫程序時，如果任務不是那么的緊，我們很容易出現懈怠的情緒，這時我們可能會打開人人、微薄這種東西來打發消遣一下。當兩個人共同工作時，你浪費你自己的時間不要緊，但你浪費他人的時間就說不過去了。
話說回來，世上人與人之間總是存在差異的，而不像機器那樣由程序統一控制。當兩個人的思維發生碰撞時，有時也許會融合并誕生出更好的想法，有時恐怕就會出現爆炸，令雙方都不太愉快。如果讓兩個編程習慣及審美觀差別極大的人結對完成一個項目，那可想這個過程會是多么糟糕，基本在爭吵中度過，這樣能夠寫好程序嗎？當兩個人的技術水平差別過大時，一人嫌另一人效率低，另一人則感覺被輕視，越發懈怠，這有基本成了一個人的工作了，而且兩人也不愉快。同時，這也許項目的選題相關，有些項目需要個人思考去解決問題，有些項目需要大家討論來解決問題。有的人不喜歡旁邊有人看著，有的人不喜歡總是看別人而自己不動手，這些都會成為結對編程的限制條件。因此，在結對編程前，我們應該確定合適的選題，并且兩人不能太陌生，技術水平不能差別太大，要互相認可對方。有相同的認可，相同的興趣，合適的選題，充分的熱情，然后兩人結對進行開發，這樣才能發揮出結對編程應有的功效，不至于將大量時間浪費在無謂的爭吵上。
結對編程真的能夠帶來1+1>2的效果嗎？我認為這很大程度上取決于我們自己的規劃，因為很多時候，我們需要自己獨立的思考，去實現一些想法，并不需要兩個人一天從早到晚一直坐在一起，面對著同一臺顯示器，一起思考，一起設計。
下面介紹一下我的隊友林榕城。從三明治的角度出發——他是個技術能力非常強的人，有著強大的想象力，但是這些想象力往往會超出我們的實際能力，認為任何問題都很簡單，從而造成一種心有余而力不足的景象，比較追求華麗，這與我所認可的簡約美產生了分歧，不過，他確實是一個非常好的隊友，追求卓越，為我們的項目做出了非常多的貢獻，并且工作積極，很大程度上督促著我，同時也糾正了我的許多編程毛病，給了我很大幫助。
***，來一張咱的合照：
照片上，我是一名driver，但更多的時候，我充當著一名navigator。
結對編程，你明白了嗎？
原文鏈接：??http://www.cnblogs.com/foster/archive/2011/08/29/2158082.html??
【編輯推薦】
