Shared Code：讓我們變成博格人吧

03/10 21:51~23:48

▲圖片節錄自Google搜尋結果

在「星艦迷航記」系列的影集裡面可能有幾千種不同的種族， 其中最厲害的應該就屬「博格人」。博格人可以直接同化其他種族，把他們的知識直接吸收過來，形成一個集合體（宇宙中數十億的博格人都擁有一個共同的集合意識）。由於博格人擁有集體意識因此能夠有效地協調分派工作，而博格人做事情在宇宙間也以『高品質，高效率』著稱。

XP 裡面有一個 practice 叫做 shared code (原本叫做 collective ownership)，大意就是說專案的程式碼屬於所有開發人員所共有，無論程式原始的作者是誰，只要大家看到程式中有問題或是設計不良的地方，都可以動手修改。數年前 Teddy 看到 collective ownership 這個作法，直覺就想到難道這是在模仿博格人的『集體意識』嗎？在軟體開發中，collective ownership 的概念讓 source code 成為所有開發人員的『集體意識』，這個「集體意識」（source code）由所有的開發人員所貢獻，維護，成長。這種作法至少有以下三點好處：

1. 高品質的 source code：由於 source code 是大家共同擁有的，因此有很多雙眼睛盯著它。當開發人員把自己寫好的 code 貢獻進去這個『集體意識』的時候，如果程式寫得太爛，也會怕別人看到會偷笑。所以，潛意識中不知不覺就會想把程式設計的好一點，code 寫得乾淨一點。這就像就算你家裏亂的跟豬舍一樣，當朋友到你家作客的時候，總是要稍微打掃一下，留點名聲給別人探聽的道理是一樣的。其次，因為任何人有權只要看到『集體意識』有不良成份，就可以直接改善，因此長久下來品質自然會變好。最後，當你發現原本你所寫的程式被別人改過之後，你也學到了如何把程式設計的更好的技巧。當然也有可能是被你的同事越改越爛，此時就換你機會教育對方了。總之抱持著『互相漏氣求進步』的精神就對了。
2. 提高工作分派的彈性：幾乎所有的軟體開發方法，都會告訴我們要挑選最優先的需求（通常是對客戶價值最高的需求）來開發。理論上是如此，但實際上卻很難。為什麼？假設現在客戶覺 UI 很難用，要求做出容易操作的系統。此時可能絕大部分的工作都和 UI 的開發有關。如果 source code 是大家的，通常表示每個人或多或少都有能力處理不同模組的程式。所以長期下來，因為開發人員專業分工不同而導致派工困難的問題就會比較少一點 （但也許不可能全部消失）。另外，團隊也比較不會因為某人請假，而導致功能無法開發的問題。放假的人也可以放心去休假，不用怕被電話騷擾。萬一團隊中有人離職，對於專案的影響也會比較小。
3. 提昇開發人員的技能：由於 source code 是大家共有的，因此開發人員有機會可以輪流開發不同性質的程式，長期下來可以提高自己的專業技能。這樣可以避免開發人員長久下來都做同樣的事情，造成工作疲乏的現象。

看到這邊，相信很多鄉民必然抱持不贊同的態度。因為大家都習慣把程式當成自己生命的某種延伸，寫程式也都會有特定的習慣，如果把對於程式的界線或是控制權開放出去，這樣到時候被亂改一通，倒楣的還不是自己？對老闆而言，shared code 更是『違反祖制，大逆不道』的行為（來人啊，拖出去斬了）。程式碼沒有 owner，到時候出系統問題（而且一定會出問題）老闆要找哪一個倒楣鬼負責？

在傳統的心態下，同一個團隊的人，每個人負責若干的模組，界線劃分的非常清楚。好處是，由於你一直在做類似的工作，你這一項技能變得越來越強，因此看起來你的工作效率也越來越高。另外，乍看之下責任很清楚，哪個模組有問題就找那個負責人。這樣做的缺點是，每個人矇著頭各做各的，程式的品質好壞通常沒有人關心（除非團隊有持續做 code review... 不過應該很少）。當你遇到問題的時候，由於你的同事正好也在忙著他自己所負責的模組，所以通常沒有時間也沒有很大的熱誠來幫助你，因此你需要花費更久的時間來自行摸索。另外，開發人員萬一離職對於整個專案的影響就比較大。由於每個人的地盤劃分得很清楚，要是你不小心踩到別人的地盤，例如問了一句：『這個功能怎麼會需要做那麼久』，那麼你很可能被反嗆一句：『你那麼厲害不然你來做好了』。最後，大家各自負責的結果，可能導致『整合』的問題沒有人管。每一個人負責的模組都宣稱沒有問題，但是整合起來就有問題。那誰要管？

當然，要實施 shared code 也是有它的困難。大家都聽過『三個和尚沒水喝』，如何確保這份『集體意識』不會被越改越亂而又沒有人要負責？Teddy 目前的經驗如下：

1. 剛開始的時候，還是採用傳統的方法，每個人依據專長或興趣分配到若干個專案。
2. 要盡早導入持續整合，確定不同的模組可以整合在一起。
3. 要求開發人員一定要寫 unit tests。
4. 等系統雛型大致穩定之後，鼓勵大家 pair programming。在這個過程中，由不同模組的創始人帶另一個開發人員，讓他可以慢慢具備接手的能力。平均起來這個過程最短通常也需要1~2個月。
5. 持續下去，至少達到每一個模組至少都有兩個人非常熟悉為止。

要達到團隊成員全部都完全了解整個 codebase 是很不容易的一件事，但是只要肯做，一定可以慢慢地朝向這個目標邁進。這是一條有點艱辛，緩慢，且遙遠的路程，不過報酬卻是十分豐厚。這麼說好了，就好比要去『西天取經』，亦或是『魔戒遠征隊』，出發之前大家都知道旅途十分凶險，達到目的地之後卻可以拯救世人啦。


友藏內心獨白：當博格人又不好，博格人當中只有 Voyager 的「 7 of 9」比較討喜，而且還是在變回人類之後。