简单设计
XP团队建构软件系统为一个简单的设计。他们从简单开始，并且在整个程序员测试和设计改进过程中，他们保持着简单的设计。一个XP团队保持着设计总是刚好适合系统当前的功能要求。这里没有多余的投入，并且软件系统总是为将来做好了准备。
在XP中设计并不是一次性完成的事情，也不是一件从上到下的事情，它是自始至终的事情。在发布计划和迭代计划中都有设计的步骤，在快速设计过程中集合了团队的能力并且在整个项目过程地构中改进设计。在类似于极端编程这样的递增和迭代过程中，良好的设计是本质。这是在整个开发过程中必须更多的关注设计的原因。
成对编程
在XP所有的产品软件都是由两个程序员并排坐在一起，在同一台机器上共同完成的。这个实践保证了所有的产品代码都至少有一个其它的程序员进行了审视，而结果是更好的设计，更好的测试和更好的代码。
让两个程序员去做“一个程序员的工作”看起来有些效率低下，但是实际上刚好相反。研究表明成对编程在让程序员们单独工作相同的时间内会得到更好的代码。这证明了：两个头脑加在一起比一个好得多！
很多程序员在还没有尝试过的情况下就反对成对编程。这确实需要一些实践来做好它，而且你需要认真地实践数周以上的时间来看到结果。百分之九十的学习过成对编程的程序员都会喜欢这样，因此我们向所有的团队强烈推荐它。
除开提供更好的代码和测试之外，成队也提供了知识在团队中间传递。当成对地程序员交换伙伴时，每个人都会从其它的某个人那里学到新的知识。程序员们在学习，他们的技术在提高，他们对团队和公司来讲变得更有价值。成对，即使它本身在XP过程之外实施，也是每个人的巨大成功。
测试优先开发
极端编程围绕着反馈，而在软件开发中，好的反馈需要好的测试。最优秀的XP团队实践“测试优先开发”，在一个很小的循环中增加一个测试，然后让它能够工作。几乎是轻而易举的，团队提供的代码接近100%都有测试程序覆盖着，在绝大多数情况下这是很重要的进步。（如果你的程序员已经提供了更多的现有测试程序，你会拥有更多的力量。将它们保存下来，他们只会提供帮助的！）
仅仅写了测试程序还是不够的：你必须要运行它们。这里，极端编程也是极端的。这些“程序员测试”，或者说“单元测试”是一个完整的集合，每当程序员们发布任何代码到代码库的时候（成对的程序员通常每天发布两次或者更多次），每一个程序员测试必须能够正确的运行。每时每刻都是百分之百运行！这意味着程序员们可以立刻得到有关他们做得究竟如何的反馈。进一步说，这些测试提供了软件设计改进时无价的支持。
设计改进
极端编程在每一个迭代都关注于提供商业价值。为了在整个项目过程中完成这个目标，软件系统必须有良好的设计。可选择性可能会降低并且最终停滞。因此XP采用一种持续改进设计的过程，称为“重构”，来自于Martin Fowler 的书名，“重构：改进现有代码的设计”。
重构的过程关注在去掉重复（一个低劣设计的明确标志），以及提高代码的“内聚”，还有减少“耦合”。高内聚和低耦合在最近三十年以来被公认为是良好设计的特点。结果就是XP团队从一个好的简单的设计出发，并且总是让软件系统有一个好的简单的设计。这让他们能保持他们的开发速度，并且通常在实际上提高了项目开发速度。
重构自然是通过全面的测试来提供有力的支持的，这些测试用来确认当设计改变的时候不会破坏系统中的任何东西。因此客户测试和程序员测试都是有效的评价因素。XP的实践是相互支持的：他们会比各自独立时更为强壮。
持续集成
极端编程队伍总是保持的系统完全地集成在一起。我们说每日建构版本是为弱者提供的：XP团队每天都要构建系统很多次。（一个40人的XP团队每天至少集成八到十次！）
这个实践的好处可以通过回想你可能听说过的（或者是亲身参与过的）项目来了解：当系统构建是每周或以更低的频率进行时，通常会陷入“集成的地狱”，在那里所有东西都不能运行而且没有人知道为什么。
极少进行集成会给软件项目带来一系列的问题。第一个，尽管集成是发行好的工作代码的条件， 但是团队并不去实践它，而且通常它被委派给那些对整个系统并不十分了解的人。第二，极少集成的代码通常是——我宁愿说总是——错漏百出。
集体代码所有权
在一个极端编程项目中，每一对程序员都可以在任何时候改进任何一处的代码。这意味着所有的代码在很多人的关注下获得更多的收益，这样就提升了代码质量并且减少了缺陷。这里还有另外一个重要的好处：当代码仅由单个人负责的时候，要求的特性往往会放到了错误的位置，因为一个程序员发现他需要一个特性但是那段代码却不归他管理。代码的所有者太忙乐而不能去增加这个特性，所以这个程序员只好把这个特性加进了这个特性本不应该存在的他自己的代码中。这导致了难看的，难于维护到代码，充斥着重复和低（差）的内聚。
如果有人在他们所不理解的代码上进行盲目的修改时，集体代码所有权可能带来问题。XP通过两种关键技术来避免这类的问题：通过程序员测试来捕获错误，成对编程则表明在不熟悉的代码上工作的时候非常好的途径是找一个这方面的专家作为伙伴。为了确保在需要是进行好的修改，这种实践将知识延伸到了整个团队。
编码标准
XP团队遵循一个公共的编码标准，因此系统中所有的代码看上去都像出自单独一个——非常有能力的——人之手。这个标准的规定并不重要：重要的是要让所有的代码看上去很相似，用来支持集体代码所有权。
系统比喻
极端编程团队对于程序如何运作形成一个共识，我们称之为“系统比喻”。在非常好的状态时，系统比喻是关于程序如何运作的一个简单的灵魂描述，例如用“这个程序工作时就像一箱子蜜蜂，外出寻找花粉并带回蜂箱”作为一个基于代理的信息查询系统的描述。
有些时候一个十分诗意的想象可能不会出现。在任何情况下，无论有没有生动的比喻，XP团队都会选用一个公共的命名系统来确保每个人都能理解系统是如何工作的，以及到哪里去找到你所需要的功能，或者找到你要增加功能的正确位置。
可接受的步伐
极端编程团队都会在这里很长的一段时间。他们努力的工作，并且在一个能够不断维持的步伐下。这意味着在有效的时候他们会加班工作，而且他们经常这样工作来保证每周都有最大的生产力。这恰当的解释了死亡竞赛式的项目既不会有生产力也不会创造有质量的软件系统。XP团队在这里是要胜利而不是要死亡。
小结
极端编程是一种以简单性、交流、反馈和勇气为基本宗旨的开发纪律。它的做法是以有效的实践规则将整个团队紧密联系起来，通过充分的反馈使团队能随时知道自己目前的状况和恰当地调节实践规则以适应自己的特殊情况。
