解析极限编程

XP简介

－－极限编程方法学＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝敏捷型方法学的代表；轻量级软件工程方法学；拥抱需求变化；不一样的开发过程；软件工程的历史回顾：＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝自上个世纪60年代以来软件工程思想逐渐形成与发展出现了很多软件开发模型与方法例如：瀑布模型、快速原型、增量模型和螺旋模型等90年代以后，卡耐基梅隆软件学院推出的CMM，更是对于软件开发的过程管理，提出了确切的衡量指标。图表显示：＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝（数据来自美国GSM研究机构,MichaelMah）传统的软件开发过程：＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝以RUP为代表强调项目的可控性是一个用例驱动的基于UML和构件式架构的迭代增量式开发过程RUP定义了初始、细化、实现和部署4个阶段，分别对应着关键里程碑的划分。RUP是可以裁减的：＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝对于角色、流程、工件和活动的要求是灵活、可配置的，所以它广泛的适用于各种类型的项目在RUP的各个里程碑，都规定了要交付的成果，尤其是对于需求的变更以及文档，它强调及时的更新与同步。这些都决定了RUP是一种重量级的软件开发方法：＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝比较适合大中型的项目和产品开发

XP以及其核心价值＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝很多轻量型的软件开发方法例如水晶模型、适应模型以及极限编程等它们都强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用。

XP以及其核心价值＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝KentBeck在XP的开篇之作《ExtremeProgrammingExplained-EmbraceChange》中提出了极限编程这一创新的软件过程方法论。极限编程是一种高度动态的过程，它通过非常短的迭代周期来应对需求的变化。在极限编程中，包括四个基本活动：编码、测试、聆听与反馈XP有四个核心价值是我们应该注意＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝沟通：问题往往是由于开发人员与设计人员、设计人员与客户之间的沟通不畅造成的简单：应该尽量保持代码的简单，只要它能工作就可以与其实现一个复杂的的系统，不如设计一个能够满足目前需要的、简单的系统，因为你所考虑的情况可能永远都不会发生。反馈：尽快获得用户的反馈，并且越详细越好，使得开发人员能够保证自己的成果符合用户的需要。勇气：这是最重要的核心价值。因为XP强调要"拥抱变化"，因此对于用户的反馈，要勇于对自己的代码进行修改，丢掉坏的代码。

XP的适用环境：＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝XP弱化针对未来需求的设计，非常注重当前的简化它的实践，有一个非常关键的假设就是：开发人员只注重眼前需求，依赖重构来适应需求的变动，这样所带来的风险、开销要小于需求变化使得事先充分设计失效的代价；反之，实施XP就是不明智的

XP适用范围：＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝因此,XP适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的代价来满足用户未来的需求，XP在平衡短期和长期利益之间做了巧妙的选择。

XP并不是解决问题的"银弹"：＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝XP方法是一种轻量级的方法，它也有它的适用范围。通常认为：功能需求可以固定的，可以作比较精确的需求设计的，生命周期很长的，超大型软件项目，人员数码十分巨大的（比如上百人）不适于适用XP方法XP不适用的领域：＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝中大型的项目（项目团队超过10人）；重构会导致大量开销的应用；需要很长的编译或者测试周期的系统；不容易进行测试的应用；团队人员异地分布的项目；不能接收XP文化的组织和团队；XP的最佳实践：＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝Xp由大约20来个实践为主要方法指导实践和实践之间结合成有机整体，有的关系紧密有的关系并非很密切。对于实践的感觉就象过去武林高手学成之前的基本功XP的最佳实践＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝代码规范or代码标准(CodeStandards)XP：强调通过指定严格的代码规范来进行沟通，尽可能减少不必要的文档。注：这里和传统的软件工程方法是相矛盾的XP的最佳实践＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝每周40小时工作制(40-hourWeek)不加班，不熬夜XP：要求项目团队人员每周工作时间不能超过40小时，加班不得连续超过两周，否则反而会影响生产率。注：对于项目进度和工作量合理安排的要求就比较高。XP的最佳实践＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝计划博弈(PlanningGame)迭代周期的划分XP：要求结合项目进展和技术情况，确定下一阶段要开发与发布的系统范围。XP的最佳实践＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝系统隐喻(SystemMetaphor)XP：通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。XP不需要事先进行详细的架构设计。XP的最佳实践＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝系统隐喻(SystemMetaphor)XP：通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。XP不需要事先进行详细的架构设计。XP的最佳实践＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝简单设计(SimpleDesign)传统的软件工程要求：前提是需求不变化，或者很少变化；而XP认为：需求是会经常变化的，因此设计不能一蹴而就而应该是一项持续进行的过程。XP的最佳实践＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝简单设计(SimpleDesign)KentBeck认为对于XP来说，简单设计应该满足以下几个原则：成功执行所有的测试；不包含重复的代码；向所有的开发人员清晰地描述编码以及其内在关系；尽可能包含最少的类与方法。XP的最佳实践＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝测试驱动(Test-driven)先测试，再编码；代码未动，测试先行XP：强调“测试先行”。在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都得以通过。注：测试的可自动化，集成化。XP的最佳实践＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝代码重构(Refactoring)XP：强调代码重构在其中的作用，认为应该经常进行重构，通常有两个关键点应该进行重构：对于一个功能实现前和实现后。代码重构是指在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。重构不是XP所特有的行为，在任何的开发过程中都可能并且应该发生。XP的最佳实践＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝结对编程(PairProgramming)XP：认为在项目中采用成对编程比独自编程更加有效。结对编程是由两个开发人员在同一台电脑上共同编写解决同一问题的代码，通常一个人负责写编码，而另一个负责保证代码的正确性与可读性。成对编程是一种非正式的同级评审(PeerReview)。它要求结对编程的两个开发人员在性格和技能上应该相互匹配XP的最佳实践＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝集体拥有代码XP：认为开发小组的每个成员都有更改代码的权利，所有的人对于全部代码负责。评论：代码全体拥有并不意味者开发人员可以互相推委责任，而是强调所有的人都要负责。如果一个开发人员的代码有错误，另外一个开发人员也可以进行BUG的修复。XP的最佳实践＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝持续集成(ContinuousIntegration)XP：提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试。因为，这样可以使得团队保持一个较高的开发速度，同时避免了一次系统集成的恶梦。著名的微软公司就有每日集成(DailyBuild)的成功实践。XP的最佳实践＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝小型发布(SmallRelease)XP：强调在非常短的周期内以递增的方式发布新版本，从而可以很容易地估计每个迭代周期的进度，便于控制工作量和风险；同时，也可以及时处理用户的反馈。用户在发布后两个工作日