個開發環境。嘿嘿，小寶，他來了你再有問題就可以直接向他請教了。章浩人很Nice的。”

“是啊！自從Charles那回聽過咱們的站立會議之後，對Scrum很有好感。再加上咱們前幾個Sprint確實做得還行，所以這次Charles聽完我和李沙關於TD專案開發任務的彙報後，咱們不是在Resource一欄寫著缺少開發人手嗎？他看了之後就問我想要誰。我的第一個念頭就是章浩！”

“呵呵，當時說出來還怕Charles不答應，因為章浩畢竟是周小小Team的Technical　Leader。Charles當時可沒答應我，只是跟我講他會去和周小小談談！誰知道今天早上Charles就告訴我章浩可以下週暫時借調到咱們Team，做完咱們規劃的3個Sprint之後，再看情況是否需要回周小小的Team。”阿捷笑著和大家講述著事情的經過。阿捷並沒有和其他人講其實他在和Charles講完借調章浩後，曾經獨自找章浩談過近3個小時。

“哈哈，我說昨天中午在食堂跟章浩一起吃完飯往檯球室走，中途遇見周小小，周小小連看都不看我跟章浩一眼，原來是因為這個啊。呵呵，太好了，下週章浩過來剛好可以趕上咱們的下一個　Sprint！”大民興奮地講著。

第11章　你開車，我導航（6）

“嗯，是啊。雖然章浩非常有經驗，可能他也需要對咱們正在用敏捷方式做的TD專案熟悉一段時間。咱們最好想個辦法，讓章浩迅速融合到咱們的開發程序中。大民，你還記得上次你提到的結對程式設計嗎？如果專案組有新人加入，或者由於某種原因進行換崗，你提到可以透過結對的方式來提高整個團隊的開發效率。今天再給我們大家講講吧。”阿捷看著大民。

大民高興地說：“好啊，阿捷！我老早就想說這個了，只不過咱們組一直都沒有進過新人。說到結對，通常咱們大家都會立即想到程式設計結對，其實在XP中，這個概念可以是更廣泛一些的，還可以是設計結對、評審結對、單元測試結對！”

“設計結對是在對某個模組開始編碼之前，兩人共同完成該模組的設計，這種設計通常不會花費很長時間，不會產生設計文件，更多的是討論交流，主要考慮是否符合總體架構，是否足夠靈活，易於重構等。”

“單元測試結對通常是說一個人編寫測試程式碼，另外一個人編寫程式碼來滿足測試。這樣，任何一個人對設計理解有誤，程式碼都不會透過單元測試，從而可以避免由同一個人編寫單元測試程式碼和程式程式碼帶來的黑洞，往往可以發現更多的問題或缺陷。”

“聽起來是把一個人的TDD；　變成了兩個人的TDD！”阿捷總結。

“對！這樣效果會很不錯！複審結對是在編碼活動完成、透過單元測試後進行的。一般採用一個人講程式碼組織和程式設計思路，一個人傾聽、提問的形式。這種複審模式更多地強調了相互交流，這會比一個人單獨評審，然後總結評審意見發給原作者的模式效率要高得多，文件、郵件也減少了。當然有人說，這麼做就會沒有文件化的評審記錄。可誰會關心這個呢？良好的程式碼應該說明了一切。”

小寶一直聽得很仔細，插了一句：“其實，如果兩人程式設計結對了，程式設計的過程其實也就是複審的過程，完全可以省略評審。”

“對！”大民非常贊同小寶的觀點，“設計結對、評審結對、單元測試結對這三種方式是對結對程式設計實踐的有效補充，操作簡單，受益卻很大。而對真正意義上的程式設計結對，我其實並不怎麼看好！”

“啊？為什麼？”大家都對大民丟擲的這個結論很震驚！

“程式設計結對，在任一時刻都只是一個程式設計師在程式設計，效率到底有多高呢？1＋1》1是肯定了，但是否1＋1》2呢？”大民留了一點時間給大家思考。

“現在還沒有肯定的答案！國外也有很多關於程式設計結對的研究，基本都是建立在結對的兩人組和一個人之間的對比，結論基本上是程式設計結對不能始終保證開發質量和效率始終高於單人程式設計。如果是結對的兩人組和兩個單人開發組進行對比，結果更是未必。所以，我目前也不認為結對一定能始終提高效率。”

“但是，我覺得，他應該能夠在某一個階段，或者說專案進行的某一個階段內提高效率提高質量。”小寶滿懷疑問地說。

“這也是對的！所以我前面也提到了‘始終’這個詞！這是因為只有兩個經驗相等的人結對才有可能真正提高編碼效率。而現