關於結對編程的一些問題

前言

　　最近因爲公司項目，有機會嘗試結對編程（pair programming），實踐了3個月，也有了本身的一些心得體會，本文以Martin.Fowler的《結對編程模糊概念》來展開敘述。

1. 實踐敏捷過程必定要「結對」嗎？

This is utterly false. 'Agile' is a very broad term defined only in terms of values and principles, most notably in the Manifesto for Agile Software Development.

　　正如Martin所言，敏捷宣言並未說起結對編程是必須的，敏捷只是一種思想，結對編程僅僅是實踐中的一個非必須的組成部分。即便XP被強烈推崇，也不表明結對編程適用於任何公司或者項目。

　　就我的體會而言，目前項目組內會有Switch pair的過程，個人理解是pair的過程更多的注重團隊成員間的知識分享以及相互之間的溝通、檢查代碼等，帶來代碼質量上以及、知識流動上的優點，要因項目或成員而異。

2. 極限編程迫使你結對嗎？

I would say that pair-programming is usual for XP teams. I wouldn't say that a team that doesn't do pair-programming thus cannot call itself an XP team. I should also point out that to most XPers I know the question of whether a team is XP or not is uninteresting; the real issue is whether a team is effective.

　  Martin所同意的是團隊開發效率或者說結對編程是否適合團隊。

3. 若是我不喜歡結對編程，我就不必去實踐它？

　　Make sure you have someone who really knows how coach you, so you can be sure you're evaluating the real thing.

　　針對這一點，我以爲我仍是有切身體會的，真的很贊成Martin的觀點。若是你經歷過一個很差的pair體驗，你就要回憶而且追問下，是否你找到了「合適」的parter來一塊兒pair，而不是那種話不投機半句多、我寫你看着，這種同伴。

　　每每pair的過程當中兩我的的水平會有所差距，這個問題要從下面幾個角度考慮：

　　1. 若是你是low的一方，你須要一個什麼樣的同伴，你但願同伴是如何回答你的各類疑問，如何正確提出問題，怎麼樣提問能讓對方樂意回答你的問題，如何讓pair的對象不以爲你很low，如何找一個有耐心的同伴交流，而不是諷刺挖苦？

　　我以爲這個問題是一個很難平衡的問題，可能在大多數的狀況下，要虛心請教、加速學習，努力跟上設計思路，而且提出本身的觀點，讓對方以爲你不是一個「無用之人」，誠然，最開始老是最難熬的，「命運」是公平的，若是有一個更Nice的同伴，可能你的學習努力程度就會稍若些；若是你的同伴很自傲，說話略帶諷刺，這可能會激勵你更快的學習。儘量找一個適合本身的parter纔是開始pair的關鍵。

　　2. 若是你是High的一方，你是否思考過，low的一方的感覺，你應該如何幫助low的一方提升能力水平，如何能在你累的時候，low能替你完成你的思路？

　　俗話說的好，授人以魚，不如受人以之漁。可能作爲能力稍強的一方如何引導同伴去融入代碼，融入設計思惟，而不是我本身也行，不須要知識分享也能完成，或者你水平太low，問題太多，我不須要你這樣的累贅。其實pair的一方面是分享知識的過程，若是簡單簡單理解爲完成項目任務，則會錯失不少提高本身的機會，若是是這樣你要考慮你是否適合pair。

　　3. 兩我的水平至關，有時，你們思路一致，互相搶鍵盤來完成代碼，而有時，甚至兩我的爲了一個命名爭的面紅耳赤？

　　這是一個至關廣泛的情景，而每每後者出現的次數更多。這裏有一些對代碼理解上的衝突，有一些實踐上的規範，還有一些人心裏的虛榮（不接受別人對本身的否認，即便是錯誤的也要堅持），這時首先要思考下本身堅持的東西是不是正確的，本身是否能認可不足（不完美），其次能夠找「第三方」來決斷矛盾。從實踐的角度出發，若是事事都要第三方決斷的話，極有可能大家兩個之間的pair關係早以不存在，我以爲處理pair矛盾的過程是兩我的互相理解、互相包容的過程，一味最求自我，這樣只能單打獨鬥。

　　固然，若是兩我的，「化學」做用比較好的話，會很是happy ：）

4. 結對編程對下降工做效率？

that would be true if the hardest part of programming was typing

　　一些結對編程的支持者認爲，結對編程的效率會更高，他們（她們）能夠持續討論、互相review代碼，這樣能夠保證高質量的代碼。而更多時候「工做效率」是沒法衡量的，特別是在解決很困難的問題時，一我的可能會陷於某種「極明顯」的錯誤中，而不得要領，這個時候若是兩個能保持獨立思考的人每每效率更高。

　　在個人pair中，有時個人任務是當代碼開發遇到困難時梳理代碼的做用，重新overview代碼思路，解決困難，一我的的能力是有限的，而兩個互補的人會產生1+1>2的效果。

5. 結對編程只適用於解決困難代碼場合？

Except this: writing boring rote code is a smell. If I'm writing boring repetitive code it's usually a sign that I've missed an important abstraction, one that will drastically reduce the amount of rote code to write. Pairing will help you find that abstraction.

　　簡單並不表明沒有重構機會或者說沒有機會寫出更完美的代碼。

　　在個人pair過程當中，partner老是在提醒我要重構，抽取代碼段，也許這就是一種外在的推力，來開發更優質的代碼。結對編程是提成代碼能力的過程，你如何知道你寫的代碼是最最優美的呢？看看codewars上大牛們代碼，你本身都會以爲汗顏。