|
|
結對編程是構建軟件系統的一種有效方法。采用結對編程，帶來的顯著效益：
- 更好的想法——持續(xù)不斷的頭腦風暴、更大的知識庫、在理解上有更少的差異、有更多的腦力解決設計問題；
- 更好的質量——更少的漏洞、想法的即時認證、始終如一的方法并更加遵守團隊會議中的要求；
- 更全面的認識——經驗共享與知識共享、對于為什么做、怎么做和做什么有更深入的理解；
- 更高的生產率——更好地集中精力及更高的工作強度、彼此促進并激勵來達到最好的結果、更少的拖延和時間浪費；
- 更多樂趣——大多數人喜歡分小組工作并且共同解決有趣的問題。
極限編程的領導者堅持主張所有重大的進展都應成對進行。但是我們能說在所有情況下結對編程都是最好的方法嗎？
程序員可以找到一些看似可行的方法來替代結對編程，這些方法不需要兩個人始終都在一起工作：
- 想法——頻繁的團隊頭腦風暴與短期結對（或團隊）編程會議相結合，來解決最復雜的任務；
- 質量——測試人員與開發(fā)人員共事，一起編寫自動化測試；
- 認知——頻繁的討論、代碼復查、培訓會議；
- 生產率——清晰的目的與務實的工作方法可以讓你更集中精力、使方法更清晰并能帶來更高的效率；
- 樂趣——密切合作與相互支持
什么時候結對編程是最有效的方法？
最主要的因素是技術與挑戰(zhàn)相匹配。在獨自編程中，如果技能和挑戰(zhàn)能互相匹配，最高產的模式就是流模式（Flow）。結對編程添加了一個更有效的模式——指導模式（Coaching），它能夠提高全隊當前與未來任務的生產率。
成功的模式
1. 流模式（Flow）——兩個程序員共同從事一個有趣又有挑戰(zhàn)性的問題。他們會有不同的技術、遇到不同的挑戰(zhàn)，但是它們都善于找到好的解決方法。例如，其中一個人可能是Javascript專家，另一個人可能是強大的后臺程序員。他們能夠結合彼此的腦力、知識及經驗來共同處理復雜的AJAX任務，從而創(chuàng)造出最好的解決方案。
2. 指導模式（Coaching）——老練的程序員在解決問題方面有經驗和知識，可以與其他不能有效地獨自解決問題的程序員分享。后來加入的程序員有足夠的理論基礎來理解這些解決方法和程序的實現。他會在學習中慢慢進步，成為更優(yōu)秀的程序員。
失敗的模式
3. 浪費專家時間（Wasting expert time）——問題太簡單，以致專家的經驗無指導意義。
4. 不知所措的新手（Overwhelmed novice）——問題太過復雜或者需要太多新知識，使程序員學不到任何有用的東西。
有疑問的模式
5. 兩個專家共事一個易管理的任務——若兩個程序員都了解如何實現任務并且之前都成功地解決過相似的問題，那么結對編程就沒有太多的用處了。
6. 一個程序員處于流模式（Flow），另一個在一旁學習（Learning）——若另一個程序員時不時地打斷他，并要求對一些基本的但與挑戰(zhàn)性問題沒有直接關系的事情做出解釋，那么他很難專注于解決挑戰(zhàn)性的問題。
7. 一個程序員處于流模式，另一個專注于指導（Coaching）——如果想讓這種模式獲得成功，指導者應該思想開放，避免指導過多，同時也可以給另一個程序員想出自己的（甚至是更好的）解決方法的機會。
此外，心理問題可能會導致結對編程的失敗：
- 專家的威脅——遭到其他技術更高的程序員更具“威脅”的程序員，會擔心自己被視為無能；
- 需要時間考慮——結對編程之前，程序員需要更多時間去考慮，但他往往在仔細考慮自己的想法之前就被強迫開始結對編程了；
- 寧可獨自工作——內向的程序員喜歡獨自工作(不合群的人)；
- 人員關系不融洽——程序員互相討厭對方。
我們能使結對編程一直有效嗎？
當然！把任務、技術和合作匹配起來。在兩個生產方式中找到成對的——流（Flow）或者指導（Coaching）。若成對的程序員能夠用他們自己的及從對方身上學到的技術來共同解決有趣的問題，那么這個團隊將會是最高產的。
然而，結對編程應該是自由選擇或及首選方法，但它不應是強制性的實踐。就像你在這篇文章中所看到的，當結對編程不太有效的時候會產生一些模式和出現一些心理狀況。
簡而言之，結對編程應該是軟件小組工具庫中最有用的工具之一。要弄清楚什么時候及如何使用它。
結束語
你已經結對編程了么？如果你已經結了，歡迎在評論中和大家分享你的相關觀點、經驗和心得。
it知識庫：什么時候該采用結對編程？，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
