共同拥有程序代码，可以降低维护的困难，还可看看其它高竿的家伙如何解决问题。如果你的开发项目没有程序代码权限控管的问题，那么推行程序代码共有，肯定能为团队带来益处。

设想一个情境：和你一同开发某个系统的同事请假了，不幸的是，这个系统临时发生了一个严重的问题，必须在最短的时间内修正，但无论如何也无法连络上这位同事，这种情况该当如何？

倘若只有这位同事了解详情，其余的人即便手上能存取出了问题的程序代码，面对错综复杂的逻辑，不见得能在短时间内理解。而且，贸然地动手修改，一来不见得能解决问题，二来就算能解决眼前的燃眉之急，由于软件的高度复杂性，也很有可能引发意料之外的副作用。

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网络电话，都在他的涉猎范围之内。