【IT168 技术文章】

    结对编程的根本思路是改善开发团队内部的沟通质量。在实际情况中，不同的开发团队面临着不同的沟通问题。那么，该如何找到一个共通的指导思路呢，又该如何根据实际的情况进行调整呢？

    成本权衡和策略选择

    从上一篇文章的讨论中，我们可以了解到，由于现实的因素，做到理想化的结对编程往往会有很大的阻力。这个时候，我们可以根据实际的情况进行调整，选用不同的方式。但我们如何评估这些方式的成本呢？设计结对，测试结对，复审结对等等的变通方式都存在一个问题：就是表面上看起来它们似乎既达到了结对的效果，又节省了成本。但是实际上，这个成本并没有节省，而是转移了。

    在项目中，为了令结对编程的思路更容易令人接受，我们采用了变通的做法，在设计和复审的时候结对，编码则由单个开发人员负责。A和B针对某项需求进行了2个小时的设计讨论，然后由B负责编码。但是B在编码的时候发现原先的设计存在考虑不周的情况，他决定对设计进行一些修改，这时候，他想通知A，但是此时A不在，于是B根据自己的思路调整了设计，并完成了实现。而在复审的时候，B不得不花上一段时间来向A说明设计变更的原因和细节。 

    注意到，这个过程中，A和B不进行结对编码而节省的时间其实是转移到复审上来了。当然，复审上花费的时间可能要比编码的时间短得多。但是我们还必须看到，如果B变更后的设计也存在缺陷，A和B仍然需要花费一定的时间来改进设计和实现，这种情况也是有很大的可能性发生的。

    对结对编程的成本进行讨论并不是要下一个定论。对于不同的组织而言，这个成本是不确定的。对于某一些组织而言，理想的结对编程也许非常的合适，但对于另外一些组织来说就未必。重点在于，必须找到一种方法，使得团队之间的沟通能力得以增强。

    不同团队进行结对方式设计的时候的标准只有一种，就是如何改进沟通质量。不同的团队有着不同的沟通问题。找到这个沟通问题，才能够对症下药。有这样一个软件组织，他贯彻结对编程的思路很简单，就是为了减小人员流动对业务的影响。经过研究，我们发现这个组织有这么一些特点：产品经历过数代的演化，结构复杂；开发人员仅对自己负责的模块比较了解，全面掌握系统的人极少；产品拥有固定的客户群，客户时常有修改的需求；任何一个开发人员的流失都意味着他负责的模块在一段时间内无人接手；相对于模块无人负责的尴尬境地，增加一个开发人员的成本是可以接受的。在这样的一种情况下，该组织要求任何一个模块都必须有两个开发人员负责。事实上，采用了这一方法之后，人员并没有翻倍，因为维护老产品和开发新产品的工作是并行的，而且，同一个开发人员不仅仅只负责一个模块。虽然人员增多了，但是客户的满意度提高了，而开发力量也同时得到了增强，这个结果还是令人满意的。

    可以看到，在这个例子中，结对的方式并不是XP中所描述的结对编程，它只是一种组织形式，但是在解决沟通问题上，两者的思路是相类似的。同样的，我们如果希望在自己的组织中应用结对，那么分析自己组织的沟通瓶颈的工作是少不了的。

    设计结对

    设计结对的含义是某一模块的设计由双人完成，这里的设计并不是大规模的软件设计（对于大规模的前期设计而言，我们更倾向于让团队设计，请参看敏捷架构设计一文），而是在某个特性在编码之前的设计，这种设计的特点是持续的时间很短（只有几个小时或是几十分钟），但是对于整个代码的质量而言非常的重要，因为我们需要保证设计符合架构的原则，以及设计的灵活性，一致性等等，还需要保证设计的性能和速度。而某个特性在设计完成并进入编码之后，这部分特性就已经确定下来了。因此这种小规模的设计往往是软件开发中比较重要的细微点。在设计上配置双人，能够有效地提高代码质量。这种结对的思路是把成本花在关键的部件上，但是小规模设计结对的具体表现往往是两个人对某个问题的某种看法，他并不能以代码或是模型的形式来体现，对非编码者一方的约束比较小，而代码实现很可能和设计有所出入，这样，非实现者也难以获得这方面的知识。这种方式如果单独使用，容易演变成一种形式，效果并不是很好。因此，我们需要其它结对方式的配合。

    测试结对

    这里的测试结对专指单元测试结对。结对的基本思路是A和B就类轮廓（类结构和公有方法）达成一致后，A编写测试代码，B编写代码来满足测试。如果B对设计的理解有误，那么代码一定通不过测试，如果A对设计的理解有误，B必须通知A重新编写测试。如果对XP的单元测试的改变非常熟悉的话，采用这种方式会有不错的效果。首先，测试代码本身就是小规模设计，而且它以一种规范的编码形式反映出来。只要测试代码足够优秀，它可以捕捉很多的设计缺陷。其次，这种方式是测试有限的一种变体，但是其效果要优于单个人的测试优先。因为一个人思考测试和设计难免有考虑不周的地方，但是如果两个人来考虑的话，测试往往能够发现出更多的问题或缺陷。刚开始使用这种方式的时候，可能会有些不习惯，但是熟悉之后就会比较顺利。

    复审结对

    设计结对和测试结对都是在编码活动开始之前进行结对活动。但是复审结对则是在编码活动完成后进行的。A在B完成代码之后，需要对代码进行复审，复审的内容包括，代码是否体现了设计的意图，代码中是否存在缺陷，代码是否满足需求，代码是否符合一致性原则。一般这种复审都属于同级复审。当然根据我们下文中讨论的组织风格，也可以让有经验的程序员对没有经验的程序员进行指导。复审结对对软件过程的最大意义就在于它形成了一个持续复审的体制，它保留了复审制度的优点，而且可以克服复审制度中的缺点。例如花费时间长，遭至开发人员的反感，不能够进行彻底的复审等等。

    这三种方式的结对可以单独实行，也可以配合实行。这三种方式虽然都不是完整的结对编程实践，但是尽可能的获得了结对编程好处，而成本是相对低廉的。刚开始实施结对编程或是没有足够的资源采用结对编程的，可以采用以上的变通方式。

    结对编程的组织风格

    结对编程并不是抓阄。成员的组织是需要一定的技巧的。基本的操作思路是，先找出沟通的关键性问题，然后针对问题入手，组织人员。举一个例子来说，对于某个项目而言，参与的开发人员经验较少，开发人员对组织的开发模式不熟悉，对开发的目标领域也同样不熟悉。主要的工作任务都压到了经验丰富的高级程序员身上。为了解决这个问题，在项目的头几次的迭代中，强制实行了配对制度，配对的基本思路是老手带新手，配对的实现是老手编写单元测试，要求新手实现，并共同进行代码复审（即采用测试结对和复审结对两种方式）。在完成一个小模块之后，老手就需要更换他的搭档，以保证在前两个迭代完成的时候，新手能够较为独立的进行开发工作。一开始的进度非常的不理想。老手也有着不同程度的怨言，认为这是在耽误时间。但高层管理人员听取了项目负责人的汇报之后，表示支持这种做法。在所有的新手都和老手搭配过后，情况有了很大的变化。系统的开发速度明显加快，团队内已经形成了密切沟通的氛围，老手们能够腾出手进行更复杂的设计和质量控制，更令人惊喜的是，已经有两名新手快要接近老手的水平了，这意味着，下一轮的结对编程过程中，他们将扮演当老手的角色。

    这个例子告诉我们：

    *针对重要的沟通问题实行结对编程
    *一次解决一个问题
    *结对编程的形式是针对沟通问题和环境特点而设计的
    *优秀的实践必须坚持才能够有效果

    这是一个非常典型的组织风格，可以适用于很多的软件项目。它充分体现了沟通的重要性。更多的组织风格还包括：

    *培训性项目。有时候这种项目也被称为摸索性项目，项目的最大目标就是为了研究和试验某些技术，以便在软件组织内部推广该技术。在这种项目中，知识的探索和研究往往要比成本更重要，因此可以采用结对编程的形式。
    *质量控制。软件开发的过程中，往往会有设计的核心部分。这部分的设计要么关系到软件的整体结构，要么就是代表了客户最为关心的需求。这部分的软件设计的好坏，将会直接影响客户对软件的看法。因此这部分的设计是值得投入双倍的开发力量的。而在很多的项目中，我们发现很多开发人员并没有意识到这一点，对开发人员来说，可能只是一些微不足道的错误，但这些错误有时候就会让客户留下非常不好的影响。因此，识别软件中的重要部分并投入更多的开发力量，往往能够令最终的软件质量有很大的提升。
    *轮岗制度。研究表明，即便是知识管理做的再好的组织，仍然是有大量的知识是保存在人脑中的。而为了不形成一个个的信息孤岛，最好的信息流转的方式就是沟通。轮岗制度，或者说是Cross Training，正是为了解决这一问题而设计的。轮岗制度解决的另一个问题是，保证你的团队中既没有忙的团团转的人，也没有闲的发慌的人。这是管理着重要解决的问题，而轮岗制度可以很好的解决它。