什么是极限编程

 

 

什么是极限编程？

极限编程是一种软件开发的方法原则， 这些准则有：简易， 交流， 回馈， 勇气， 尊重。这种准则在作为整体的开发团队在简单实践的前提下，拥有足够使团队看到他们处于开发中何种境地的回馈，以及将实践转换到其特定情况。

 

 

极限编程基础

 

 

         极限编程中， 项目的贡献者是整个团队（whole Team）不可分割的一部分，团队形成与一种叫做客户的组织周围，该客户每日进驻开人团队

 

核心实践： 【团队整体】

    极限编程团队由简单的规划和追踪来决定下一步需要做什么以及预测何时项目会结束。其商业价值体现在，团队产生软件是按照一系列完整的小单元，且每个自洽的小单元均经过客户定义的所有测试

 

核心实践：【规划游戏】， 【小释放】，【客户测试】  

     极限编程的程序员结对工作， 简单设计，着迷于测试代码， 以目前的需要为导向来推进设计

核心实践：  【简单设计】， 【结对编程】， 【测试驱动开发】， 【改进设计】   

      极限编程团队保持系统的完整性以及永久运行。程序员总是结对的产出所有的代码，所有时间都在一起工作。他们以一致的方式编码一致当有需求时，每一个成员都能理解并改进代码。

 

     极限编程是关涉到团队为所有编码负责， 关涉到以一致的方式开发代码所致团队成员之间的代码可以流畅的阅读，关涉到一致保持系统完成运行

       

核心实践： 【改进设计持续集成】， 【集体代码所有权】，【编码标准】 

     极限编程团队共享关于系统是怎样面貌的通用简单的图像。 每个人工作在可持续的步调下  

 

核心实践： 【隐喻成】， 【持续步调】

 

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

 

核心实践 

 

【团队整体】

 

所有参与XP项目的共享者是一个团队的成员。该小组必须包含一个商业角色，“客户”，提供需求， 设置优先顺序， 引领项目。最好客户方是真正的终端用户，了解需求以及领域知识。团队当然包括程序员， 也包括测试员， 帮助客户定义客户可接受的测试。分析员为客户提供帮助， 帮助来定义需求，通常还有一个教练，帮助团队在正确的方向上前进。 也可能有管理员， 提供资源， 掌控外部交流， 协调动作， 这些角色不必每个都单独唯一， 极限编程团队中的每个人可以扮演多重角色， 最好的团队中的团队成员是没有角色区别的， 仅贡献了不同的项目所需技巧而已。

 

XP 规划给软件开发提出了这么两个关键问题：问题一，预测在给定日期系统将达到何种状态；问题二：决定下一步将做什么。较之强调准确语言什么是需要的以及这需要多久而言，更强调引领项目。在XP编程中有两个规划步骤：

释放计划（Releaseplanning） 是一种实践。 客户提供给程序员系统期望， 程序员则评估其难度。客户拥有预算评估以及重要的系统期望领域知识 ， 客户为项目进行了规划。初期的释放计划必然的不精确：无论优先权或预估都不是可靠的， 直至团队开始工作我们对于团队的工作进度仍然是不清晰的。即使第一个释放计划对决策足够准确， XP团队仍然经常释放计划。

 

迭代计划是一种实践， 团队每隔几周都被给出方向。 XP团队构建软件用两周进行迭代，在每一次迭代结束时递交可运行的软件。 在迭代计划期间，客户为下两周给出软件预期的面貌，程序员此时的工作就是将客户给出的软件预期分解成一个个任务， 评估花费（在比释放计划更精细的级别），基于之前迭代期所完成的工作量，团队在本轮迭代期将交付的东西前签字。

 

这些计划步骤都非常简单，但团队提供了非常有用的信息同时有客户优质的把控 。每隔几周，进度的总量就显现出来了。在XP编程中没有百分之九十已近完成的说法，只有客户讲述的一个特征故事已经完成或未完成。关注可见性导致了一个精致的小悖论：一方面， 由于有如此明显的可见性， 客户可以在项目进度不足的情况下取消项目。另一方面， 亦由于有如此明显的可见性，下一步将做什么的这种决定能力是如此的完善， XP编程倾向于在受到更小压力同时递交更多所需

 

 

