讀處

Pair programming 是由XP發明人Kent Beck提出來的概念

簡單來說，就是兩個人共用一台電腦，一起開發軟體

一個人做為Driver 就是操作電腦的人,

另一個人則為Navigator也就是出一張嘴告訴driver要做什麼

由於我們指導教授非常推崇"一起寫程式"，

因此我們實驗室除了採用Pair programming以外，還採用了Mob programming

所謂的Mob programming就是一群人用一台電腦，一起開發軟體

▲這就是我們Mob programming的實況，我們實驗室現在買了好多台大螢幕

採用Mob programming就更為方便了

在我們實驗室中，除了我參與的ezScrum專案採用Pair programming以外，

其他專案都是採用Mob programming

某天早上我們在吃早餐時，我把我的partner叫過來說我們邊吃早餐邊聊個天

我說很多人對於Pair programming都有所質疑，

大家都覺得採用Pair programming會降低開發速度

人力都不夠了，還兩個人一起寫程式

我們的指導教授非常推廣Pair programming以及Mob programming

那麼如果有人對於Pair programming有所質疑時，又或是你今天要說服老闆採用Pair programming時

我們要如何根據我們採用Pair programming一年時間的經驗去告訴別人Pair programming的好處

我們統結了一下如下:

1. 可以互相監督 :

這當然是往不好的面向去想，因為兩個人一起寫程式，就能彼此監督，如此就不敢再開發時間去看臉書、追韓劇...

除非...兩個人一起看XD

2. 可以互相學習，技術交流，開發出來的軟體品質通常比較好 :

以經驗談，當成員不知道要做啥，或是不會做的時候就可以和另外一位成員一起討論想辦法解決，

就可以避免掉不知道做啥時再裝忙、瞎忙，或是不知道怎麼做的時候花大量時間查詢資料，

而他在查的東西說不定剛好就是別人已經會的東西。因此可以避免許多時間的浪費。

況且如果大家各做各的，很有可能寫出來的程式碼彼此衝突或是不相容，

在整合上就需花更多時間，也有可能花大量時間在Debug。

3. 當有新成員加入團隊，透過Pair programming能讓新成員快速上手

因此，大家對於Pair programming會不會拖累的疑慮

以宏觀來看，當然是不會啊!!

後來我跟我的partner說，最後可以再丟一句話給老闆:

如果你是一個短視近利的主管或是老闆，那你就繼續不要採用pair programming 吧!

當然...站在主管或老闆面前我們肯定不敢說的XD

所以只能在這邊打打嘴砲 哈哈XD

不過後來我自己又再想想...會不會不是老闆或主管不願意採用pair programming阿!?

說不定是工程師本身不願意採用，因為其實採用pair programming精神壓力相對比自己開發來得大啊

(畢竟不能偷懶....)

不過在這邊可以建議可以開發一段時間就休息一下

或是可以小聊一下，緩和氣氛(我常這樣 哈哈!)

有一本書《大腦喜歡這樣學》，裡面談到人的大腦分成專注模式以及發散模式

發散模式是離開專注模式，當你專注一段時間後可以休息一下，再回來工作

我不知道大家有沒有和我一樣的經驗

就是當寫程式遇到瓶頸時去吃個飯、喝個咖啡或是運動一下再回來寫程式

莫名其妙就把剛剛的難題給解掉了，後來讀了《大腦喜歡這樣學》這本書後才知道原來這就是所謂的"發散模式"

大家有興趣可以去把那本書拿來讀一讀，很有意思的一本書

我後來把這本書的概念分享給我的partner知道後

我常常就會跟他說，我們來進行一下發散模式吧!