什麼時候該採用結對編程? - OSCHINA - 中文開源技術交流社區

編者按：原文作者Andriy Solovey從事軟體開發已有15年，做過開發人員、軟體經理和系統架構師。關注構建優質、可靠和可用的軟體。

結對編程是構建軟體系統的一種有效方法。採用結對編程，帶來的顯著效益：

• 更好的想法——持續不斷的頭腦風暴、更大的知識庫、在理解上有更少的差異、有更多的腦力解決設計問題；

• 更好的質量——更少的漏洞、想法的即時認證、始終如一的方法並更加遵守團隊會議中的要求；

• 更全面的認識——經驗共享與知識共享、對於為什麼做、怎麼做和做什麼有更深入的理解；

• 更高的生產率——更好地集中精力及更高的工作強度、彼此促進並激勵來達到最好的結果、更少的拖延和時間浪費；

• 更多樂趣——大多數人喜歡分小組工作並且共同解決有趣的問題。

極限編程的領導者堅持主張所有重大的進展都應成對進行。但是我們能說在所有情況下結對編程都是最好的方法嗎？

程式設計師可以找到一些看似可行的方法來替代結對編程，這些方法不需要兩個人始終都在一起工作：

• 想法——頻繁的團隊頭腦風暴與短期結對（或團隊）編程會議相結合，來解決最複雜的任務；

• 質量——測試人員與開發人員共事，一起編寫自動化測試；

• 生產率——清晰的目的與務實的工作方法可以讓你更集中精力、使方法更清晰並能帶來更高的效率；

什麼時候結對編程是最有效的方法？

最主要的因素是技術與挑戰相匹配。在獨自編程中，如果技能和挑戰能互相匹配，最高產的模式就是流模式（Flow）。結對編程添加了一個更有效的模式——指導模式（Coaching），它能夠提高全隊當前與未來任務的生產率。

成功的模式

1. 流模式（Flow）——兩個程式設計師共同從事一個有趣又有挑戰性的問題。他們會有不同的技術、遇到不同的挑戰，但是它們都善於找到好的解決方法。例如，其中 一個人可能是javascript專家，另一個人可能是強大的後臺程式設計師。他們能夠結合彼此的腦力、知識及經驗來共同處理複雜的AJAX任務，從而創造出 最好的解決方案。

2. 指導模式（Coaching）——老練的程式設計師在解決問題方面有經驗和知識，可以與其他不能有效地獨自解決問題的程式設計師分享。後來加入的程式設計師有足夠的理論基礎來理解這些解決方法和程序的實現。他會在學習中慢慢進步，成為更優秀的程式設計師。

失敗的模式

3. 浪費專家時間（Wasting expert time）——問題太簡單，以致專家的經驗無指導意義。

4. 不知所措的新手（Overwhelmed novice）——問題太過複雜或者需要太多新知識，使程式設計師學不到任何有用的東西。

有疑問的模式

5. 兩個專家共事一個易管理的任務——若兩個程式設計師都了解如何實現任務並且之前都成功地解決過相似的問題，那麼結對編程就沒有太多的用處了。

6. 一個程式設計師處於流模式（Flow），另一個在一旁學習（Learning）——若另一個程式設計師時不時地打斷他，並要求對一些基本的但與挑戰性問題沒有直接關係的事情做出解釋，那麼他很難專注於解決挑戰性的問題。

7. 一個程式設計師處於流模式，另一個專注於指導（Coaching）——如果想讓這種模式獲得成功，指導者應該思想開放，避免指導過多，同時也可以給另一個程式設計師想出自己的（甚至是更好的）解決方法的機會。

此外，心理問題可能會導致結對編程的失敗：

• 專家的威脅——遭到其他技術更高的程式設計師更具「威脅」的程式設計師，會擔心自己被視為無能；
• 需要時間考慮——結對編程之前，程式設計師需要更多時間去考慮，但他往往在仔細考慮自己的想法之前就被強迫開始結對編程了；
• 寧可獨自工作——內向的程式設計師喜歡獨自工作(不合群的人)；
• 人員關係不融洽——程式設計師互相討厭對方。

我們能使結對編程一直有效嗎？

當然！把任務、技術和合作匹配起來。在兩個生產方式中找到成對的——流（Flow）或者指導（Coaching）。若成對的程式設計師能夠用他們自己的及從對方身上學到的技術來共同解決有趣的問題，那麼這個團隊將會是最高產的。

然而，結對編程應該是自由選擇或及首選方法，但它不應是強制性的實踐。就像你在這篇文章中所看到的，當結對編程不太有效的時候會產生一些模式和出現一些心理狀況。

簡而言之，結對編程應該是軟體小組工具庫中最有用的工具之一。要弄清楚什麼時候及如何使用它。

結束語

你已經結對編程了麼？如果你已經結了，歡迎在評論中和大家分享你的相關觀點、經驗和心得。

譯文出處：伯樂在線- 職場博客
譯文連結：http://www.jobbole.com/entry.php/489