极端编程

极限编程中的计划和反馈循环

极端编程XP)是软件开发方法打算改进软件质量以及对不断变化的客户需求的响应能力。作为一种敏捷软件开发[1][2][3]它提倡经常出现发行在简短的开发周期中,旨在提高生产率并引入可以采用新客户需求的检查站。

极端编程的其他元素包括:编程成对或做广泛的代码审查单位测试在所有代码中,在实际需要之前不编程功能,平坦的管理结构,代码简单性和清晰度,预计随着时间的流逝,客户的需求会发生变化,并且问题得到了更好的理解,并且经常与客户和程序员之间进行沟通。[2][3][4]该方法的名称是从传统软件工程实践的有益元素提高到“极端”级别的想法。举个例子,代码评论被认为是一种有益的做法;采用极端,可以审查代码连续(即实践配对编程)。

历史

肯特·贝克在他的工作期间开发了极端编程克莱斯勒综合补偿系统(C3)工资单项目.[5]贝克成为C3项目负责人1996年3月。他开始完善项目中使用的开发方法,并写了一本关于方法论的书(极端编程解释了,于1999年10月出版)。[5]克莱斯勒七年后,2000年2月取消了C3项目戴姆勒·奔驰获得了公司。[6]沃德·坎宁安是对XP的另一个主要影响。

许多极端编程的做法已经存在一段时间了。该方法采用”最佳实践“到极端。水星项目,在1960年代初期。[7]为了缩短总开发时间,一些正式的测试文件(例如验收测试)与已准备好测试的软件并行开发。在程序员编写软件并将其与硬件集成之前,NASA独立测试小组可以根据形式要求和逻辑限制编写测试程序。XP将此概念提升到极端层次,编写自动测试(有时是在软件模块内),该测试甚至可以验证软件编码的小部分的操作,而不仅仅是测试较大的功能。

起源

两种主要影响1990年代形状的软件开发:

快速变化的要求要求较短产品生命周期,并且经常与传统的软件开发方法发生冲突。

克莱斯勒综合补偿系统(C3)开始了,以确定使用对象技术的最佳方法,使用克莱斯勒的薪资系统作为研究的对象,并使用短暂聊天作为语言和宝石作为数据访问层。克莱斯勒带来了肯特·贝克[5]一个著名的Smalltalk从业者,要做性能调整在系统上,但是他注意到开发过程中的几个问题,他的角色扩大了。他借此机会提出并实施了开发实践的一些变化 - 根据他与他的经常合作者的工作沃德·坎宁安。贝克描述了这些方法的早期概念:[8]

我第一次被要求领导团队时,我要求他们做一些我认为是明智的事情,例如测试和评论。第二次在线上还有更多。我以为:“该死的鱼雷,至少这会构成一篇很好的文章。”并要求团队将所有旋钮提高到我认为是必不可少的东西并遗漏其他一切的所有旋钮。

贝克邀请罗恩·杰弗里斯(Ron Jeffries)该项目以帮助开发和完善这些方法。此后,杰弗里斯(Jeffries)担任教练,将这些做法灌输为C3团队的习惯。

关于XP背后的原理和实践的信息,通过讨论原始维基,坎宁安的Wikiwikiweb。各种贡献者讨论并扩展了这些想法,并产生了一些分拆方法(请参阅敏捷软件开发)。此外,XP概念已经解释了[通过谁?],几年来,使用超文本XP网站上的系统图http://www.extremeprogramming.org大约1999年。

贝克编辑了一系列有关XP的书籍,从他自己的极端编程解释了(1999,ISBN0-201-61641-6),将他的想法传播给更大的听众。该系列的作者经历了参加XP及其实践的各个方面。该系列包括一本批评这些做法的书。

当前状态

XP在1990年代末和2000年代初在软件社区中引起了极大的兴趣,看到在许多与其起源完全不同的环境中采用。

原始实践所需的高纪律通常经常是在路边,导致其中一些做法,例如那些过于僵化的做法,无法在单个站点上弃用或减少或什至未完成。例如,日末的实践集成测试对于特定项目,可以更改为周末时间表,或者简单地简化为相互商定的日期测试。如此轻松的时间表可以避免人们急于产生人造存根,以通过日末测试。少量的时间表允许在几天内开发复杂功能。

