其次，代码复审的难度加大。代码复审是非常重要的工作，但是代码的混乱将会加大代码复审的难度，因为复审小组的成员不得不花费时间来了解代码的风格，并做出指导。更糟糕的是，代码复审小组的成员往往都是软件组织中的重要成员，他们的时间都代表了高昂的成本。也许没有人仔细计算过这样的成本，但是这些成本累积起来，也会是一个令人吃惊的数字。
再次，项目风险和组织风险都随之增大。这种在以项目开发为结算单位的软件开发组织中尤为明显，因项目开发人员离开而导致项目源代码难以维护的情况非常的普遍。对于已经完工的项目而言，这使得项目维护成本上升，对于尚未完工的项目而言，这会打乱现有的项目进度，导致项目进度的延后。
最后，也是致命的一个问题，内部沟通难以有效的进行。软件开发不是一个单独的活动。优秀的程序员组成的团队未必就是一个优秀的团队。究其原因，大部分都是因为沟通不善造成的原因。组织内部的知识很难形成流动，开发人员之间难以共享知识，而新成员也无法从经验丰富的老员工那里学习。
沟通不畅最终会积累形成组织软件设计平均水平无法提高的问题。软件设计属于脑力劳动，但是个人的知识覆盖程度和思考能力都有限，个人的设计往往都是有缺陷的，而雇佣大师级的开发人员的成本是相当高昂的，并不是所有的软件组织都能够像IBM或是微软那样雇佣大量的优秀人才。因此面对有限的人力资源（数量和质量两方面），关键的问题就在于如何让有限的资源发挥最大的作用。
软件工艺
在参与一家软件组织的代码复审之后，我加入了这一小节的内容。既然是工艺，当然是一些很细微的环节，例如浏览集合的写法、类和方法的命令、注释的规则等等。这些都属于程序员自身修养的部分，但是很多组织恰恰是在这个环节上存在问题。编码的随意性导致了代码可理解性的下降，为团队共享代码设置了障碍，没有人会主动的去看别人的代码。在前面我们说代码的混乱会导致复审的困难，而代码混乱同时产生的另一个影响，就是软件组织的平均软件工艺水平无法提高。虽然每个程序员都希望能够编写优美的代码，但编写优美代码需要一定的毅力和时间，尤其是在项目时间压力大的时候，代码的优美性常常是被忽略的。但是，强制要求代码优美性并不容易实现，需要监督的成本，效果也难以令人满意。
结对编程可以从组织结构上缓解这个问题。程序员大多是骄傲的，如果有一个同伴在身边，那程序员可拉不下脸来编写难看的代码。这是很有意思的现象，但是挺有效的。程序员通过这种方式，可以相互促进，提高编程工艺水平。虽然软件工艺解决的都是一些微小的问题，但是正是这些问题，最终影响到了软件的质量。从代码管理的角度上来说，管理的基本任务都是这些"小问题"。
过程保证
结对编程可以在有效的解决这些问题的同时保证成本最小，这是结对编程之所以成为结对编程而不是三人编程的原因。在硬件设备的运行过程中，单点故障的最好解决方法是双机备份。这一思想运用到团队和过程上就形成了结对编程的基础。我们见过一个软件组织实施结对编程的初衷是为了保证产品的安全性，在产品的各个重要部件上都至少配备了两位负责人。一开始他们没有意识到他们朝着结对编程迈出了第一步，后来他们发现这种方法非常的有效，并针对这种方法进行扩展，形成了完整的结对编程体系。
在传统的软件开发中，一般都会在软件过程中建立几个检查点（Check Point），在这个点上，软件的各个部分都需要进行检查，设计是否符合规范，是否满足需求，程序中是否存在缺陷。但是在每个Check Point上花费的时间往往是非常可怕的。每个CP上花费的工作包括：
文章来源于领测软件测试网 https://www.ltesting.net/
