我做过的软件项目中，曾经梦想有一个明星可以带领项目勇往直前，突破艰难险阻最终交付一个好的产品。虽然我从事的项目基本都交付了，可整个过程不能说都很顺利。我一直怀疑，那个明星没有到来。
可是，我现在明白了，那个明星可能永远不会来。最终，我们发现那个明星就是我们自己，我们只能靠自己。
我们曾经靠大量加班，积极努力的开发和修补bug来完成软件系统。曾经由于赶进度，并且是新的团队，完成了有大量bug的系统，每个sprint忙个不停，功能多到写到凌晨4点（仍没有写完）。开发出来的系统不稳定，让客户验收自然满意度不高。然后就每天忙于“擦屁股”，我们希望通过测试改善软件的质量，可是上线之后就补测试的愿望从来就没有去做。这个问题是个普遍的问题，结果导致了大家都认为单元测试很重要，但是都不写测试。
最近对极限编程（XP，Extreme Programming）的了解，让我意识到，XP可以让一个普通的团队也能打造出优秀的产品，这里的优秀，说的是bug比较少，并且功能按照预先的定义完成，项目进度也能按照计划完成。
我们目前刚开始实践XP，其中有两个很重要实践是结对编程和TDD（Test Driven Development，测试驱动开发）。
结对编程
XP倡导计划任务时按照结对时间来估算，如果团队有6个开发人员，每天编码时间4个小时的话，那每天的结对编程时间就是12小时，而不是24小时。
你可能觉得一个人写代码，另外一个人看着，这样效率会降低一半，实际上从Kent Beck的经验来看，结对编程的工作效率是超过一个人工作的两倍的，这一点也得到了其他XP实践者的认同。
另外，两个人一起写代码，不但可以实时review代码，消除了大多数潜在的bug，也是互相学习的过程。另外，还能让编程工作更加专注，平常分心去看看社交网络的习惯也被改掉了，总不能在同事面前去玩社交网络吧。
我们第一次结对编程就感受到了它的强大的力量。通过结对编程，我们对需求不清楚的地方进行讨论，改善设计；我们对一些新的知识一起搜索，一起解决问题和共享知识；我们对一些编程习惯进行交流，提高个人编程效率；我们对如何写测试进行讨论，让我们对需要什么样的设计有更清晰的了解。
TDD
TDD遵循“写测试 - 让测试通过 - 重构”这样的循环进行。这是一个反直觉的实践，因为我的代码还没写呢，测试啥啊。直到我实践了之后我才感受到了它的强大的威力，测试相当于功能描述和代码之间的一个桥梁，可以帮助我们思考我们需要实现一个什么样的功能。
写测试，就是写我们需要如何用代码实现一个功能，是对代码的描述，比如一个表单提交成功之后需要显示一个消息。如果我希望这个消息是一个消息组件Message来实现的话，那我可以写：
expect(container).containsElement(Message)
上面是一个伪代码的测试用例。虽然我还没有写任何的关于Message这个组件的代码，但是我的测试已经写完了，毫无疑问，这个测试运行起来是肯定会失败的。
之后我们就可以添加Message这个组件，让测试通过。
最后，我们可以持续重构，完善这个组件。在重构的过程中，因为有测试在实时运行，所以我们可以知道我们写的代码有没有错误。
一旦完成了重构，我们的这个任务也完成了，通过这个过程也极大的增加了成就感和安全感，我们知道，有了测试，基本不会出现什么bug了。
通过不断的进行XP的实践，我相信，就算普通的程序员团队也能产出优秀的产品
，让我们拭目以待。
最后
你们团队在用XP吗，你最大的收获是什么？