同时,其他敏捷开发实践还没有静止,截至2019年XP继续发展,从该领域的经验中吸收更多的经验教训,以使用其他实践。在第二版极端编程解释了(2004年11月),在第一版五年后,贝克添加了更多和实践,并区分主要和推论实践。

概念

目标

极端编程解释了将极端编程描述为一门软件开发纪律,该纪律组织人们生产更高质量的软件。

XP试图通过拥有多个短期开发周期而不是一个长的一个简短的开发周期来降低需求变化的成本。在这个学说中,变化是软件开发项目的自然,不可避免的和理想的方面,应该计划进行,而不是试图定义一套稳定的要求。

极限编程还在敏捷方法之上引入了许多基本价值,原理和实践。

活动

XP描述了软件开发过程中执行的四个基本活动:编码,测试,聆听和设计。这些活动中的每一个都在下面描述。

编码

XP的拥护者认为,系统开发过程的唯一真正重要的产品是计算机可以解释的软件说明。没有代码,就没有工作产品。

编码可用于找出最合适的解决方案。编码还可以帮助传达有关编程问题的想法。处理复杂的编程问题的程序员,或发现很难向其他程序员解释解决方案,可以简化地对其进行编码,并使用代码来演示其含义。代码,表示这个立场的支持者,总是清晰明确,不能以多种方式解释。其他程序员可以通过编码他们的想法来对此代码提供反馈。

测试

测试对于极端编程至关重要。[9]Extreme编程的方法是,如果进行一些测试可以消除一些缺陷,那么许多测试可以消除更多缺陷。

  • 单位测试确定给定功能是否按预期工作。程序员编写尽可能多的自动测试,他们可以想到可能“破坏”代码。如果所有测试成功运行,则编码完成。在转到下一个功能之前,请测试编写的每个代码。
  • 接受测试验证程序员理解的要求是否满足客户的实际要求。

整个系统集成测试最初,鼓励每天的活动,以便早日检测不兼容的界面,以在与相干功能广泛不同的单独部分之间重新连接。但是,根据系统整体接口的稳定性,将系统范围的集成测试降低到每周或更少。

程序员必须聆听客户需要的系统来做的事情,什么”商业逻辑“需要。他们必须足够好了解这些需求,以使客户有关如何解决问题或无法解决问题的技术方面。客户与程序员之间的沟通在计划游戏.

设计

从简单性的角度来看,当然可以说,系统开发不仅仅是编码,测试和聆听所需的更多。如果这些活动表现良好,则结果应始终是有效的系统。实际上,这将行不通。一个人可以在不设计的情况下走很长一段路,但是在给定的时间里,人们会被卡住。系统变得太复杂了,系统内的依赖性不再明确。可以通过创建组织系统中逻辑的设计结构来避免这种情况。良好的设计将避免系统中的许多依赖性;这意味着更改系统的一部分不会影响系统的其他部分。

极限编程最初在1999年认可了四个值:交流,简单,反馈和勇气。第二版的新价值,尊重极端编程解释了。这五个值如下所述。

沟通

构建软件系统需要将系统要求与系统的开发人员进行通信。在正式的软件开发方法中,此任务是通过文档完成的。极端的编程技术可以看作是快速建立和传播发展团队成员之间机构知识的方法。目的是为所有开发人员提供与系统用户持有的视图相匹配的系统的共享视图。为此,极端编程有利于简单的设计,常见的隐喻,用户和程序员的协作,频繁的口头交流和反馈。

简单

极限编程鼓励从最简单的解决方案开始。然后可以稍后添加额外的功能。这种方法与更常规的系统开发方法之间的区别在于,专注于设计和编码当今的需求,而不是明天,下周或下个月的需求。有时将其总结为“你不需要”(Yagni)方法。[10]XP的支持者承认,有时明天可能需要更多的努力来改变系统。他们的说法是,这是由于不投资可能会在其相关性之前可能会改变的可能性的优势所弥补的。编码和设计不确定未来的需求意味着将资源花在可能不需要的东西上的风险,同时也许延迟了关键特征。与“沟通”价值相关,设计和编码的简单性应提高沟通质量。团队中的大多数程序员可以轻松理解具有非常简单的代码的简单设计。

反馈