【客户测试】

 

作为提供系统预想特性的那一部分，  XP客户定义了一个或多个可以接受的测试来展示所述性能已经可以工作。团队则构建测试并用这些测试来证明系统构建的正确性。由于时间的压力，自动化相当重要，手册测试被省略掉。

最佳的XP团队对待客户测试的态度和他们对待程序测试的态度是一样的：一旦测试运行起来，从那以后团队保证其不断的正确运行。 这意味着系统将不断的取得进步而不会回退。

 

 

【小释放】

 

XP团队用两个重要的方式来实践【小释放】

首先，在每一个 团队释放运行， 已测试软件， 递交客户选择的商业价值。 无论是评估或最终提交个终端用户，客户可以以任何方式使用软件。最重要的方式是软件是可见的，并在每一次迭代结束时递交给客户。这个特点保证了开发中所有事情都是公开以及可控的。

其次，XP团队经常对其终端用户进行释放。 XP 的Web项目几乎是每日释放， 而相对于外包项目而言的所谓 in house project则是以月的频度进行释放。

以如此高频度制做良好的版本看上去似乎是不可能的，但XP团队就是一直在这么做的。具体可以参考【持续集成 】，并注意到这些频度释放由于XP的测试特性而保持可信， 具体可见【客户测试】【测试驱动开发】

 

 

【简单设计】

 

XP团队构建软件在一个简单但是充足的设计之上。  项目起始于简单， 通过 【程序测试】以及【设计改经】 让开发过程始终保持简单充足的设计原则。XP团队将设计保持在适应系统的当前功能需求的水准。没有浪费的意图， 软件总是为下一轮做好准备。

XP的设计不是一次性的，显著的，  而是永续存在的。

 

【结对编程】

 

在XP中所有的软件产品都是由以两个在同一台电脑前的程序员为单元构建。产出的产品由于有多于一人来审查，结果导致更好的设计，更好的测试，更好的代码。

看上去两个程序员处理一个程序员的任务是没有效率的， 但是恰恰相反。结队编程的研究显示了其结队之于单枪匹马的优势。

 

有些程序员在没有试过的情况下就反对结对编程。 在学习了结对编程的程序员中有百分之九十

是欢迎结队编程的。

 

结队，除了提供更好的代码与测试外， 同时在整个团队中交换知识。 当结队变换时，每一个人都得到了其他人的特殊知识。 程序员学习到技能的增强， 对团队更加有价值，同时对公司也更加有价值

 

 

【测试驱动开发】

 

极限编程让人着迷的一点就是反馈，在软件开发过程中， 好的反馈要求有好的测试为前提。

顶级XP团队实践“ 测试驱动开发”， 在非常短的周期内添加测试，同时使其工作。团队几乎轻松的产出百分百覆盖测试的代码。（如果你的程序已经有了更精致的测试， 请继续， 这只会帮助你！）

 

仅仅写测试是不够的：你还需要运行他们。 此处程序员测试或单元测试是一体的， 任何实践任何程序员释放任何代码到代码库（结队情况下每天通常释放两次或更多），每个个体程序员的测试必须正确无误。任何时候百分百！这意味这程序员立即获取关于它们是如何做的回馈。 而且， 这些测试提供了当软件设计改进时极其重要的支持。

 

 

【设计改进】

 

极限编程聚焦于在每个迭代周期中均递交商业价值。 在整个项目过程中趋向于此目标， 这样的软件必须是设计良好的。替换的设计方案会降低并最终使项目无路可走。 所以XP编程使用一种叫做重构的持续设计改进过程， 『参考 Refactoring: Improvingthe Design of Existing Code，作者Martin Fowler』

 

重构的过程聚焦于去除重复设计（铁定是一个低劣设计），增强代码的一致性， 降低耦合度。 最近30年发现高内聚低耦合是良好构造代码的黄金检验律。XP团队起始于良好且简单的设计，并给软件设计同样带来了良好简单的特性。这使得团队有信息保持其独有的开发速度（在项目前进的时开发速度也相应的加快了）

 

 

