极限编程_极限编程xp - CSDN
精华内容
参与话题
  • 什么是极限编程

    千次阅读 2008-12-27 18:29:00
    极限编程(XP,eXtreme Programming)是一种软件工程方法学,是敏捷软件开发中最富有成效的几种方法学之一。如同其他敏捷方法学,极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。XP的支持者...
     
    

    极限编程(XP,eXtreme Programming)是一种软件工程方法学,是敏捷软件开发中最富有成效的几种方法学之一。如同其他敏捷方法学,极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。XP的支持者认为软件需求的不断变化是很自然的现象,是软件项目开发中不可避免的、也是应该欣然接受的现象;他们相信,和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比,有能力在项目周期的任何阶段去适应变化,将是更加现实更加有效的方法。

    XP为管理人员和开发人员开出了一剂指导日常实践的良方;这个实践意味着接受并鼓励某些特别的有价值的方法。支持者相信,这些在传统的软件工程中看来是“极端的”实践,将会使开发过程比传统方法更加好的响应用户需求,因此更加敏捷,更好的构建出高质量软件。

    历史

    极限编程的创始者是肯特·贝克(Kent Beck)、沃德·坎宁安( Ward Cunningham)和罗恩·杰弗里斯(Ron Jeffries),他们在为克莱斯勒综合报酬系统(Chrysler Comprehensive Compensation System )(C3) 的薪水册项目工作时提出了极限编程方法。Kent Beck在1996年3月成为C3的项目负责人,开始对项目的开发方法学进行改善。他写了一本关于这个改善后的方法学的书,并且于1999年10月将之发行,这就是《极限编程解析》(2005第二版出版)。克莱斯勒在2000年2月取消了实质上并未成功的C3项目,但是这个方法学却一直流行在软件工程领域中。至今2006年,很多软件开发项目都一直以极限编程做为他们的指导方法学。

    该书阐述了如下的极致编程的哲学思想 :

    一种社会性的变化机制
    一种开发模式
    一种改进的方法
    一种协调生产率和人性的尝试
    一种软件开发方法
    把极致编程一般化并用于其它型别的专案称为极致专案管理。

     未来的方向

    极限编程的推广之一为把不同的敏捷软件实践和传统实践节奏地结合起来,弹性地合用于不同企业开发环境。这就是软件开发节奏(Software Development Rhythms)的中心思想

    XP的目标

    极限编程的主要目标在于降低因需求变更而带来的成本。在传统系统开发方法中(如SDM),系统需求是在专案开发的开始阶段就确定下来,并在之后的开发过程中保持不变的。这意味着专案开发进入到之后的阶段时出现的需求变更—而这样的需求变更在一些发展极快的领域中是不可避免的—将导致开发成本急速增加。这一概念可以用下图来表示:

    Image:Costofchange.jpg

    极限编程透过引入基本价值、原则、方法等概念来达到降低变更成本的目的。一个应用了极限编程方法的系统开发专案在应对需求变更时将显得更为灵活。下图展示了这一降低变更成本的目的:

    Image:Costofchangexp.jpg

    XP 核心的实践

    极致编程实践作业的核心,正如 Extreme programming explained 所描述的,可以被区分为以下四个范围(12个实践作业):

    小规模回馈

    反覆性程序而不是批量的

    • 持续整合
    • 设计最佳化(原名:软件重构
    • 小型发布

    共同认识(共识)

    • 简单的设计
    • 系统隐喻
    • 集体程式码所有
    • 程式设计标准/程式设计规约

    程式设计师的利益

    • 恒定速路
    • 可反覆性速率(原名:每周40小时)

     

    在第二版的Extreme programming explained中,在主要实践之外,还列出了一系列延伸的实践。

    核心实践源自被广泛接受的最佳实践,并且被推向极至:

    开发人员和客户之间的交互是有益的. 因此,一个极致编程的小组从理论上要求需要一个软件使用者在身边,这个使用者制定软件的工作需求和优先等级, 并且尽可能在各种问题出现的时候马上就能回答(实际工作中,这个角色是由客户代理商完成的).
    如果学习是好的, 那么就把它做到底: 这样减少了开发和回馈周期的长度,测试也能更早完成.
    简单的代码更可能工作。所以极致编程的程序设计师在一个软件专案中唯写出能够满足目前实际需求的代码,这样或多或少降低了代码的复杂性和重复性.
    如果简单的代码是好的, 那么把变得复杂的代码改写成简单的.
    代码评审是好的。因此,极致编程的程序设计师以两人搭档的方式工作. 他们共享一个屏幕和键盘,增加了队员之间的交流,也让代码在一被写出的时候就被人评审了.
    测试代码是好的。因此,在极致编程中,测试用例在实际代码之前就被写出来了. 代码只有在通过测试的时候才被认为完成了. (当然,需要进一步分解来降低复杂性). 整个软件系统用一种周期化的,实时的,被预先变好的自动化测试方式来保证它的确有作用.参看 测试驱动的开发.
    一般来说,极致编程被认为对于少于12人的小团队很有用。一些人认为极致编程可以用于大的团队,但是其它人认为统一软件程序更适合大的团队。然而,极致编程在一些超过100人的开发小组中获得成功. 并不是极致编程不能够推广到更大的团队,而是很少有更大的团队来试著用它. 极致编程的人员也拒绝去随便推测这个问题.

     XP的价值
    最初,极限编程技术只提出了四条价值标准,而在《极限编程解析》的第二版中又加入了第五条。以下就是这五条标准:

    沟通
    简单
    回馈
    勇气
    尊重(最新添加的价值)

     软件重构
    构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中,这一任务是通过文档来完成的。

    极限编程技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法。它的目标是向所有开发人员提供一个对于系统的共享的视角,而这一视角又是与系统的最终用户的视角相吻合的。为了达到这一目标,极限编程支持设计、抽象、还有用户-程序员间交流的简单化,鼓励经常性的口头交流与反馈。


     简单
    极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于,它只关注于对当前的需求来进行设计、编码,而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的,即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点,因为将来的需求在他们还没提出之前是很可能发生变化的。为了将来不确定的需求进行设计以及编码意味着在一些可能并不需要的方面浪费资源。而与之前提到的“交流”这一价值相关联来看,设计与代码上的简化可以提高交流的质量。一个由简单的编码实现的简单的设计可以更加容易得被小组中的每个程序员所理解。


     反馈
    在极限编程中,“反馈”是和系统开发的很多不同方面相关联的:

    来自系统的反馈:通过编写单元测试,程序员能够很直观的得到经过修改后系统的状态。
    来自客户的反馈:功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。这样的评审一般计划2、3个礼拜进行一次,这样客户可以非常容易的了解、掌控开发的进度。
    来自小组的反馈:当客户带着新需求来参加项目计划会议时,小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户。
    反馈是与“交流”、“简单”这两条价值紧密联系的。为了沟通系统中的缺陷,可以通过编写单元测试,简单的证明某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户可以以定义好的功能需求为依据,对系统进行周期性的测试。用Kent Beck的话来说:“编程中的乐观主义是危险的,而及时反馈则是解决它的方法。”


     勇气
    极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码,不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。每个程序员都有这样的经历:他们花了一整天的时间纠缠于自己设计和代码中的一个复杂的难题却无所得,而第二天回来以一个全新而清醒的角度来考虑,在半小时内就轻松解决了问题。


     尊重
    尊重的价值体现在很多方面。在极限编程中,团队成员间的互相尊重体现在每个人保证提交的任何改变不会导致编译无法通过、或者导致现有的测试case失败、或者以其他方式导致工作延期。团队成员对于他们工作的尊重体现在他们总是坚持追求高质量,坚持通过重构的手段来为手头的工作找到最好的解决设计方案。


     原则
    组成极限编程基础的原则,正是基于上面描述的那几条价值。在系统开发项目中,这些原则被用来为决策做出指导。与价值相比,原则被描述的更加具体化,以便在实际应用中更为简单的转变为具体的指导意见。


     快速反馈
    当反馈能做到及时、迅速,将发挥极大的作用。一个事件和对这一事件做出反馈之间的时间,一般被用来掌握新情况以及做出修改。与传统开发方法不同,与客户的发生接触是不断反复出现的。客户能够清楚地洞察开发中系统的状况。他/她能够在整个开发过程中及时给出反馈意见,并且在需要的时候能够掌控系统的开发方向。

    单元测试同样对贯彻反馈原则起到作用。在编写代码的过程中,应需求变更而做出修改的系统将出现怎样的反应,正是通过单元测试来给出直接反馈的。比如,某个程序员对系统中的一部分代码进行了修改,而假如这样的修改影响到了系统中的另一部分(超出了这个程序员的可控范围),则这个程序员不会去关注这个缺陷。往往这样的问题会在系统进入生产环节时暴露出来。


     假设简单
    假设简单认为任何问题都可以"极度简单"的解决。传统的系统开发方法要考虑未来的变化,要考虑程序码的可重用性。极致编程拒绝这样作。


     增量变化
    极限编程的提倡者总是说:罗马不是一天建成的。一次就想进行一个大的改造是不可能的。极限编程采用增量变化的原则。比如说,可能每三个星期发布一个包含小变化的新版本。这样一小步一小步前进的方式,使得整个开发进度以及正在开发的系统对于用户来说变得更为可控。


     包容变化
    可以肯定地是,不确定因素总是存在的。“包容变化”这一原则就是强调不要对变化采取反抗的态度,而应该包容它们。比如,在一次阶段性会议中客户提出了一些看来戏剧性的需求变更。作为程序员,必须包容这些变化,并且拟定计划使得下一个阶段的产品能够满足新的需求。


     活动
    XP 描述了在软件开发过程中四种基本的行为。 XP describes four basic activities that are performed within the software development process.


     编码
    XP的提倡者争辩说在系统开发过程的产物中真正重要的只有编码


     软件测试
    没有经过测试的程序码什么都不是。如果你没有测试,客户可能感觉不到,很多软件在发布的时候没有经过完整的测试,它们还都在工作(或多或少的工作)。 在软件开发程序中,极致编程认为,如果一个函数没有经过测试就不能认为它可以工作。


     实践

     策划游戏
    在极致编程中主要的策划程序称为策划游戏。 本节将通过程序模型介绍这个程序。

    策划程序分为两部分:

    发布策划:
    反覆状态:
    Image:Planninggame.gif


     送出状态 – 发布计划
    这一阶段涉及成本、利润和计划影响这三个因素,包含四个部分:

    按照价值排序:业务方按照商业价值为使用者故事排序。
    按风险排序:开发方按风险为使用者故事排序。
    设定周转率:开发方决定以怎样的速度开展专案。
    选择范围:挑选在下一个发布中需要被完成的使用者故事,基于使用者故事决定发布日期。

     价值排序
    业务方按照商业价值为使用者故事排序。它们会被分为三类:

    关键:没有这些故事系统无法运作或变得毫无意义。
    重要的商业价值:有重要业务价值的非关键使用者故事。
    最好能有:并没有重要商业价值的使用者故事;例如在可用性或使用者界面上的改进。

     风险排序
    程序设计师按照风险对使用者故事进行排序。他/她们将使用者故事的风险划分成三类:低、中、高。以下是这种方式的一个范例:

    决定风险索引:依照以下因素给每个使用者故事一个0到2的索引:
    完全度(我们是否已经了解所有的故事细节?)
    完全(0)
    不完全(1)
    未知(2)
    发散性(可能会发生变化吗?)
    低(0)
    中(1)
    高(2)
    复杂度(是否难以建构?)
    简单(0)
    标准(1)
    复杂(2)
    为每个使用者故事增加所有这些索引后,给这些使用者故事指定一个风险索引:低(0–1),中(2–4),高(5–6)。


    激励状态 – 发布计划
    在作业阶段开发人员和业务人员可以“操纵”整个程序。这意味着,他们可以做出改变。个体的使用者故事,或是不同使用者故事的相对优先等级,都有可能改变;预估时间也可能出现误差。这是做出相应调整的机会。


    探索阶段- 反覆计划
    反覆计划中的探索阶段是关于建立任务和预估实施时间。

    收集使用者故事:收集并编辑下一个发布的所有使用者故事。
    组合/分割任务:如果程序设计师因为任务太大或太小而不能预估任务完成时间,则需要组合或分割此任务。
    预估任务:预测需要实作此任务的时间。

    约定阶段 - 反覆计划
    在反覆计划的约定阶段以不同使用者故事作为参考的任务被指派到程序设计师。

    程序设计师接受任务:每个程序设计师都挑选一个他/她负责的任务。
    程序设计师预估任务:由于程序设计师对此任务负责,他/她必须给出一个完成任务的估计时间。
    设定负载系数:负载系数表示每个程序设计师在一个反覆中理想的开发时间。比如:一周工作40小时,其中5小时用于开会,则负载系数不会超过35小时。
    平衡:当团队中所有程序设计师都已经被配置了任务,便会在预估时间和负载系数间做出比较。任务配置在程序设计师中达到平衡。如果有一个程序设计师的开发任务过重,其它程序设计师必须接手他/她的一部分任务,反之亦然。

    作业阶段 - 反覆计划
    各个任务是在反覆计划的作业阶段中一步步实作的。

    取得一张任务卡片:程序设计师取得一张由他/她负责的任务的卡片。
    找寻一名同伴:这个程序设计师将和另一位程序设计师一同完成开发工作。这在实施结队程序设计中会做更深入的探讨。
    设计这个任务:如果需要,两位程序设计师会设计这个任务所达成的功能。
    编辑单元测试:在程序设计师开始编辑实作功能的程序码之前,他/她们首先编辑自动测试。这在实施单元测试中会做更深入的探讨。
    编辑程序码:两位程序设计师开始编辑程序码。
    执行测试:执行单元测试来确定程序码能正常工作。
    执行功能测试:执行功能测试(基于相关使用者故事和任务卡片中的需求)。

    结对程序设计
    结对程序设计的意思是所有的程序码都是由两个人坐在一台电脑前一起完成的。一个程序设计师控制电脑并且主要考虑编码细节。另外一个人主要关注整体结构,不断的对第一个程序设计师写的程序码进行评审。

    结对不是固定的: 我们甚至建议程序设计师尽量交叉结对。这样,每个人都可以知道其它人的工作,每个人都对整个系统熟悉,结对程序设计加强了团队内的沟通。 (这与程序码集体所有制是息息相关的).


    集体所有制
    集体所有制意味着每个人都对所有的程序码负责;这一点,反过来又意味着每个人都可以更改程序码的任意部分。结队程序设计对这一实践贡献良多:借由在不同的结队中工作,所有的程序设计师都能看到完全的程序码。集体所有制的一个主要优势是提升了开发程序的速度,因为一旦程序码中出现错误,任何程序设计师都能修正它。

    在给予每个开发人员修改程序码的权限的情况下,可能存在程序设计师引入错误的风险,他/她们知道自己在做什么,却无法预见某些依赖关系。完善的单元测试可以解决这个问题:如果未被预见的依赖产生了错误,那么当单元测试执行时,它必定会失败。

     现场客户
    在极致编程中,“客户”并不是为系统付帐的人,而是真正使用该系统的人。极致编程认为客户应该时刻在现场解决问题。例如:在团队开发一个财务管理系统时,开发小组内应包含一位财务管理人员。


     单元测试
    单元测试是用以测试一小段程序码的自动测试(例如:类,方法)。在极致编程中,在程序码编辑前就编辑单元测试。这种方式的目的是激励程序设计师设想他/她的程序码在何种条件下会出错。极致编程认为当程序设计师无法再想出更多能使他/她的程序码出错的情况时,这些程序码便算完成。


     重构
    由于XP教条提倡编辑程序时只满足目前的需求,并且以尽可能简单的方式实作。有时会碰上一套僵硬的系统,所谓僵硬的系统,表现之一是需要双重(或多重)维护:功能变化需要对多份同样(或类似)的程序码进行修改;另一种表现是对程序码的一部分进行修改时会影响其它很多部分。XP教条认为当这种情况发生时,意味着系统正告诉你通过改变系统架构以重构程序码,使它更简单、更泛用。参见重构。

    极致编程的特征
    极致编程方法的基本特征是:

    增量和反覆式的开发 - 一次小的改进跟着一个小的改进。
    反覆性,通常是自动重复的单元测试,回归测试。参见JUnit。
    结对程序设计
    在程序设计团队中的使用者交互(在场的客户)
    软件重构
    共享的程序码所有权
    简单
    回馈
    用隐喻来组织系统
    可以忍受的速度
    这些内容属性来源于那些被认为是有效的原则,并把它们发挥到极致:

    开发人员和客户之间的交互是有益的. 因此,一个极致编程的小组从理论上要求需要一个软件使用者在身边,这个使用者制定软件的工作需求和优先等级, 并且尽可能在各种问题出现的时候马上就能回答.
    如果学习是好的, 那么就把它做到底: 这样减少了开发和回馈周期的长度,测试也能更早完成.
    简单的程序码更可能工作。所以极致编程的程序设计师在一个软件专案中唯写出能够满足目前实际需求的程序码,这样或多或少降低了程序码的复杂性和重复性.
    如果简单的程序码是好的, 那么把变得复杂的程序码改写成简单的.
    程序码评审是好的。因此,极致编程的程序设计师以两人搭档的方式工作. 他们共享一个屏幕和键盘,增加了队员之间的交流,也让程序码在一被写出的时候就被人评审了.
    测试程序码是好的。因此,在极致编程中,测试用例在实际程序码之前就被写出来了. 程序码只有在通过测试的时候才被认为完成了. (当然,需要进一步分解来降低复杂性). 整个软件系统用一种周期化的,实时的,被预先变好的自动化测试方式来保证它的确有作用.参看 测试驱动的开发.
    一般来说,极致编程被认为对于少于12人的小团队很有用。一些人认为极致编程可以用于大的团队,但是其它人认为统一软件程序更适合大的团队。然而,极致编程在一些超过100人的开发小组中获得成功. 并不是极致编程不能够推广到更大的团队,而是很少有更大的团队来试着用它. 极致编程的人员也拒绝去随便推测这个问题.


    争论的观点
    极致编程也有其被争论的一面:

    没有书面的详细的规格说明书
    客户代表被安排在专案中
    程序设计师以结对的方式工作
    测试驱动的开发
    绝大多数设计活动都匆匆而过,并渐进式的,开始一个“最简单的可能工作的东西”并当其需要时(测试失败)才增加复杂性。单元测试促成为了设计纪律。


    极致编程中的沟通
    建构软件系统的一个基本任务是向系统的开发人员传达系统的需求。在形式的软件开发方法学中,沟通是通过文件完成的。

    极致编程方法可以被看作为在开发团队成员间快速建构和散布统一的知识的一种方法。目的在于给所有开发人员一个共享的关于系统的看法,这个看法与使用者持有的看法相一致。为了这个目的,极致编程热衷于简单的设计,隐喻,使用者与程序设计师之间的合作,频繁的口头沟通和回馈。

    展开全文
  • 极限编程(XP):概念、特点和应用

    千次阅读 2013-05-23 09:00:06
    [摘要] 极限编程是一种轻量级的、灵巧的、简单的软件工程方法。与传统的开发过程不同,极限编程的核心活动体现在需求→测试→编码→设计过程中。因此适用于规模小、进度紧、需求变化大、质量要求严的项目。它希望以...
     
     
     
     

    [摘要] 极限编程是一种轻量级的、灵巧的、简单的软件工程方法。与传统的开发过程不同,极限编程的核心活动体现在需求→测试→编码→设计过程中。因此适用于规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题,以最大的灵活性和最小的代价来满足用户未来的需求。

    [关键词] 极限编程;概念;特点;应用

    在传统的软件系统开发中,系统需求是在项目开发的开始阶段就确定下来,并在之后的开发过程中保持不变的,这就意味着从进入项目开发到之后的所有阶段所出现的所有需求变更(这样的需求变更在国内目前的商业软件系统开发中是不可避免的),将导致开发成本急速增加。极限编程是一种轻量级的、灵巧的、简单的软件工程方法,适合于12人以下的小型开发团队,它的主要目标在于面对商业软件系统环境做出了务实的选择,力求降低需求变更而带来的成本增加,进而提高软件的开发效率。

    一、极限编程简介

    极限编程(Extreme Programming,简称XP)是敏捷软件开发方法的代表。2000年,美国软件工程专家Kent Beck对极限编程这一创新软件过程方法论进行了解释:“XP是一种轻量、高效、低风险、柔性、可预测、科学而充满乐趣的软件开发方法。”Kent Beck建议XP应用于规模小、进度紧、需求变化大、质量要求严格的项目[1]。极限编程是价值而非实践驱动的高度迭代的开发过程。其价值体现在以下几个方面:第一,沟通(Communication):即追求有效的沟通。XP强调项目开发人员、设计人员、客户之间等有效地、及时地沟通,确保各种信息的畅通。第二,简单(Simplicity):即实现最简单的可行方案。XP认为应该尽量保持代码的简单,只要能够满足工作需要就行,这样有利于代码的重构和优化。第三,反馈(Feedback):即快速有效的反馈。要求不断对当前系统状态进行反馈,通过反馈,达到迅速沟通、编码、测试、发布的目的。第四,勇气(Courage):即勇于放弃和重构。对于用户的反馈,XP程序员要勇于对自己的代码进行修改,即使有些修改可能会使得原来已经通过的测试又出现错误,但是经过团队的共同攻关,最终必然会取得满意的效果。

    二、极限编程的开发过程及特点

    与传统的开发过程不同,极限编程的核心活动体现在需求→测试→编码→设计过程中,因此对工作环境、需求分析、设计、编程、测试、发布等提出了新的思路和要求。

    1、工作环境:XP要求每个参加项目开发的人都担任一个角色(项目经理、项目监督人等),并履行相应的权利和义务。所有的人都在一个开放式的开发环境中工作,最好是在同一个大房间中工作,随时讨论问题,强调每周40小时工作制,不加班。

    2、需求分析:客户被纳入开发队伍。由于客户不具备计算机专业知识,无法用专业语言明确描述需求,所以开发人员和客户一起,用讲故事的方式把需求表达出来,这种故事被称为user story,即用user story表示需求。开发人员根据经验将许多user story 组合起来,或将其进行分解,最终记录在story card的小卡片上,这些user story将陆续被程序员在各个小的周期内,按照商业价值、开发风险的优先顺序逐个开发。

    3、设计:XP强调简单设计(simple design),即用最简单的办法实现每个小需求。在XP中,没有那种传统开发模式中一次性的、针对所有需求的总体设计,这些设计只要能够满足系统客户在当前的需求就可以了,不需要考虑将来可能的变化,整个设计过程包括在整个螺旋式发展的项目中。

    4、编程:成对编程(pair programming)是极限编程的一大特色,即两个人一起使用同一个屏幕,同一个键盘,共同完成一段程序的编码。成对编程的好处是,可以提高纪律性,更容易写出优质的代码,同时保证编程的流畅进行,更重要的是,能够使得整个团队更方便地分享编程经验,有利于新手的快速成长。

    5、测试:在极限编程中,测试是非常重要的一个环节,它首先要求在开始写程序之前先写好测试,其目的是为了提高软件的可测试性。XP要求开发人员经常把开发好的模块整合到一起,每次整合后都要运行单元测试;做任何的代码复核和修改,都要运行单元测试;发现了漏洞,就要增加相应的测试。除了单元测试之外,还要进行整合测试、功能测试、负荷测试和系统测试等。所有这些测试是极限编程开发过程中最重要的文档之一,也是最终交付给用户的内容之一。

    6、发布:XP要求按照开发计划,每经过一个开发周期,软件就发布一次,而不是像传统的开发方法那样,整个软件开发完成后才发布。在一个开发周期内,开发人员要求客户选择最有价值的user story作为未来一两个星期的开发内容,一个开发周期完成后,提交给客户的系统虽然不是最终的产品,但它已经实现了几个客户认为是最重要的story,开发人员将逐步在其基础上增加新的模块,而且在发布前软件都经过单元测试和集成测试,因此,虽然软件并不完备,但是,发布的软件客户还是可以真正使用的。

    三、极限编程的优缺点

    1、极限编程的优点

    与传统的软件工程方法相比较,极限编程具有以下优点:(1)重视客户的参与;(2)重视团队合作和沟通;(3)制定计划前做出合理预测;(4)让编程人员参与软件功能的管理;(5)重视质量;(6)简单设计;(7)高频率的重新设计和重构;(8)高频率及全面的测试;(9)递增开发;(10)连续的过程评估;(11)对过去的工作持续不断的检查。

    2、极限编程的缺点

    其缺点主要表现为:(1)以代码为中心,忽略了设计;(2)缺乏设计文档,局限于小规模项目;(3)对已完成工作的检查步骤缺乏清晰的结构;(4)质量保证依赖于测试;(5)缺乏质量规划;(6)没有提供数据的收集和使用的指导;(7)开发过程不详细;(8)全新的管理手法带来的认同度问题;(9)缺乏过渡时的必要支持。

    四、极限编程的应用

    XP适用于规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题,以最大的灵活性和最小的代价来满足用户未来的需求,XP在平衡短期和长期之间做了巧妙的安排[2]。

    我国的软件开发过程经常存在一些问题,如:客户需求变化频繁、系统支付时间一推再推、交付系统错误层出不穷、因程序员半途跳槽而导致工作不能顺利完成、需求估计不足、因程序员之间交流少而导致代码重复开发、文档不能真实地反映实际情况等等。为了有效地克服上述问题,软件机构在项目开发时,有意识地采用XP方法,并且取得了一定效果。通过对这些应用的总结,可以概括出,XP应用确实具有一定的适用范围,而应用成功的关键在于,充分认识XP应用过程中的优缺点,在保持组织既有的开发过程和生命周期模型的前提下,结合应用类型、项目特点和组织文化,借鉴、汲取个别对项目有效的XP方法,在领会其精神实质的基础上灵活运用,而不是全部照搬硬套。另外以下几个问题也是在应用中需要注意的:

    1、不同方法的目标对象和适用环境各不相同,学习和运用流行的过程方法论是实施过程改进的好办法,但在具体应用过程中,应整合其最佳元素,设计出适合具体实际项目的过程体系。

    2、在软件工程实践中要充分把握好开发技能、软件过程和组织管理各个要素的平衡,不能偏重某一方面,轻视另一方面;

    3、在应用XP时,应该首先从基本实践入手,逐渐深入到扩展性实践,因为基本实践彼此独立,互不影响,而扩展性实践则是建立在某些基本实践的基础上的,而且要采取循序渐进、迂回反复(迭代)的策略,而不是一步到位,这样容易取得成功。

    我国目前许多开发机构中已经使用了XP方法,但是,由于XP理论本身仍然处于不断完善和改进阶段,另外具体的开发项目也有各自的特点,因此,如何更好地将其应用到实际的项目开发过程中还需要进一步深入研究。

    [参考文献]

    [1]谷秀岩,“关于极限编程的理论研究”,《计算机与网络》[J],2004年第12期,P93-95

    [2]王卫民,何晓韬,“极限编程理论浅析”,《安阳工学院学报》[J],2006年第6期,P45-47

    [3]方志刚,《软件工程原理与应用》(第二版)[M],北京,科学出版社,2003.8

    [4]张惠彦,廉保旺,逯野,“极限编程的研究和应用”,《科学技术与工程》[J],第7卷第12期,P2997-3000

    [5]杜荣华,龚德俊,刘好德,谌海军,“极限编程在大型项目开发中的应用”,《交通与计算机》[J],2004年第6期,P110-112


    转载自:http://www.uml.org.cn/UMLForum/200906103.asp

    展开全文
  • 体验极限编程(XP)

    万人学习 2018-10-22 21:38:02
    极限编程,英文:Extreme Programming,简称:XP编程,这是一种轻量、、强调适应变化、适合中小型项目的项目管理方法。本课程为你分享极限编程的10多种佳实践。
  • 极限编程

    2014-04-24 19:52:12
    极限编程(eXtreme Programming,简称XP)。极限编程(XP)是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的。 设计和编程都是人的活动。忘记这一点,将会失去一切。 -- Bjarne Stroustrup  极限编程(XP...


    极限编程(eXtreme Programming,简称XP)。极限编程(XP)是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的。 设计和编程都是人的活动。忘记这一点,将会失去一切。
    -- Bjarne Stroustrup

       极限编程(XP)是敏捷方法中最著名的一个。它是由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。

    下面是极限编程的有效实践:
    1. 完整团队 XP项目的所有参与者(开发人员、客户、测试人员等)一起工作在一个开放的场所中,他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
    2. 计划游戏计划是持续的、循序渐进的。每2周,开发人员就为下2周估算候选特性的成本,而客户则根据成本和商务价值来选择要实现的特性。
    3. 客户测试作为选择每个所期望的特性的一部分,客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。
    4. 简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试,不包含任何重复,表达出了编写者想表达的所有东西,并且包含尽可能少的代码。
    5. 结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
    6. 测试驱动开发编写单元测试是一个验证行为,更是一个设计行为。同样,它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环,尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作,他们先增加一个失败的测试,然后使之通过。
    7. 改进设计随时利用重构方法改进已经腐化的代码,保持代码尽可能的干净、具有表达力。
    8. 持续集成团队总是使系统完整地被集成。一个人拆入(Check in)后,其它所有人责任代码集成。
    9. 集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责,每个人都可以参与任何其它方面的开发。
    10. 编码标准 系统中所有的代码看起来就好像是被单独一人编写的。
    11. 隐喻 将整个系统联系在一起的全局视图;它是系统的未来影像,是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符,那么你就知道该模块是错误的。
    12. 可持续的速度 团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作,他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑。 极限编程是一组简单、具体的实践,这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法,项目团队可以拿来直接采用,也可以增加一些实践,或者对其中的一些实践进行修改后再采用。
    展开全文
  • 浅谈极限编程

    千次阅读 2019-06-08 23:08:15
    为什么出现极限编程 ? 敏捷方法论有一个共同的特点,那就是都将矛头指向了“文档”,它们认为传统的软件工程方法文档量太“重”了,称为“重量级”方法,而相应的敏捷方法则是“轻量级”方法。正是因为“轻量级”...

    为什么出现极限编程 ?

    敏捷方法论有一个共同的特点,那就是都将矛头指向了“文档”,它们认为传统的软件工程方法文档量太“重”了,称为“重量级”方法,而相应的敏捷方法则是“轻量级”方法。正是因为“轻量级”感觉没有什么力量,不但不能够有效体现灵活性,反而显得是不解决问题的方法论似的。因此,就有了一次划时代的会议,创建了敏捷联盟。

    在敏捷方法论领域中,比较知名的、有影响力的,是拥有与 Microsoft 的操作系统相同缩写语——XP的极限编程(eXtreme Programming)。极限编程方法论可以说是敏捷联盟中最鲜艳的一面旗帜,也是被研究、尝试、应用、赞扬、批判最多的一种方法论,也是相对来说最成熟的一种。

    这一被誉为“黑客文化”的方法论的雏形最初形成于1996—1999年间,Kent Beck、Ward Cunninggham、Ron Jeffrey 在开发 C3 项目(Chrysler Comprehensive Compensation)的实践中总结出了 XP 的基本元素。在此之后,Kent Beck 和他的一些好朋友们一起在实践中完善提高,终于形成了极限编程方法论。

    什么是解析极限编程 ?

    那么什么是 极限编程呢? 这里我们把极限编程简称为 XP

    XP 是一种轻量(敏捷)、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比,其最大的不同在于:

    • 在更短的周期内,更早地提供具体、持续的反馈信息。
    • 在迭代的进行计划编制,首先在最开始迅速生成一个总体计划,然后在整个项目开发过程中不断的发展它。
    • 依赖于自动测试程序来监控开发进度,并及早地捕获缺陷。
    • 依赖于口头交流、测试和源程序进行沟通。
    • 倡导持续的演化式设计。
    • 依赖于开发团队内部的紧密协作。
    • 尽可能达到程序员短期利益和项目长期利益的平衡。

    Kent Beck 曾经说过“开车”就是一个 XP 的范例,即使看上去进行得很顺利,也不要把视线从公路上移开,因为路况的变化,将使得你必须随时做出一些这样那样的调整。而在软件项目中,客户就是司机,他们也没有办法确切地知道软件应该做什么,因此程序员就需要向客户提供方向盘,并且告知我们现在的位置。

    XP 包括写什么呢?如图,XP 由价值观、原则、实践和行为四个部分组成,它们彼此相互依赖、关联, 并通过行为贯穿于整个生命期。

    在这里插入图片描述

    四大价值观

    XP 的核心是其总结的

    沟通(Communication)

    简单(Simplicity)

    反馈(Feedback)

    勇气(Courage)

    四大价值观,它们是XP的基础,也是XP的灵魂。

    此外还扩展了第五个价值观:谦逊(Modesty)。 XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱;XP 精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习 XP 的关键,是用“沟通、简单、反馈、勇气和谦逊”的态度来对待 XP;轻松愉快地来感受 XP 的实践思想;自己认真实践后,通过对真实反馈的分析,来决定 XP 对自己的价值;有勇气接受它,或改进它。

    PS 吐槽:对吧,我老实程序员。拿这几个价值观去恋爱去了,但是现在还是单身0.0

    沟通

    通常程序员给人留下的印象就是“内向、不善言谈”,然后项目中的许多问题就出在这些缺乏沟通的开发人员身上。经常由于某个程序员做出了一个设计决定,但是却不能及时地通知大家,结果使得大家在协作与配合上出现了很多的麻烦,而在传统的方法论中,并不在意这种口头沟通不畅的问题,而是希望借助于完善的流程和面面俱到的文档、报表、计划来替代,但是这同时又引入了效率不高的新问题。

    XP 方法论认为,如果小组成员之间无法做到持续的、无间断的交流,那么协作就无从谈起,从这个角度能够发现,通过文档、报表等人工制品进行交流面临巨大的局限性。因此,XP 组合了诸如对编程这样的最佳实践,鼓励大家进行口头交流,通过交流解决问题,提高效率

    PS 吐槽: 闷头苦干?不见得你带来的效益更高

    简单

    XP 方法论提倡在工作中秉承“够用就好”的思路,也就是尽量地简单化,只要今天够用就行,不考虑明天会发现的新问题。这一点看上去十分容易,但是要真正做到保持简单的工作其实很难的。因为在传统的开发方法中,都要求大家对未来做一些预先规划,以便对今后可能发生的变化预留一些扩展的空间。

    正如对传统开发方法的认识一样,许多开发人员也会质疑 XP,保持系统的扩展性很重要,如果都保持简单,那么如何使得系统能够有良好的扩展性呢?其实不然,保持简单的理由有两个:

    • 开发小组在开发时所做的规划,并无法保证其符合客户需要的,因此做的大部分工作都将落空,使得开发过程中重复的、没有必要的工作增加,导致整体效率降低
    • 在 XP 中提倡时刻对代码进行重构,一直保持其良好的结构与可扩展性。也就是说,可扩展性和为明天设计并不是同一个概念,XP 是反对为明天考虑而工作,并不是说代码要失去扩展性

    而且简单和沟通之间还有一种相对微妙的相互支持关系。当一个团队之间,沟通的越多,那么就越容易明白哪些工作需要做,哪些工作不需要做。另一方面,系统越简单,需要沟通的内容也就越少,沟通也将更加全面

    PS 吐槽: 唉~~~~~

    反馈

    是什么原因使得我们的客户、管理层这么不理解开发团队?为什么客户、管理层总是喜欢给我们一个死亡之旅?究其症结,就是开发的过程中缺乏必要的反馈。在许许多多项目中,当开发团队经历过了需求分析阶段之后,在相当长的一段时间内,是没有任何反馈信息的。整个开发过程对于客户和管理层而言就像一个黑盒子,进度完全是不可见的。

    而且在项目的过程中,这样的现象不仅出现在开发团队与客户、管理层之间,还包括在开发团队内部。这一切问题都需要我们更加注重反馈。,反馈对于任何软件项目的成功都是至关重要的,而在 XP 方法论中则更进一步,通过持续、明确的反馈来暴露软件状态的问题。具体而言就是:

    • 在开发团队内部,通过提前编写单元测试代码,时时反馈代码的问题与进展
    • 在开发过程中,还应该加强集成工作,做到持续集成,使得每一次增量都是一个可执行的工作版本,也就是逐渐是软件长大,整个过程中,应该通过向客户和管理层演示这些可运行的版本,以便及早地反馈,及早地发现问题。

    同时,我们也会发现反馈与沟通也有着良好的配合,及时和良好的反馈有助于沟通。而简单的系统更有利于测试和反馈。

    PS 吐槽:不得不说啊 测试也是很重要的一环

    勇气

    在应用 XP 方法论时,我们每时每刻都在应对变化:由于沟通良好,因此会有更多需求变更的机会;由于时刻保持系统的简单,因此新的变化会带来一些重新开发的需要;由于反馈及时,因此会有更多中间打断你的思路的新需求。

    总之这一切,使得你立刻处于变化之中,因此这时就需要你有勇气来面对快速开发,面对可能的重新开发。也许你会觉得,为什么要让我们的开发变得如此零乱,但是其实这些变化若你不让它早暴露,那么它就会迟一些出现,并不会因此消亡,因此,XP 方法论让它们早出现、早解决,是实现“小步快走”开发节奏的好办法。

    也就是 XP 方法论要求开发人员穿上强大、自动测试的盔甲,勇往直前,在重构、编码规范的支持下,有目的地快速开发

    勇气可以来源于沟通,因为它使得高风险、高回报的试验成为可能;勇气可以来源于简单,因为面对简单的系统,更容易鼓起勇气;勇气可以来源于反馈,因为你可以及时获得每一步前进的状态(自动测试),会使得你更勇于重构代码。

    PS 吐槽:拒绝做羞涩的程序员

    四大价值观之外

    在这四大价值观之下,隐藏着一个更深刻的东西,那就是尊重。因为这一切都建立在团队成员之间的相互关心、相互理解的基础之上

    五个原则

    快速反馈

    及时地、快速地获取反馈,并将所学到的知识尽快地投入到系统中去。也就是指开发人员应该通过较短的反馈循环迅速地了解现在的产品是否满足了客户的需求。这也是对反馈这一价值观的进一步补充。

    简单性假设

    类似地,简单性假设原则是对简单这一价值观的进一步补充。这一原则要求开发人员将每个问题都看得十分容易解决,也就是说只为本次迭代考虑,不去想未来可能需要什么,相信具有将来必要时增加系统复杂性的能力,也就是号召大家出色地完成今天的任务。

    逐步修改

    就像开车打方向盘一样,不要一次做出很大的改变,那样将会使得可控性变差,更适合的方法是进行微调。而在软件开发中,这样的道理同样适用,任何问题都应该通过一系列能够带来差异的微小改动来解决。

    提倡更改

    在软件开发过程中,最好的办法是在解决最重要问题时,保留最多选项的那个。也就是说,尽量为下一次修改做好准备。

    优质工作

    在实践中,经常看到许多开发人员喜欢将一些细小的问题留待后面解决。例如,界面的按钮有一些不平整,由于不影响使用就先不管;某一两个成员函数暂时没用就不先写等。这就是一种工作拖泥带水的现象,这样的坏习惯一旦养成,必然使得代码质量大打折扣。

    而在 XP 方法论中,贯彻的是“小步快走”的开发原则,因此工作质量决不可打折扣,通常采用测试先行的编码方式来提供支持

    PS 吐槽:细节!!!0.0

    十三个最佳实践

    在 XP 中,集成了 13 个最佳实践,有趣的是,它们没有一个是创新的概念,大多数概念和编程一样老。其主要创新点在于提供一种良好的思路,将这些最佳实践结合在一起,并且确保尽可能彻底地执行它们,使得它们能够在最大程度上相互支持,紧接下来,我们就对每一种最佳实践进行一番了解。

    计划游戏

    计划游戏的主要思想就是先快速地制定一份概要的计划,然后随着项目细节的不断清晰,再逐步完善这份计划。计划游戏产生的结果是一套用户故事及后续的一两次迭代的概要计划。

    “客户负责业务决策,开发团队负责技术决策”是计划游戏获得成功的前提条件。也就是说,系统的范围、下一次迭代的发布时间、用户故事的优先级应该由客户决定;而每个用户故事所需的开发时间、不同技术的成本、如何组建团队、每个用户故事的风险,以及具体的开发顺序应该由开发团队决定。

    好了,明白这些就可以进行计划游戏了。首先客户和开发人员坐在同一间屋子里,每个人都准备一支笔、一些用于记录用户故事的纸片,最好再准备一个白板,就可以开始了。

    • 客户编写故事:由客户谈论系统应该完成什么功能,然后用通俗的自然语言,使用自己的语汇,将其写在卡片上,这也就是用户故事。
    • 开发人员进行估算:首先客户按优先级将用户故事分成必须要有、希望有、如果有更好三类,然后开发人员对每个用户故事进行估算,先从高优先级开始估算。如果在估算的时候,感到有一些故事太大,不容易进行估算,或者是估算的结果超过 2人/周,那么就应该对其进行分解,拆成 2 个或者多个小故事。
    • 确定迭代的周期:接下来就是确定本次迭代的时间周期,这可以根据实际的情况进行确定,不过最佳的迭代周期是 2~3 周。有了迭代的时间之后,再结合参与的开发人数,算出可以完成的工作量总数。然后根据估算的结果,与客户协商,挑出时间上够、优先级合适的用户故事组合,形成计划。

    PS 吐槽:客户期望与 客户的期望--。--

    小型发布

    XP 方法论秉承的是“持续集成,小步快走”的哲学,也就是说每一次发布的版本应该尽可能的小,当然前提条件是每个版本有足够的商业价值,值得发布。

    由于小型发布可以使得集成更频繁,客户获得的中间结果也越频繁,反馈也就越频繁,客户就能够实时地了解项目的进展情况,从而提出更多的意见,以便在下一次迭代中计划进去。以实现更高的客户满意度。

    PS 吐槽:走持续集成吧,不然产品真的拼不过向上的互联网公司

    隐喻

    相对而言,隐喻这一个最佳实践是最令人费解的。什么是隐喻呢?根据词典中的解释是:“一种语言的表达手段,它用来暗示字面意义不相似的事物之间的相似之处”。那么这在软件开发中又有什么用呢?总结而言,常常用于四个方面。

    • 寻求共识:也就是鼓励开发人员在寻求问题共识时,可以借用一些沟通双方都比较熟悉的事物来做类比,从而帮助大家更好地理解解决方案的关键结构,也就是更好地理解系统是什么、能做什么。
    • 发明共享词汇:通过隐喻,有助于提出一个用来表示对象、对象间的关系通用名称。例如,策略模式(用来表示可以实现多种不同策略的设计模式)、工厂模式(用来表示可以按需“生产”出所需类得设计模式)等。
    • 创新的武器:有的时候,可以借助其他东西来找到解决问题的新途径。例如:“我们可以将工作流看做一个生产线”。
    • 描述体系结构:体系结构是比较抽象的,引入隐喻能够大大减轻理解的复杂度。例如管道体系结构就是指两个构件之间通过一条传递消息的“管道”进行通信。

    当然,如果能够找到合适的隐喻是十分快乐的,但并不是每种情况都可以找到恰当的隐喻,你也没有必要强求

    简单设计

    强调简单设计的价值观,引出了简单性假设原则,落到实处就是“简单设计”实践。这个实践看上去似乎很容易理解,但却又经常被误解,许多批评者就指责 XP 忽略设计是不正确的。其实,XP 的简单设计实践并不是要忽略设计,而且认为设计不应该在编码之前一次性完成,因为那样只能建立在“情况不会发生变化”或者“我们可以预见所有的变化”之类的谎言的基础上的。

    Kent Beck 概念中简单设计是这样的:

    • 能够通过所有的测试程序。
    • 没有包括任何重复的代码。
    • 清楚地表现了程序员赋予的所有意图。
    • 包括尽可能少的类和方法
    • 他认为要想保持设计简单的系统,需要具备简单思考的能力,拥有理解代码和修改的勇气,以及为了消除代码的“坏味道”而定期重构的习惯。
    • 那么如何开始进行简单的设计呢?XP 实践者们也总结也一些具体的、可操作的思考方法。
    • 首先写测试代码:具体将在后面详细描述。
    • 保持每个类只负责一件事:SRP(单一职责原则)是面向对象设计的基础原则之一。
    • 使用 Demeter(迪米特)法则:迪米特法则,也称为 LoD 法则、最少知识原则。也就是指一个对象应当对其他对象尽可能少地了解。用隐喻的方法来解释的话就是“只与你直接的朋友通信”、“不要和陌生人说话”。
    • 使用 CRC 卡片进行探索。

    测试先行/测试驱动开发

    当我第一次看到“测试先行”这个概念的时候,我的第一感觉就是不解,陷入了“程序都还没有写出来,测试什么呀?”的迷思。我开始天马行空地寻求相关的隐喻,终于找到了能够启发我的工匠,首先,我们来看看两个不同的工匠是如何工作的吧。

    • 工匠一:先拉上一根水平线,砌每一块砖时,都与这跟水平线进行比较,使得每一块砖都保持水平。
    • 工匠二:先将一排砖都砌完,然后再拉上一根水平线,看看哪些砖有问题,对有问题的砖进行适当的调整。

    你会选择哪种工作方法呢?你一定会骂工匠二笨吧!这样多浪费时间呀!然而你自己想想,你平时在编写程序的时候又是怎么做的呢?我们就是按工匠二的方法在工作呀!甚至有时候比工匠二还笨,是整面墙都砌完了,直接进行“集成测试”,经常让整面的墙倒塌。看到这里,你还会觉得自己的方法高明吗?这个连工匠都明白的道理,自己却画地为牢呀。

    不仅我们没有采用工匠一的工作方法,甚至有的时候程序员会以“开发工作太紧张”为理由,而忽略测试工作。但这样却导致了一个恶性循环,越是没有空编写测试程序,代码的效率与质量越差,花在找 Bug、解决 Bug 的时间也越来越多,实际产能大打降低。由于产能降低了,因此时间更紧张,压力更大。你想想,为什么不拉上一根水平线呢?难道,我们不能够将后面浪费的时间花在单元测试上,使得我们的程序一开始就更健壮,更加易于修改吗?不过,编写测试程序当然要比拉一条水平线难道多,所以我们需要引入“自动化测试工具”,免费的 xUnit 测试框架就是你最佳的选择。

    为了鼓励程序员原意甚至喜欢在编写程序之前编写测试代码,XP 方法论还提供了许多有说服力的理由。

    • 如果你已经保持了简单的设计,那么编写测试代码根本不难。
    • 如果你在结对编程,那么如果你想出一个好的测试代码,那么你的伙伴一定行。
    • 当所有的测试都通过的时候,你再也不会担心所写的代码今后会“暗箭伤人”,那种感觉是相当棒的。
    • 当你的客户看到所有的测试都通过的时候,会对程序充满前所未有的信心。
    • 当你需要进行重构时,测试代码会给你带来更大的勇气,因为你要测试是否重构成功只需要一个按钮。

    测试先行是 XP 方法论中一个十分重要的最佳实践,并且其中所蕴含的知识与方法也十分丰富。

    PS 吐槽:是啊测试也要强,你会发现一个好的互联网公司,不仅开发强,是什么都强!!要想改变产品的质量,人员的变革是必不可少的

    重构

    重构时一种对代码进行改进而不影响功能实现的技术,XP 需要开发人员在闻到代码的坏味道时,有重构代码的勇气。重构的目的是降低变化引发的风险,使得代码优化更加容易。通常重构发生在两种情况之下。

    • 实现某个特性之前:尝试改变现有的代码结构,以使得实现新的特性更加容易。
    • 实现某个特性之后:检查刚刚写完的代码后,认真检查一下,看是否能够进行简化。

    在《重构》一书中,作者 Martin Fowler 提示我们:在考虑重构时,应该要养成编写并经常运行测试代码的习惯;要先编写代码,再进行重构;把每一次增加功能都当做一次重构的好时机;将每一个纠正错误当做一次重构的重要时机。同时,该书中也列出大量需要重构的情况和重构方法。

    最后类似地,给还没有足够勇气进行重构的程序员打几剂强心针:

    • XP 提倡集体代码所有制,因此你可以大胆地在任何需要修改的地方做改动。
    • 由于在 XP 项目组中有完整的编码标准,因此在重构前无须重新定义格式。
    • 在重构中遇到困难,和你结对编程的伙伴能够为你提供有效的帮助。
    • 简单的设计,会给重构带来很大的帮助。
    • 测试先行让你拥有了一个有效的检验器,随时运行一下就知道你重构的工作是否带来了影响。
    • 由于 XP 在持续集成,因此你重构所带来的破坏很快就能够暴露,并且得以解决。

    重构技术是对简单性设计的一个良好的补充,也是 XP 中重视“优质工作”的体现,这也是优秀的程序员必备的一项技能

    PS 吐槽:拿的工资多的

    结对编程

    “什么!两个人坐在一起写程序?那岂不是对人力的巨大浪费吗?而且我在工作时可不喜欢有一个人坐在边上当检察官。”是的,正如这里列举出来的问题一样,结对编程技术还是被很多人质疑的。

    不过,自从 20 世纪 60 年代,就有类似的实践在进行,长期以来的研究结果却给出了另外一番景象,那就是结对编程的效率反而比单独编程更高。一开始虽然会牺牲一些速度,但慢慢的,开发速度会逐渐加快,究其原因,主要是结对编程大打降低了沟通的成本,提供了工作的质量,具体表现在:

    • 所有的设计决策确保不是由一个人做出的。
    • 系统的任何一个部分都肯定至少有 2 个人以上熟悉。
    • 几乎不可能有 2 个人都忽略的测试项或者其他任务
    • 结对组合的动态性,是一个企业知识管理的好途径。
    • 代码总是能够保证被评审过。
    • 而且 XP 方法论集成的其他最佳实践也能够使得结对编程更加容易进行:
    • 编码标准可以消除一些无谓的分歧。
    • 隐喻可以帮助结对伙伴更好地沟通。
    • 简单设计可以使得结对伙伴更了解他们所从事的工作。

    结对编程技术被誉为 XP 保持工作质量、强调人文主义的一个典型的实践,应用得当还能够使得开发团队之前的协作更加流畅、知识交流与共享更加频繁,团队的稳定性也会更加稳固。

    PS 吐槽:其实吧,在中国不太好有这样的环境,大多数老板是以先赚钱后产品为生,不是以产品为上后打销路的。。。

    集体代码所有制

    由于 XP 方法论鼓励团队进行结对编程,而且认为结对编程的组合应该动态地搭配,根据任务的不同、专业技能的不同进行最优组合。由于每个人都肯定会遇到不同的代码,所以代码的所有制就不再适合于私有,因为那样会给修改工作带来巨大的不便

    也就是说,团队中的每个成员都拥有对代码进行改进的权利,每个人都拥有全部代码,也都需要对全部代码负责。同时,XP 强调代码是谁破坏的(也就是修改后发生问题),就应该由谁来修复。

    由于在 XP 中,有一些与之匹配的最佳实践,因此你并无须担心采用集体代码所有制会让你的代码变得越来越乱:

    • 由于在 XP 项目中,集成工作是一件经常性得工作,因此当有人修改代码而带来了集成的问题,会在很快的时间内被发现。
    • 由于每一个类都会有一个测试代码,因此不论谁修改了代码,都需要运行这个测试代码,这样偶然性的破坏发生的概率将很小。
    • 由于每一个代码的修改就是通过了结对的两个程序员共同思考,因此通常做出的修改都是对系统有益的。
    • 由于大家都坚持了相同的编码标准,因此代码的可读性、可修改性都会比较好,而且还能够避免由于命名法、缩进等小问题引发经常性得代码修改。

    集成代码所有制是 XP 与其他敏捷方法的一个较大不同,也是从另一个侧面体现了 XP 中蕴含的很深厚的编码情节。

    PS 吐槽:其实吧,在中国敢把代码给你,疯了吧????

    持续集成

    在前面谈到小型发布、重构、结对编程、集体代码所有制等最佳实践的时候,我们多次看到“持续集成”的身影,可以说持续集成是对这些最佳实践的基本支撑条件。

    可能大家会对持续集成与小型发布代表的意思混淆不清,其实小型发布是指在开发周期经常发布中间版本,而持续集成的含义则是要求 XP 团队每天尽可能多次地做代码集成,每次都在确保系统运行的单元测试通过之后进行。

    这样,就可以及早地暴露、消除由于重构、集体代码所有制所引入的错误,从而减少解决问题的痛苦

    要在开发过程中做到持续集成并不容易,首先需要养成这个习惯。而且集成工作往往是十分枯燥、烦琐的,因此适当地引入每日集成工具是十分必要的。XP 建议大家首先使用配置管理服务器将代码管理起来,然后使用 Ant 或 Nant 等 XP 工具,编写集成脚本,调用 xUint 等测试框架,这样就可以实现每当程序员将代码 Check in 到配置服务器上时,Ant 就会自动完成编译和集成,并调用测试代码完成相应的测试工作。

    每周工作 40 小时/可持续的速度

    这是最让开发人员开心的、管理者反对的一个最佳实践了,加班、再加班早已成为开发人员的家常便饭,也是管理者最常使用的一种策略,而 XP 方法论认为,加班最终会扼杀团队的积极性,最终导致项目失败,这也充分体现了 XP 方法关注人的因素比关注过程的因素更多一些。

    Kent Beck 认为开发人员即使能够工作更长的时间,他们也不该这样做,因为这样做会使他们更容易厌倦编程工作,从而产生一些影响他们效能的其他问题。因此,每周工作 40 小时是一种顺势行为,是一种规律。其实对于开发人员和管理者来说,违反这种规律是不值得的。

    • 开发人员:如果不懂得休息,那么就无法将自己的节奏调整到最佳状态,那么就会带来很大的负面影响。而且在精神不集中的状态下,开发质量也得不到保证。
    • 管理者:也许这可以称得上“第二种人月神话”,那就是你不得不通过延长每天的工作时间来获得更多的人月。这是因为,每个开发人员的工作精力是有限的,不可能无限增长,在精力不足的时候,不仅写出来的代码质量没有保障,而且还可能为项目带来退步的效果。因此采用加班的方式并不是一个理性的方式,是得不偿失的。

    不过有一点是需要解释的,“每周工作 40 小时”中的 40 不是一个绝对数,它所代表的意思是团队应该保证按照“正常的时间”进行工作。那么如何做到这一点呢?

    • 首先,定义符合你团队情况的“正常工作时间”。
    • 其次,逐步将工作时间调整到“正常工作时间”。
    • 再次,除非你的时间计划一团糟,否则不应该在时间妥协。
    • 最后,鼓起勇气,制定一个合情合理的时间表。

    正如米卢说过的“享受足球”一样,同样地,每一个开发人员应该做到“享受编程”,那么“每周工作 40 小时”就是你的起点。

    团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作,他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑。

    PS 吐槽:这里的40小时 是打引号的哈哈哈

    现场客户

    为了保证开发出来的结果与客户的预想接近,XP 方法论认为最重要的需要将客户请到开发现场。就像计划游戏中提到过的,在 XP 项目中,应该时刻保证客户负责业务决策,开发团队负责技术决策。因此,在项目中有客户在现场明确用户故事,并做出相应的业务决策,对于 XP 项目而言有着十分重要的意义。

    也许有人会问,客户提交了用户故事之后不就完成工作了吗?其实很多尝试过用户故事的团队都会发现其太过简单,包含的信息量极少,XP方法论不会不了解,因此,不会把用户故事当做开发人员交付代码的唯一指示。用户故事只是一个起点,后面的细节还需要开发人员与客户之间建立起来的良好沟通来补充。

    作为一名有经验的开发人员,绝对不会对现场客户的价值产生任何怀疑,但是都会觉得想要实现现场客户十分困难。要实现这一点,需要对客户进行沟通,让其明白,想对于开发团队,项目成功对于客户而言更为重要。而现场客户则是保障项目成功的一个重要措施,想想在你装修房子的时候,你是不是常常在充当现场客户的角色呢?其实这隐喻就是让客户理解现场客户重要性最好的突破口。

    其实现场客户在具体实施时,也不是一定需要客户一直和开发团队在一起,而是在开发团队应该和客户能够随时沟通,可以是面谈,可以是在线聊天,可以是电话,当然面谈是必不可少的。其中的关键是当开发人员需要客户做出业务决策是,需要进一步了解业务细节时能够随时找到相应的客户。

    不过,也有一些项目是可以不要现场客户参与的:

    • 当开发组织中已经有相关的领域专家时。
    • 当做一些探索性工作,而且客户也不知道他想要什么时(例如新产品、新解决方案的研究与开发)。

    去尝试吧,现场客户不仅可以争取得到,而且还能使得团队焕然一新,与客户建立起良好的合作与信任。

    编码标准

    编码标准是一个“雅俗共享”的最佳实践,不管是代表重型方法论的 RUP,PSP,还是代表敏捷方法论的 XP,都认为开发团队应该拥有一个编码标准。XP 方法论认为拥有编码标准可以避免团队在一些与开发进度无关的细节问题上发生争论,而且会给重构、结对编程带来很大麻烦。试想如果有人将你上次写的代码的变量命名法做了修改,下次你需要再改这部分代码时,会是一种什么感觉呢?

    不过,XP 方法论的编码标准的目的不是创建一个事无巨细的规则表,而是只要能够提供一个确保代码清晰,便于交流的指导方针。

    如果你的团队已经拥有编码标准,就可以直接使用它,并在过程中进行完善。如果还没有,那么大家可以先进行编码,然后在过程中逐步总结出编码规则,边做边形成。当然除了这种文字规范以外,还可以采用一些如自动格式化代码工具之类的方法进行代码规范。,事实上,你只需要很好地贯彻执行其他的实践并且进行沟通,编码标准会很容易地浮现出来。

    PS 吐槽:我看不懂你,你看不懂我

    配合是关键

    有句经典名言“1+1 > 2 ”最适合表达 XP 的观点,Kent Beck 认为 XP 方法论的最大价值在于在项目中融会贯通地运用12个最佳实践,而非单独地使用。你当然可以使用其中的一些实践,但这并不意味着你就运用了 XP 方法论。XP 方法论真正能够发挥其效能,就必须完整地运用12个实践。

    在这里插入图片描述

    其实吧,唉算了不总结了,好好工作吧,多学一点~~~~

    本文参考

    展开全文
  • 极限编程一览

    千次阅读 多人点赞 2019-12-02 10:07:26
    极限编程(XP)的起源始于1990年代,当时肯特·布莱克(Kent Black)在戴姆勒克莱斯勒(DaimlerChrysler)处理项目时试图寻找一种更好的软件开发方法。他的新方法后来被称为极限编程方法论,并被证明是一种成功的...
  • 极限测试主要由两部分测试组成:单元测试和验收测试。 一、单元测试 单元测试是极限测试中主要采用的测试方法,它具有两条简单规则: 所有代码模块在编码开始之前必须设计好单元测试用例。 在产品发布之前需要...
  • 极限编程(中文pdf)

    热门讨论 2020-07-21 09:57:55
    极限编程极限编程极限编程极限编程极限编程极限编程极限编程极限编程极限编程极限编程极限编程
  • 极限编程是敏捷编程中最负盛名的一个,其名称中“极限”二字的含义是指把好的开发实践运用到极致。目前,极限编程已经成为一个典型的开发方法,广泛应用于需求模糊且经常改变的场合。 下面简述极限编程方法采用的...
  • 极限编程四个核心的理解

    千次阅读 2012-05-03 15:05:53
    极限编程的核心有四个:交流、简单、反馈、勇气这四个原则大家在平时做项目的过程中一定也注意到了,但是两位大师 Kent Beck 和 Martin Fowler 能够把这四点归结在一起,使他们能够共同组成极限编程这架四轮马车,却...
  • 敏捷开发与极限编程

    千次阅读 2010-03-16 22:57:00
    敏捷开发与极限编程简介 2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟,敏捷开发...
  • 极限编程的例子 极限编程的例子 极限编程的例子 极限编程的例子 极限编程的例子极限编程的例子极限编程的例子极限编程的例子极限编程的例子
  • 极限编程为什么不适合中国国情?

    千次阅读 2014-12-21 12:41:51
    极限编程为什么不适合中国国情?  2009-01-06 16:01:20| 分类: 技术研讨|举报|字号 订阅 XP为什么不适合国内的现状?下面是我个人的一些看法。 针对极限编程的准则: 用户故事 先...
  • 极限编程最佳实践的深入研究

    千次阅读 2006-10-06 16:53:00
    极限编程最佳实践的深入研究 目录极限编程概述... 1极限编程的力量源泉... 2极限编程的真谛... 4极限编程的假设... 4极限编程的真谛... 6极限编程的最佳实践... 11首先,是计划阶段... 11然后,是开发
  • 极限编程缺点 极限编程(XP)是一种敏捷方法 ,被认为是软件开发中最有效的方法之一。 它以测试优先的开发方案运行。 它具有短期计划,同时高度适应需求的变化,并且由高生产率的团队组成,这些团队可以快速有效地...
  • 极限编程感悟

    2007-01-11 11:31:00
    极限编程又称xp方法,是敏捷开发的软件过程模型。 极限编程的4条准则:沟通,简单,反馈和勇气(修复缺陷,集中攻关和放弃原有的代码)。 基本原则:快速反馈,假设简单,递增更改,提倡更改,优质工作。 开发...
  • 极限编程四个核心的理解(一)

    千次阅读 2005-04-18 16:34:00
    极限编程的核心有四个,交流、简单、反馈和勇气,这四个原则大家在平时做项目的过程中一定也注意到了。但是两位大师Kent Beck 和 Martin Fowler能够把这四点归结在一起,使他们能够共同组成极限编程这架四轮马车,却...
  • 极限编程思想

    2018-08-14 18:06:26
    极限编程(XP)是一种新型的软件开发方法论,它的构想是结合了许多种“程序员真想这么做”的方法而成的。 XP 是由一组被证明有效的实行方法所组成的,这些方法都是被设计来共同运作,这些方法包括: 多次经常性...
  • 极限编程实践

    2017-08-07 11:20:15
    极限编程实践 1、完整团队   XP项目的所有参与者(开发人员、客户、测试人员等)一起工作在一个开放的场所中,他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们...
  • 极限编程与敏捷开发

    千次阅读 2005-12-10 15:51:00
    在按照我的理解方式审查了软件开发的生命周期后,我得出一个结论:实际上满足工程设计标准的惟一软件文档,就是源代码清单。 -- Jack Reeves 简介 2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批...
1 2 3 4 5 ... 20
收藏数 46,152
精华内容 18,460
关键字:

极限编程