l

2010年3月10日 星期三

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

03/10 21:51~23:48

螢幕截圖 2016-04-29 15.52.59

▲圖片節錄自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」比較討喜,而且還是在變回人類之後。

2 則留言:

  1. 嗯..沒有人會把「代價」當做是完成一件事之後得到的好處...把代價改成「報酬」或「回報」之類詞會比較符合文意

    回覆刪除
  2. 樓上的好心人:

    您也看出來 Teddy 文章寫到最後已經頭腦不清,開始胡言亂語了。謝謝您找到一個 bug,已修正。

    回覆刪除