【重构】 强烈的需要全面的测试以支持当设计演化的时候，任何东西都不会拉下。 【客户测试】和【程序员测试】是全面测试的两个支柱。极限编程实践对密不可分的两中类型的测试均是支持的。

 

【持续集成】

 

极限编程团队在开发中一直保持系统的完整性。我们有这样一种说法，每日对wimps进行构建：极限团队每天多于一次进行build.(一个拥有四十个人员的极限开发团队一天至少build 8到10次)

 

这种持续集成的优势可以通过思考这样的项目（你可能听说过）来得到对比：当buil的过程在以周为单位或者频率更底的情况下，这种频度的build很容易发生问题，且一旦问题发生时就陷入了没有人清晰把控的所谓“集成狱域”。

 

低频度的集成容易导致软件项目的严重问题。 首先， 尽管集成对于交付好的软件代码很重要，但是团队对其实践关注不够； 其次，低频度的代码常常是有bug的代码。 问题常常是在单独的子系统测试都不会覆盖到的时候偷偷溜进 集成期间;再次， 不良的整合常常导致大段代码的冻结。代码冻结意味着当程序员应当专注于开发新功能代码的大段时间，却确浪费在回退过程中。这将导致你在市场中地位的下降， 或者是你的终端用户的效率的降低。

 

【集合代码所有权】

 

在一个极限项目上，任何结队的程序员可在任何时间修改任何的代码。这意味着所有的代码获得了许多人的关注，保证了代码的质量同时降低了代码的缺陷度。这同时带来了另外一项重要的好处：当代码属于某一个人的时候，一旦某个需求被放置在错误的地方...之后当某个其它的程序员发现他所需要的软件特性存在于某处他所不拥有的代码之中。代码的所有者忙于做此事，所以程序员就将软件的特性放到其自身的代码中，虽然这些特性不应当出属于该代码的管辖。这将导致难以维护的代码， 高耦合低内聚的代码。

 

【集合代码所有权】也可能会成为一个问题，如果人们盲目的处理其所未知的代码。极限编程通过下述二种关键方式避免了这一窘境：【程序员测试】捕获错误，同时【结对编程】意味着处理未知代码的最好方式是和专家一起共事于代码。此种方式带来的另外一个好处是这种实践使得整个团队隐式的形成了学习型团队。

 

 

 

 

【编码标准】

 

极限团队遵循通用编码规范， 所以系统中的所有代码看上去就像是由一个人的分格所写就的。编码规范的细节并不重要，重要的是所有的代码看上去都很熟悉， 用以支持【集合代码所有权】

 

 

 

【隐喻】

 

极限开发团队形成了一种关于程序是怎样工作的共识， 我们称之为【隐喻】。在最好的情况下，【隐喻】是关于程序如何工作的简单有效的描述方式， 诸如作为基于主体的信息检索系统的描述“这个程序向蜜蜂箱一样，外出穿花授粉，然后带到蜜蜂箱”。在任何情况下，无论有无生动形象的图景， 极限编程团队都会使用常用的系统词汇以确保所有人都了解系统是如何工作的以及何处去找到你所期望的函数功能， 在正确的地方加上你所期望的函数。

 

 

 

【持续步调】

 

极限编程团队久已熟蕴此道，他们努力工作在一种可以无限期维持的步调之中。随着一周又一周的流逝，产能也趋于最大化。当今软件开发应当了解的基本一点就是：有最终截止日期的交付项目既不能产出有质量的软件又无成效。极限编程软件理论与实践可以胜任而不是将项目引入毫无前途的死胡同。

 

 

『结论』

 

极限编程是一种基于以下几个价值观的软件开发方法论：简单， 交流， 回馈，勇气。极限编程只有在将整个团队融为一个简单实践的学习型组织时，只有在取得足够的回馈以使团队成员了解他们身处项目何方，进而根据时位来作出相应的抉择的时候，极限编程才是一种能发挥出其理论优势的编程方法论。

 

（完）

 

转载自：  http://xprogramming.com/what-is-extreme-programming/