配對程式設計的迷思

關於 配對程式設計 的一些常見迷思。

如果你正在進行敏捷流程，你必須進行配對程式設計。

這是完全錯誤的。「敏捷」是一個非常廣泛的術語，僅根據價值觀和原則定義，最著名的是 敏捷軟體開發宣言。宣言中沒有提到配對程式設計，而且大多數敏捷方法都沒有將其納入其方法中。

由於配對程式設計是 XP 的一種實務，因此它在敏捷社群中具有很大的影響力。因此，它經常被提及為敏捷實務，意即一種通常由敏捷專案人員使用的實務。但這是一種觀察，而不是一種規範。

極限程式設計強迫你進行配對程式設計

這是一個更為微妙的問題。配對程式設計是 XP 的實務之一，而且自其創立以來一直如此。此處的微妙之處在於 XP 實務對於宣稱正在進行 XP 的團隊而言是否為強制性的。這實際上是一個比乍看之下更棘手的問題。XP 與任何敏捷方法一樣，都期望團隊選擇自己的流程。在《極限程式設計精解》中，Kent 說實務是「你會看到 XP 團隊每天都在做的事情」。我會說配對程式設計對於 XP 團隊來說很常見。我不會說一個不進行配對程式設計的團隊因此不能稱自己為 XP 團隊。我還應該指出，對我所認識的大多數 XP 人士而言，一個團隊是否是 XP 團隊的問題並不可觀；真正的問題在於一個團隊是否有效率。

我所能做到的最接近強迫配對程式設計的事情就是說，如果你想學習如何進行 XP，你應該嘗試配對程式設計，看看它是否適合你。

我不需要嘗試配對，因為我知道我不會喜歡它。

此陳述的問題在於許多人對配對程式設計感到驚訝。他們嘗試了一下，預期會討厭它，但發現他們真的喜歡它。

這一點進一步受到許多人嘗試錯誤配對的影響，這可能會造成錯誤的印象。在角落方塊中被動地盯著某人的肩膀看幾個小時並不是配對程式設計。確保你找一位真正了解如何指導你的人，這樣你才能確定你正在評估真實的東西。

配對程式設計將開發人員的生產力減半。

我對此的輕率回答是：「如果程式設計中最困難的部分是打字，那會是真的」。

配對程式設計的倡導者之所以成為倡導者，是因為他們相信一對實際上比兩個獨立的開發人員更有生產力。這是由於配對引入了持續的討論和審查。你會想出更好的設計，犯更少的錯誤，並讓更多人熟悉程式碼。所有這些事情都抵消了打字的人較少的問題。

當然，由於我們無法衡量生產力，我們無法確定。我的看法是，你應該嘗試一下，團隊應該思考他們是否覺得配對比不配對更有效率。與任何新實務一樣，確保你留出足夠的時間，這樣你就有很大的機會跨越改善鴻溝。

只有在複雜的程式碼上配對才有價值，死背程式碼沒有任何優勢。

我認為這一點是有道理的，配對是關於改善設計和將錯誤降到最低。簡單編寫的死背程式碼幾乎沒有機會讓配對發揮作用。

除了這一點：撰寫無聊的死背程式碼是一種氣味。如果我正在撰寫無聊的重複程式碼，這通常表示我錯過了一個重要的抽象，而這個抽象將大幅減少需要編寫的死背程式碼量。配對將幫助你找到那個抽象。