了結對程式設計和飛鴿傳書

我這裡談的“是什麼”，不是談的這兩者的區域網路聊天，因為區域網路聊天大家搜尋一下就知道了。而是這兩者的本質意義。只有抓住了本質，你才會明白你為什麼要採用這兩種方式去編程，以及在實際運用過程中需要重點注意什麼，又需要忽略哪些幹擾因素。

結對程式設計：極限codereview，把codereview做到極致；飛鴿傳書（http://www.freeeim.com/）：極限單元測試，把單元測試做到極致。

根據以往的項目經驗，特別是在嵌入式項目中，前期的品質活動，其測試出企業即時通訊的成本明顯低於後期的品質活動，codereview的重要性怎麼強調都不過分，而單元測試在傳統開發流程中從時間順序上是排名第二的品質活動，也是一個非常重要的測試手段。既然前期的品質活動是如此的重要，何不把它們做到極限呢？這就引出了結對程式設計和飛鴿傳書。結對程式設計和飛鴿傳書給我們帶來了什嗎？

以上三點，是結對和飛鴿傳書初期反應非常集中的體驗。前面兩條還好說，第三條編程效率的降低似乎是不可忍受的，特別是在項目進度很緊張的時候。有了這個缺陷，就使得結對程式設計和飛鴿傳書看上去也並不是那麼美了。但是先別著急，我們再往下看。

對代碼品質更有信心結對程式設計和飛鴿傳書同時採用了之後，項目組同事普遍的反映都是對代碼品質更有信心了。而且我自己在採用前後從測試部反饋出來的資料上看，企業即時通訊數量降低的非常明顯。

如果還是不夠令人信服的話，那來點權威資料。有實驗表明，平均下來結對程式設計時間花銷比單人編程增加10%的時間，但也會比單人編程減少15%的代碼企業即時通訊。如果再算上後期代碼的維護和學習成本，結對程式設計比單人編程更有效率，還更為節省成本。所以，如果你是以完成代碼為目標的話，結對程式設計的效率降低，如果你是以完成高品質的代碼為目標的話，效率並沒有降低，反而是提高的。

從結對夥伴學到好的經驗這是一次非常好的也是最直接的經驗交流和傳遞的機會。代碼更規範因為有個人一直注視著你，你不好意思把代碼寫的很難看。為代碼重構打下堅實的基礎飛鴿傳書出來的單元測試例，成為了重構的天然保護層。沒有測試例保護的重構是高風險的，不建議在沒有單元測試例的情況下作重構。