在极端编程中,反馈与系统开发的不同维度有关:

  • 系统的反馈:通过写作单位测试[5]或运行定期集成测试,程序员在实施更改后具有从系统状态的直接反馈。
  • 客户的反馈:功能测试(又名接受测试)由客户和测试人员撰写。他们将获得有关系统当前状态的具体反馈。该评论每两三个星期都计划一次,以便客户可以轻松地引导开发。
  • 团队的反馈:当客户在计划游戏中提出新要求时,团队直接提供了实施时间的时间。

反馈与沟通和简单性密切相关。通过编写单位测试,可以轻松传达系统中的缺陷,该单元测试证明某个代码将破裂。系统的直接反馈告诉程序员重新编码此部分。客户能够根据功能要求定期测试系统,称为用户故事.[5]去引用肯特·贝克,“乐观是编程的职业危害。反馈是治疗方法。”[11]

勇气

几种实践体现了勇气。一个是始终为今天而不是明天设计和代码的诫命。这是为了避免在设计上陷入困境,并需要大量努力来实施其他任何操作。勇气使开发人员能够对重构必要时他们的代码。[5]这意味着审查现有系统并修改它,以便可以更轻松地实现未来的更改。勇气的另一个例子是知道何时将代码扔掉:勇于删除已过时的源代码,无论使用多少努力来创建该源代码。同样,勇气意味着持久性:程序员可能会陷入整天的复杂问题上,然后第二天迅速解决问题,但前提是他们坚持不懈。

尊重

尊重价值包括对他人和自尊心的尊重。程序员绝不应提交打破汇编的更改,使现有的单位测试失败或以其他方式延迟同行的工作。成员们始终努力争取高质量,并通过重构寻求最佳的解决方案,以尊重自己的工作。

采用较早的四个价值会导致团队中其他人获得的尊重。团队中的任何人都不会感到不受欢迎或忽略。这样可以确保高水平的动力,并鼓励对团队和项目目标的忠诚。该值取决于其他值,并针对团队合作。

规则

XP规则的第一个版本是由Don Wells于1999年发布的[12]在XP网站上。29规则是在规划,管理,设计,编码和测试的类别中给出的。计划,管理和设计被明确要求反对XP不支持这些活动的主张。

Ken Auer提出了另一个版本的XP规则[13]在XP/Agile Universe 2003中。他认为XP是由其规则定义的,而不是其实践(会受到更多的变化和歧义)。他定义了两个类别:“参与规则”,决定了软件开发可以有效进行的环境,以及“播放规则”,这些规则在参与规则的框架内定义了一分钟的活动和规则。

这是一些规则(不完整):

编码

测试

  • 所有代码必须具有单位测试
  • 所有代码必须通过全部单位测试在发布之前。
  • 当一个漏洞找到了在解决错误之前创建测试(错误不是逻辑中的错误;这是未编写的测试)
  • 接受测试经常运行并发布结果

原则

构成XP基础的原则是基于刚刚描述的值,旨在促进系统开发项目中的决策。这些原则旨在比价值观更具体,在实际情况下更容易转化为指导。

反馈

极限编程认为,如果反馈经常迅速完成,则最有用。它强调,动作与反馈之间的最小延迟对于学习和改变至关重要。与传统的系统开发方法不同,与客户接触的情况更频繁地发生。客户对正在开发的系统有清晰的了解,并可以根据需要提供反馈并引导开发。借助客户的经常反馈,在开发人员花费大量时间实施它之前,将迅速注意到开发人员做出的错误设计决定。

单位测试有助于快速反馈原则。在编写代码时,运行单元测试提供了有关系统对所做更改的反应的直接反馈。这不仅包括运行测试开发人员代码的单元测试,还包括使用一个可以由单个命令启动的自动化流程来运行所有针对所有软件的所有单元测试。这样,如果开发人员的更改导致系统的其他部分的失败,而开发人员几乎不知道或一无所知,则自动化的全单位测试套件将立即揭示失败系统的其他部分以及删除或修改其更改的必要性。在传统的开发实践下,缺乏自动化的,全面的单位测试套件意味着,这种代码更改被开发人员无害,才能保留在适当的位置,仅在整合测试期间出现,或更糟的是,仅在生产中出现;并确定在集成测试前几周甚至几个月中所有开发人员所做的所有更改中,确定哪些代码更改是一项艰巨的任务。

假设简单

这是关于处理每个问题的解决方案“非常简单”。传统的系统开发方法说是为未来计划和可重复使用的编码。极端编程拒绝这些想法。

