程式程式碼共同擁有，有助能力提升

共同擁有程式程式碼，可以降低維護的困難，還可看看其它高竿的傢伙如何解決問題。如果你的開發專案沒有程式程式碼許可權控管的問題，那麼推行程式程式碼共有，肯定能為團隊帶來益處。

設想一個情境：和你一同開發某個系統的同事請假了，不幸的是，這個系統臨時發生了一個嚴重的問題，必須在最短的時間內修正，但無論如何也無法連絡上這位同事，這種情況該當如何？

倘若只有這位同事瞭解詳情，其餘的人即便手上能存取出了問題的程式程式碼，面對錯綜複雜的邏輯，不見得能在短時間內理解。而且，貿然地動手修改，一來不見得能解決問題，二來就算能解決眼前的燃眉之急，由於軟體的高度複雜性，也很有可能引發意料之外的副作用。

XP打破工作切割方式，程式程式碼不再隸屬於特定人
這樣的情況，其實在我們的開發生活中偶爾會發生，而類似的困境其實導因自常見的開發方式。或許你的團隊也是這樣，完成了系統分析、系統設計，接著專案經理將撰寫程式程式碼的工作以某種單位拆解，然後分派給團隊中的每一個成員。

這是相當常見的工作分派方式，我們常常會聽到：「A，你負責這幾支程式，而B，你則負責另外那幾支程式。」之類的話，便是屬於這一種模式。程式程式碼是以「支」為單位，而每個人的程式程式碼編寫工作之間很少有交集，分頭進行，各自埋首完成自己的目標。

只有當程式與程式之間需要相互整合時，你才會和那些一同開發專案的夥伴們互動得較頻繁。但即便如此，每個人多半還是在介面層次上進行整合，因而將對方的程式模組視為黑箱，不會細究其中的內容。

可是，當團隊成員對彼此的程式程式碼冷漠及陌生時，就會衍生出上述的問題。

除了臨時救火之外，軟體開發團隊難免遇上人員流動。只要發生這種情況，多半就會衍生出交接的需求，而這所謂的交接，實際上時常只是形式上的交接。承辦的人員，很難在極短的時間內，真正瞭解他所接收的程式程式碼細節處，究竟是如何構成及運作的。

面對上述的問題，極限程式設計（eXtreme Programming，XP）提出了一個稱為「集體程式程式碼共有（Collective Code Ownership）」的概念。在這個概念下，專案中的每個人都有權力及能力，基於增加功能、修正錯誤，以及重構的原因，更動系統中的每一行程式程式碼。

系統中的某一程式程式碼片段，不再隸屬於特定的一位程式人，也不再只是「某人負責那一支程式」。每個人都應該能夠輕易讀懂系統中的每一段程式程式碼，明白這段是如何運作，知道如何為它新增新功能、如何修正或重構，不致於引發意外的錯誤。在程式程式碼共有的團隊中，發生了緊急的問題時，每個團隊成員都具備能力處理。即使發生了人員流動的情況，其它人也很容易替補上這個人原有的工作。

這聽起來真像是開發團隊理想中的大同世界呀。

真正的程式程式碼共有，需要搭配搭檔程式設計及系統隱喻等準則
這樣的想法，和傳統上我們所習以為常的模式大相徑庭。而這樣子的概念想要在實務上落實，也需要克服不少的挑戰。

在極限程式設計中，搭配許多實踐準則，才有可能達到這個理想的目標。例如，透過搭檔程式設計（Pair Programming），時常變換一起搭檔撰寫程式的夥伴，使得每個人具有更多的機會，去接觸系統中各個面向的程式程式碼。

此外，透過建立系統的隱喻（System Metaphor），讓團隊的成員能以一致的規則，為類別、函式、變數等命名。隱喻最大的作用，在於讓團隊中的成員能夠操弄同一套語言及詞彙，使得程式人們能夠輕易地望文生義。

