联合两人的知识去对付一个难题。

知识互相传递。

更有效的查错跟纠错。

程序员都很开心。

减少员工离职的损失。

结对编程需要的一些技能：

用代码解释已有的设计结构。

用例子来解释。

用图表来解释设计思路。

如果你无法把你的设计思路表达清楚，把代码写出来。

让比较迷惑的搭档来写代码，这样他就可以较好的融入你的概念。

经常的休息。

经常的更换搭档。

TDD及它的优点

    上面这种编程的方式，就叫“测试驱动编程Test Driven Development (TDD)”，因为我们总是在写真正代码之前写一个通不过的测试，然后再写真正的代码，让测试通过。

    跟测试后行的开发方式相比，它有如下好处：

    1.为了更容易的写单元测试，我们会广泛的使用接口（比如StudentRegistryChecker等）。这个会让单元测试代码很容易读跟写，因为测试代码里面没有多余的数据。如果我们不用TDD而是直接写实现的话，我们经常会使用现成的类（比如StudentSet），测试为了调用现成的类，就不得不创建很多多余的数据，创建很巨型的对象，就像Student或者Course。

    2.因为广泛的使用接口，我们的类之间就不会藕合（比如EnrollmentSet就一点都不知道StudentSet的存在），因此重用性更好。

    3.写单元测试的时候，很容易就可以为一个行为写一个测试用例，让它通过，然后为另一种行为写另一个测试用例。也就是说，整个任务会被划分成很多小的任务，独立完成。如果我们不用TDD而直接实现的话，我们很容易就会同时把所有的行为都实现了。这样花的时间长，而且在这相当长的时间里面，写的代码都是没有测试过，不能保证准确性的。相反的，用TDD的话，我们只实现要测的行为的代码。它只花费很少的时间（几分钟），而且可以马上测试。

因为在这些卡里面，我们写上了类名，它的职责，以及它的协作关系，我们管这样的卡片叫“CRC卡”。CRC就是Class，Responsibility和Collaboration的简称。

CRC 卡的典型应用　

为什么用CRC卡，而不用文档或者更先进的UML工具？

1. 卡片上面的空间很小，这样就可以防止我们给这个类太多的职责。如果一个类的职责太多的话（比如，超过4个），尝试以更抽象的方式去考虑一下，将职责划分。

2.CRC 卡主要是用在探索或者讨论类的设计的阶段。如果我们觉得这个设计不行的话，我们既不用修改文档，也不用修改类图，只要把卡片丢了就行了。此外，一旦设计完成，我们就可以把所有的卡丢了。它们不是用来做文档的。

   3. 如果我们觉得现在的卡片不合适，之前设计的比较好，我们只要简单的把之前的卡片拿出来组合就行了。

什么是用户例事 (user story)

假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。

因此，我们的客户就是他们的市场经理。谈需求的时候，有一回他这样说：“用户往售货机每塞一个硬币，售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时，代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给他。”

上面的话描述的是一件事情，一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。这样的过程就叫“用户案例 (user case) ”或者“用户例事 (user story) ”。也就是说，上面我们的客户所说的话，就是在描述一个用户例事（ user story ）。

( 我解释一下为什么用例事这个词，没兴趣也可以忽略。在一个系统面前，每个用户要完成同样的目标，都要做这个系统设定的例行的事，这件事情不是一个例子，所以不叫事例，这也不是故事，也不能算一段历程，而是一个例行的事。 )

　pdf下载地址：　第8章以用户例事管理项目.rar