极端编程的倡导者说,一次进行重大更改是行不通的。极端编程应用增量更改:例如,系统可能每三周发行一次。当制定了许多小步骤时,客户将对开发过程和正在开发的系统有更多控制权。

拥抱变革

拥抱变革的原则是不反对改变,而是拥抱它们。例如,如果在一次迭代会议上,看来客户的要求发生了巨大变化,则程序员将采用这一要求并计划下一次迭代的新要求。

实践

极限编程被描述为有12种实践,分为四个领域:

精细的反馈

连续过程

共同的理解

程序员福利

有争议的方面

XP中的实践已经进行了激烈的辩论。[5]极端编程的支持者声称,通过拥有现场客户[5]请求更改非正式,过程变得灵活,并节省正式开销的成本。XP的批评者声称这可能导致昂贵的返工和项目范围蠕变超越以前的商定或资助。

变更控制板表明,多个用户之间的项目目标和约束存在潜在的冲突。XP的加快方法在某种程度上取决于程序员能够假设统一的客户端观点,因此程序员可以专注于编码,而不是妥协目标和约束的文档。[14]当涉及多个编程组织时,这也适用,尤其是争夺项目股份的组织。

极端编程的其他潜在有争议的方面包括:

  • 要求表示为自动接受测试,而不是规格文档。
  • 需求是逐步定义的,而不是试图提前所有这些。
  • 通常要求软件开发人员成对工作。
  • 没有大型设计。大多数设计活动都在飞行和逐步进行,从“最简单的事情可能起作用”,并且只有在测试失败要求时才添加复杂性。批评家将此与此相提并论。调试一个系统进入外观”,“担心这将导致更重新设计的努力,而不是仅在需求变化时重新设计。
  • 一个客户代表附在项目上。这个角色可能成为该项目的单点失败,有些人发现它是压力的根源。另外,还有微管理通过非技术代表试图决定使用技术软件功能和体系结构的代表。

批评家注意到一些潜在的缺点,[5]包括要求不稳定的问题,没有记录的用户冲突妥协以及缺乏总体设计规范或文档。

可伸缩性

思想工作在分布式XP项目中获得了合理的成功,最多有60人。

2004年,工业极端编程(IXP)[15]被引入为XP的演变。它旨在带来大型和分布式团队工作的能力。它现在有23个实践和灵活的值。

可严重性和响应

2003年,马特·斯蒂芬斯道格·罗森伯格(Doug Rosenberg)出版了极端编程重构:针对XP的情况,这质疑XP过程的价值,并提出了改进的方法。[6]这引发了文章,互联网新闻组和网站聊天区域的漫长辩论。该书的核心论点是XP的做法是相互依存的,但是很少有实践组织愿意/能够采用所有实践。因此,整个过程失败。这本书还提出了其他批评,并以消极的方式将XP的“集体所有权”模式与社会主义相似。

自从出版以来,XP的某些方面已经改变极端编程重构;特别是,只要仍然达到所需的目标,XP现在可以适应实践的修改。XP还为过程使用越来越多的通用术语。有人认为这些变化使以前的批评无效。其他人则声称这只是在浇水。

其他作者试图将XP与较旧的方法调和,以形成统一的方法。其中一些XP试图取代,例如瀑布方法;示例:项目生命周期:瀑布,快速应用开发(rad)等等。摩根大通公司尝试将XP与计算机编程方法相结合能力成熟度模型集成(CMMI),然后六个西格玛。他们发现,这三个系统互相加强,导致更好的发展,并没有相互矛盾。[16]

批评

Extreme编程的最初嗡嗡声和有争议的宗旨,例如配对编程连续设计,吸引了特定的批评,例如来自McBreen的批评[17]还有boehm和Turner,[18]马特·斯蒂芬斯(Matt Stephens)和道格·罗森伯格(Doug Rosenberg)。[19]然而,敏捷从业者认为,许多批评是对敏捷发展的误解。[20]