這套語言及詞彙不僅是共通的命名慣例，更會使得許多特定用語有著特定的意義。例如，設計模式就是一組隱喻，當你看到了名稱中帶有「Factory」、「Proxy」等詞的類別時，你會立即明白它們的作用，而不需要額外多說明。這正是隱喻的作用所在，能夠大大減少溝通的時間，也降低發生誤解的情況。程式程式碼本身將更能自我說明（Self-Documented）。

當然，除了系統隱喻之外，程式程式碼撰寫時的標準也是同等重要。所有的團隊成員都必須依循相同的程式程式碼風格寫作規範（例如編排的程式程式碼準則），這麼一來，每個團隊成員才能無障礙地閱讀及修改。

XP更主張設計要簡化，儘可能地簡化程式程式碼、降低複雜程度，這能提升程式程式碼的易讀性，不造成誤解，當然有助於程式程式碼成為共同擁有。

程式程式碼共有的另一個好處：可以學習到高手的開發手法
XP將此稱為共同認識（Shared understanding）。XP透過上述的準則將程式程式碼與開發成員之間的一對一關係，擴大成為多對多的關係，一段程式程式碼不再為單一開發者所獨攬，所以這位開發者不再成為這段程式程式碼的瓶頸。由於程式程式碼成了團隊所有成員共同擁有，對於系統程式程式碼的認識，會動態而且持續地在團隊中流動。

雖然並非每個團隊都適合實施XP的方式，但這些實踐準則給了我們很好的指引。即使不採用XP的開發方法，我們仍然可以藉由XP的實踐準則，提升程式程式碼的共有程度。

對於程式程式碼，程式人普遍不習慣共有，多半也排斥去修改、甚至是閱讀其它人所撰寫的程式程式碼。但推行程式程式碼共有好處實在不少，除了可以解決上述提到的維護問題，以及人力銜接的問題之外，它也提供一個可能性，讓程式人之間的知識及技巧能夠在團隊中流動，而這一點對團隊帶來的幫助甚大，因為這樣的做法，讓成員間彼此有更多的機會，見識到其它人所撰寫的程式程式碼，並且動手實際操弄。

見識到其它成員是如何解決問題，這是真正的學習，不僅只是那種來自課堂上，或從書本上的學習所得，而是親眼見到其它高竿的傢伙，看他們是如何運用自己所不熟悉的方法及技巧，解決同樣遭遇到的問題。

最好的學習就是從模仿開始
多年以來，我所參與的團隊，都主張讓每個成員寫出一致風格的程式程式碼，目標便是讓每一段程式程式碼看起來都分不清楚究竟是誰所撰寫的。也只有長久堅持這樣，才能夠讓每一段程式程式碼看起來都像是自己寫的。

雖然沒有實施搭檔程式設計，但諸如建立系統隱喻、相同的程式程式碼風格寫作規範，以及簡化設計等XP所揭櫫的準則，都讓我們在邁向程式程式碼共有時，得到相當大的幫助。

即使沒有因為實施搭檔程式設計，而喪失了讓每個人實際接觸到每一段程式程式碼的機會，但是由於實施了其它的做法，使得每個人很容易在很短的時間，都能瞭解別人所撰寫的程式程式碼，並且不易發生誤解，使得功能的修改或擴充，做起來都格外簡單。

我們會互動去修改別人所撰寫的程式程式碼，或是加以擴充，雖然這比不上搭檔程式設計，但也能達到不錯的效果。

在這過程中，新加入的成員得以透過觀摩舊有成員們的既有程式程式碼，迅速融入團隊的文化中，也能學習到自己所不知的技巧及設計方式。

最好的學習就是從模仿開始。模仿舊有成員的做法，可以讓新成員更快上手，也學習得更快、更有效。即使這些年以來，人們來來去去，但我們始終沒有因為人員的變化，而發生交接上的問題。

如果你的開發專案沒有程式程式碼許可權控管的問題，那麼推行程式程式碼共有，肯定能為團隊帶來益處。

作者簡介：
王建興 清華大學資訊工程系的博士研究生，研究興趣包括計算機網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話，都在他的涉獵範圍之內。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-402118/，如需轉載，請註明出處，否則將追究法律責任。