【文思不藏私】@千萬不要『結對編程』
4 min readSep 7, 2017
首先，這一篇是教你『不要用結對編程』（Pair Programming）的文章。所以，裡頭說的全都是不要使用『結對編程』的原因及時機。千萬不要期待聽到『結對編程』的好處，因為這條路不可行。
- 如果你的工作已經使用『結對編程』，這酸文不對你味，請左轉下樓。
- 如果你對『結對編程』一直很有好感，這頻道不適合你，請右轉下樓。
- 如果你對『結對編程』很有疑問，對了！就是這個光，這就是你要看的。
千萬不要『結對編程』的原因？
- 效率第一：靠，兩個人同時討論一段 code，是有比較有效率嗎？
- 成本第一：馬的，花兩個人薪水只做一件事，你以為錢從天上掉下來嗎？
- 專家第一：Shit，資深，懂是應該的。資淺，不會要自己去學啊？
- 嘴砲第一：屁啦！這個問題是有多難，要兩個人寫，想當初。。。？
- 個人第一：滾啦！Facebook 要讚， LINE / YouTube 要看，很忙耶？
非得要『結對編程』的原因
- 品質第一：對於『結對編程』的態度，我處於一種是『效用』優於『效率』的心態。實驗數據證明，兩個人『結對編程』大約是會多花 15% 的時間。也就是原本一個人花 100 分鐘的時間，『結對編程』約需要花 115 分鐘（總工時是 2 * 115 = 230）。但是 code 的 defect 也少了 15%，以後再花時間解 bug 的時間也可能被省下來。而且 code 的行數也會少了 15%，更精簡易懂的程式你不想要嗎？程式的複雜度通常與程式行數成正比（指數成長）。那你覺得『結對編程』對『產品的品質』有助益嗎？
- 產能第一：想像一個獨立作業的場景『15 分鐘寫 code，15 分鐘查資料，20 分鐘看 Facebook，10 分鐘回 mail/LINE』。想像一下『結對編程』的場景『25 分鐘寫 code，15 分鐘查資料，10 分鐘討論，10 分鐘打屁聊天』。不要以爲這情景很陌生，你可以試著統計看看。同樣是 1 小時的時間內，那你覺得『結對編程』對 『團隊的產能』有幫助嗎？
- 知識第一：傳統的單兵作戰，會慢慢的塑造出團隊的『超級英雄』出來，能力越強也表示責任越重。『結對編程』可能可以讓『超級英雄』的知識透過結對的過程中慢慢的讓資淺的成員吸收，也是一種『蜜蜂授粉』群體擴散的知識分享過程。當英雄請假時，當時受惠的成員就可以提槍上陣（因為有結對學習，此時武器、戰技也都具備了）。『經驗』有些時候不一定是『資深』遠勝於『資淺』，但透『結對編程』資淺可以有機會秀幾招『新學的招式』給資深看。資深可以『分析』不同做法的優缺點給資淺學。『學了』是一個程度，『懂了』又是另一種程度，『教了』才是融會貫通的程度。那你覺得『結對編程』對『團隊的知識』有幫助嗎？
- 默契第一：團隊中最有效的 Team Building 通常是發生日常工作中，而不是刻意製造的活動。『結對編程』讓團隊成員的溝通變頻繁了，讓彼此的技能程度能互相拉升。那你覺得『結對編程』對『團隊默契』有幫助嗎？
不要『結對編程』的時機
- 兩個完全不懂的，千萬不要搞在一起。首要之務，是讓他們懂或讓他們學。可以找懂的跟他們 pair 或者懂的慢慢教他。
- 兩個會吵架的，千萬不要搞在一起。先解決他們的情緒問題吧！
- 需要花時間 Survey 的，可以 pair，但是分頭進行可能比較好一點。
- 兩個人都很『熟悉』或『簡單』的工作，千萬不要結對搞在一起。我個人認爲分頭進行，分進合擊，快點幹掉吧，『結對』的性價比（CP 值）不一定很高。
結論
哈！哈！看完後有沒有更是一頭霧水，因為這是一篇『反串文』啊。請不要樣樣都『結對』，團隊成員有些時候也需要一點時間自學或反思啊！
你可以試著跟異性同事說『嗨！我們結對去上廁所，好嗎？』看會不會有什麼結果？
感謝你認真的讀完這篇文章，你的支持會是我持續寫作的動力
如果你還喜歡這篇文章請給我 1~4 個『掌聲』
如果這篇文章對你有幫助請給我 5 個以上『掌聲』
如果你對我這一系列文章有興趣歡迎『Follow』我或『分享』給你的朋友
也歡迎你將你的看法『回覆』給我