特别是,马特·斯蒂芬斯(Matt Stephens)和道格·罗森伯格(Doug Rosenberg's)对极端编程进行了审查和批评极端编程重构.[6]

也可以看看

参考

  1. ^“人类中心技术研讨会2006”,2006年,PDF,人类以人为中心的技术研讨会2006
  2. ^一个bUPENN演讲设计模式“设计模式和重构”,宾夕法尼亚大学,2003年存档2010年8月2日,在Wayback Machine.
  3. ^一个bUSFCA-EDU-601讲座极限编程.
  4. ^“敏捷软件开发宣言”。 agileManifesto.org。 2001。检索3月26日,2019.
  5. ^一个bcdefghijklmComputerworld-appdev-92“极端编程”,计算机世界(在线),2001年12月.
  6. ^一个bc罗森伯格,道格;斯蒂芬斯,马特(2003)。极端编程重构:针对XP的情况。 APRESS。ISBN 978-1-59059-096-6.
  7. ^Larman 2003.
  8. ^肯特·贝克(Kent Beck)和马丁·福勒(Martin Fowler)的采访.Informit.com。 2001年3月23日。
  9. ^丽莎·克里斯平(Lisa Crispin);提示屋(2003)。测试极端编程.ISBN 9780321113559.
  10. ^克莱尔·特里斯特拉姆(Clair Tristram)的“每个人都是程序员”。技术评论,2003年11月。 39。
  11. ^贝克,K。(1999)。极端编程解释:拥抱变革。 Addison-Wesley。ISBN 978-0-321-27865-4.
  12. ^“极端编程规则”.极端编程.
  13. ^肯·艾尔存档2008年9月20日,Wayback Machine
  14. ^约翰·卡洛尔(John Carroll);戴维·莫里斯(David Morris)(2015年7月29日)。轻松步骤,第二版敏捷项目管理。在简单的步骤中。 p。 162。ISBN 978-1-84078-703-0.
  15. ^刀具财团。“工业XP:使XP在大型组织中工作 - 切刀财团”.cutter.com.
  16. ^极限编程(XP)六sigma cmmi.
  17. ^McBreen,P。(2003)。质疑极端编程。马萨诸塞州波士顿:Addison-Wesley。ISBN 978-0-201-84457-3.
  18. ^Boehm,B。R. Turner(2004)。平衡敏捷性和纪律:困惑的指南。马萨诸塞州波士顿:Addison-Wesley。ISBN 978-0-321-18612-6.
  19. ^斯蒂芬斯,马特;道格·罗森伯格(Doug Rosenberg)(2004)。极端编程的讽刺。 MA:Dobbs博士杂志。
  20. ^sdmagazine存档2006年3月16日,在Wayback Machine

进一步阅读

  • 肯·艾尔(Ken Auer)和罗伊·米勒(Roy Miller)。应用极限编程:赢得胜利,艾迪生 - 温斯利。
  • 肯·艾尔(Ken Auer);罗恩·杰弗里斯(Ron Jeffries);杰夫·卡纳(Jeff Canna);Glen B. Alleman;丽莎·克里斯平(Lisa Crispin);珍妮特·格雷戈里(Janet Gregory)(2002)。“测试人员灭绝了吗?测试人员如何为XP团队做出贡献?”。极端编程和敏捷方法 - XP/Agile Universe 2002。计算机科学的讲义。卷。2418. Springer-Verlag。p。287。doi10.1007/3-540-45672-4_50.ISBN 978-3-540-44024-6.
  • 肯特·贝克极端编程解释:拥抱变革,艾迪生 - 温斯利。第一版,1999年。第二版,与辛西娅·安德烈斯(Cynthia Andres),2004年。
  • 肯特·贝克马丁·福勒计划极限编程,艾迪生 - 温斯利。
  • Alistair Cockburn敏捷软件开发,艾迪生 - 温斯利。
  • 马丁·福勒重构:改进现有代码的设计。Addison-Wesley。
  • Harvey Herela(2005)。案例研究:克莱斯勒综合补偿系统。 U.C. Galen Lab尔湾。
  • 吉姆·高史密斯(Jim Highsmith).敏捷软件开发生态系统,艾迪生 - 温斯利。
  • 罗恩·杰弗里斯(Ron Jeffries),Ann Anderson和Chet Hendrickson(2000),安装了极端编程,艾迪生 - 温斯利。
  • 克雷格·拉曼(Craig Larman)&V。Basili(2003)。“迭代和增量发展:简短的历史”,计算机(IEEE计算机协会)36(6):47-56。
  • 马特·斯蒂芬斯和道格·罗森伯格(Doug Rosenberg,2003)。极端编程重构:针对XP的情况,Apress。
  • 沃尔德纳(JB)(2008)。“纳米计算机和群体智能”。在:ISTE,225–256。

外部链接