软件工程/过程/极限编程简介
极限编程 (XP) 是一种软件开发方法，旨在提高软件质量和对不断变化的客户需求的响应能力。作为敏捷软件开发的一种类型，[1][2][3] 它提倡在短期开发周期（时间盒）中进行频繁的“发布”，旨在提高生产力并引入可以采用新客户需求的检查点。
极限编程的其他元素包括：结对编程或进行广泛的代码审查、所有代码的单元测试、避免在实际需要之前编写功能、扁平化的管理结构、代码的简洁性和清晰度、随着时间的推移和对问题的更深入了解，期望客户需求的变化，以及与客户和程序员之间的频繁沟通。[2][3][4] 该方法的名称来源于将传统软件工程实践的有益元素提升到“极限”水平的想法，理论上，如果一些东西好，更多就更好。它与“牛仔式编码”无关，后者更加自由形式化和无计划性。它不提倡“死亡行军”式的工作时间安排，而是提倡以可持续的节奏工作。[5]
批评者指出了一些潜在的缺点，[6] 包括对不稳定需求问题的处理、对用户冲突没有记录的妥协，以及缺乏总体设计规范或文档。
历史
[edit | edit source]极限编程是由肯特·贝克在克莱斯勒综合薪酬系统 (C3) 薪资项目工作期间创建的。[6] 贝克于 1996 年 3 月成为 C3 项目负责人，并开始完善项目中使用的开发方法，并编写了一本关于该方法的书籍（1999 年 10 月，《极限编程解释》出版）。[6] 克莱斯勒在 2000 年 2 月取消了 C3 项目，当时该公司被戴姆勒-奔驰收购。[7]
虽然极限编程本身比较新，但它的许多实践已经存在了一段时间；毕竟，这种方法将“最佳实践”提升到极限水平。例如，“在每个微增量之前先编写测试的测试驱动开发实践”早在 1960 年代初期的美国国家航空航天局水星计划就被使用（Larman 2003)。为了缩短总开发时间，一些正式的测试文档（例如验收测试）是在软件准备测试时（或之前不久）开发的。在 XP 中，通过编写自动化测试（可能位于软件模块内部）来验证即使是最小的软件编码部分的操作，而不是仅仅测试较大的功能，将这一概念提升到了极致。一些其他 XP 实践，例如重构、模块化、自底向上设计和增量设计，由利奥·布罗迪在 1984 年出版的书籍中进行了描述。[8]
起源
[edit | edit source]1990 年代的软件开发受到两个主要影响的塑造：在内部，面向对象编程取代了面向过程编程，成为该行业某些人青睐的编程范式；在外部，互联网的兴起和 dot-com 热潮强调了上市速度和公司增长作为竞争优势。快速变化的需求要求缩短产品生命周期，并且往往与传统的软件开发方法不兼容。
克莱斯勒综合薪酬系统启动是为了确定使用对象技术的最佳方法，以克莱斯勒的薪资系统作为研究对象，使用 Smalltalk 作为语言，GemStone 作为数据访问层。他们请来了肯特·贝克，[6] 一位著名的 Smalltalk 从业者，来对系统进行性能调优，但他的角色随着他注意到他们在开发过程中遇到的几个问题而扩大。他抓住这个机会，根据他与他的长期合作者沃德·坎宁安的工作，提出并实施了一些实践上的改变。贝克描述了这些方法的早期构想：[9]
我第一次被要求领导一个团队时，我要求他们做一些我认为明智的事情，比如测试和审查。第二次，风险更大。我心想，“该死的鱼雷，至少这会让文章写得更好，”[并且]要求团队将我认为至关重要的东西的旋钮都调到 10，并排除其他一切。
贝克邀请罗恩·杰弗里斯加入项目，以帮助开发和完善这些方法。此后，杰弗里斯一直担任教练，将这些实践灌输到 C3 团队的习惯中。
有关 XP 背后的原则和实践的信息通过在坎宁安的 WikiWikiWeb 上的原始维基上的讨论传播到更广泛的世界。各种贡献者讨论并扩展了这些想法，并由此产生了一些衍生方法（参见敏捷软件开发）。此外，多年来，XP 网站上的超文本系统地图一直对 XP 概念进行了解释，网址为“http://www.extremeprogramming.org”，大约在 1999 年。
贝克编辑了一系列关于 XP 的书籍，从他自己的《极限编程解释》（1999 年，ISBN 0-201-61641-6）开始，将他的理念传播给更广泛、但非常乐于接受的受众。该系列的作者对 XP 及其实践的各个方面进行了探讨。甚至还有一本书专门批判这些实践。
XP 在 20 世纪 90 年代后期和 20 世纪初引起了轰动，并在许多与起源截然不同的环境中被采用。
最初实践所需的高纪律性往往会消失，导致一些被认为过于严格的实践在个别站点上被弃用或缩减，甚至未完成。例如，针对特定项目的每日结束集成测试实践，可能会改为每周结束的计划，或者简化为相互商定的日期。这种更为宽松的计划可以避免人们为了通过每日结束测试而仓促生成人工存根。更灵活的计划允许在几天的时间内更充分地开发一些复杂的功能。然而，定期进行一些集成测试可以在将过多工作投入到不同方向的错误方向之前，检测到不同小组在非兼容、切线方向上的工作。
与此同时，其他敏捷开发实践并没有停滞不前，XP 仍在不断发展，从实际经验中吸取更多教训，以使用其他实践。在《极限编程解释》的第二版中，贝克增加了更多价值和实践，并将主要实践和辅助实践区分开来。
《极限编程解释》将极限编程描述为一种软件开发纪律，它组织人员以更高效地生产更高质量的软件。
在传统的系统开发方法（如 SSADM 或瀑布模型）中，系统的需求是在开发项目开始时确定的，并且通常从那时起就固定下来。这意味着在后期更改需求的成本（软件工程项目的常见特征[需要引用]）将很高。与其他敏捷软件开发方法一样，XP 试图通过使用多个较短的开发周期来降低变更成本，而不是使用一个较长的开发周期。在这种理论中，变更是在软件开发项目中自然、不可避免且理想的方面，应该对其进行规划，而不是试图定义一组稳定的需求。
极限编程还在敏捷编程框架之上引入了一些基本价值观、原则和实践。
XP 描述了在软件开发过程中执行的四项基本活动：编码、测试、倾听和设计。下面将分别描述这些活动。
XP 的支持者认为，系统开发过程中唯一真正重要的产出是代码 - 计算机可以解释的软件指令。没有代码，就没有可用的产品。
编码还可以用来找出最合适的解决方案。编码还可以帮助传达关于编程问题的想法。一个程序员在处理一个复杂的编程问题，发现难以向其他程序员解释解决方案时，可能会将它编码，并使用代码来演示自己的意思。支持这一观点的人认为，代码始终清晰简洁，不可能被解释为多种含义。其他程序员可以通过编码自己的想法来对这段代码给出反馈。
除非测试一个函数，否则无法确定它是否正常工作。错误和设计错误是软件开发中普遍存在的问题。极限编程的方法是，如果少量测试可以消除一些缺陷，那么大量测试就可以消除更多缺陷。
- 单元测试确定给定功能是否按预期工作。程序员会编写尽可能多的自动化测试，这些测试可能会“破坏”代码；如果所有测试都成功运行，那么编码就完成了。每段编写的代码在继续下一个功能之前都要进行测试。
- 验收测试验证程序员理解的需求是否满足客户的实际需求。这些测试发生在版本规划的探索阶段。
“测试马拉松”是一个程序员见面进行协作测试编写的活动，类似于软件测试方面的头脑风暴。
程序员必须倾听客户需要系统做什么，需要什么“业务逻辑”。他们必须充分理解这些需求，以便向客户提供关于如何解决问题或无法解决问题的技术方面的反馈。客户和程序员之间的沟通在规划游戏中得到了进一步的解决。
从简单性的角度来看，当然可以说系统开发不需要编码、测试和倾听之外的东西。如果这些活动执行得当，结果应该始终是一个可以工作的系统。实际上，这行不通。在没有设计的情况下，可以走很远，但在某个时候，你会卡住。系统变得过于复杂，系统内的依赖关系不再清晰。可以通过创建组织系统逻辑的设计结构来避免这种情况。良好的设计可以避免系统内出现大量依赖关系；这意味着更改系统的一部分不会影响系统的其他部分。
极限编程最初在 1999 年认可了四个价值观。在《极限编程解释》的第二版中增加了一个新的价值观。五个价值观是
构建软件系统需要将系统需求传达给系统开发者。在正式的软件开发方法中，此任务通过文档来完成。极限编程技术可以被视为在开发团队成员之间快速构建和传播机构知识的方法。目标是让所有开发人员对系统的共同观点与系统用户持有的观点相一致。为此，极限编程提倡简单设计、共同隐喻、用户和程序员之间的协作、频繁的口头交流和反馈。
极限编程鼓励从最简单的解决方案开始。额外的功能可以在以后添加。这种方法与更传统的系统开发方法的区别在于，它侧重于为今天而不是明天、下周或下个月的需求进行设计和编码。这有时被概括为“你不会需要它”（YAGNI）方法。[5] XP的支持者承认，这种方法有时会带来明天修改系统需要更多努力的弊端；他们声称，这可以通过以下优势来弥补：不投资于可能在变得相关之前就会发生变化的未来需求。为不确定的未来需求进行编码和设计意味着存在将资源浪费在可能不需要的东西上的风险。与“沟通”价值相关的是，设计和编码的简单性应该提高沟通质量。一个简单的设计和非常简单的代码可以很容易地被团队中的大多数程序员理解。
反馈
[edit | edit source]在极限编程中，反馈与系统开发的不同维度有关。
- 来自系统的反馈：通过编写单元测试，[6] 或运行定期的集成测试，程序员可以从实现更改后系统的状态获得直接反馈。
- 来自客户的反馈：功能测试（也称为验收测试）由客户和测试人员编写。他们将获得有关其系统当前状态的具体反馈。此审查计划每两到三周进行一次，以便客户可以轻松地指导开发工作。
- 来自团队的反馈：当客户在规划游戏中提出新的需求时，团队会直接给出实现这些需求所需时间的估计。
反馈与沟通和简单性密切相关。通过编写证明特定代码段会崩溃的单元测试，可以轻松地传达系统中的缺陷。来自系统的直接反馈告诉程序员重新编写此部分。客户能够根据功能需求（称为用户故事）[6] 定期测试系统。引用肯特·贝克的话说：“乐观是编程的职业病，反馈是治疗方法。”
勇气
[edit | edit source]一些实践体现了勇气。其中一项原则是始终为今天而不是明天进行设计和编码。这是为了避免陷入设计困境，从而需要花费大量精力才能实现其他任何内容。勇气使开发人员能够在需要时对代码进行重构而感到舒适。[6] 这意味着审查现有系统并对其进行修改，以便更容易地实现未来的更改。勇气的另一个例子是知道何时丢弃代码：有勇气删除过时的源代码，无论创建该源代码花费了多少精力。此外，勇气意味着坚持：程序员可能在一天中一直卡在一个复杂的问题上，然后在第二天快速解决问题，只要他们坚持不懈。
尊重
[edit | edit source]尊重价值包括尊重他人以及自尊。程序员不应该提交会导致编译失败、使现有单元测试失败或以其他方式延误同行的工作的更改。成员通过始终追求高质量并通过重构寻求当前解决方案的最佳设计来尊重自己的工作。
采用前面提到的四个价值观会导致获得团队中其他人的尊重。团队中的任何人都不会感到不被重视或被忽视。这确保了高度的动力，并鼓励对团队以及对项目目标的忠诚。这种价值观非常依赖于其他价值观，并且非常注重团队中的人。
规则
[edit | edit source]XP规则的第一个版本由Don Wells[10]于1999年在XP网站上发布。在规划、管理、设计、编码和测试类别中给出了29条规则。明确指出规划、管理和设计是为了反驳XP不支持这些活动的论点。
Ken Auer[11]在2003年的XP/Agile Universe上提出了XP规则的另一个版本。他认为XP是由其规则而不是其实践（实践更容易发生变化和含糊不清）定义的。他定义了两个类别：“参与规则”，规定了软件开发能够有效进行的环境，以及“游戏规则”，定义了在参与规则框架内的逐分钟活动和规则。
原则
[edit | edit source]构成XP基础的原则基于上述价值观，旨在促进系统开发项目中的决策。这些原则旨在比价值观更具体，并且更容易转化为实际情况下的指导。
反馈
[edit | edit source]极限编程认为，如果反馈快速完成，则反馈最有帮助，并表达了行动与其反馈之间的时间对学习和进行更改至关重要。与传统的系统开发方法不同，与客户的接触是在更频繁的迭代中进行的。客户对正在开发的系统有清晰的了解。他或她可以根据需要提供反馈并指导开发工作。
单元测试也有助于快速反馈原则。在编写代码时，单元测试会直接提供有关系统对所做更改的反应方式的反馈。例如，如果更改影响了与进行更改的程序员范围无关的系统的一部分，那么该程序员将不会注意到缺陷。当系统投入生产时，这种错误很可能出现。
假设简单性
[edit | edit source]这是关于将每个问题都视为其解决方案“极其简单”。传统的系统开发方法建议计划未来并为可重用性进行编码。极限编程拒绝这些想法。
极限编程的倡导者表示，一次性进行大的更改并不奏效。极限编程应用增量更改：例如，系统可能每三周发布一次小型版本。当进行许多小的步骤时，客户可以更好地控制开发过程以及正在开发的系统。
拥抱变化
[edit | edit source]拥抱变化的原则就是不反对变化，而是拥抱它们。例如，如果在一次迭代会议上发现客户的需求发生了巨大变化，程序员应该拥抱这种变化，并为下一次迭代计划新的需求。
实践
[edit | edit source]极限编程被描述为有12种实践，分为四个领域
细粒度反馈
[edit | edit source]- 结对编程[6]
- 规划游戏
- 测试驱动开发
- 整个团队
- 持续集成
- 重构或设计改进[6]
- 小版本发布
- 可持续的步伐
- 客户始终可用
- 先编写单元测试代码
- 一次只有一对程序员集成代码
- 将优化留到最后
- 不加班
- 所有代码必须具有单元测试
- 所有代码必须通过所有单元测试才能发布。
- 发现错误时，在解决错误之前先创建测试（错误不是逻辑错误，而是你忘记编写的测试）
- 经常运行验收测试并发布结果
XP 中的实践一直存在争议。[6] 极端编程的支持者认为，通过让现场客户[6] 非正式地提出变更请求，该过程变得灵活，并节省了正式开销的成本。XP 的批评者认为，这会导致代价高昂的返工和项目范围蔓延，超出之前商定的或已获得资金的范围。
变更控制委员会表明多个用户在项目目标和约束方面存在潜在冲突。XP 的快速方法在一定程度上依赖于程序员能够假设统一的客户观点，以便程序员可以专注于编码，而不是记录折衷目标和约束。这也适用于涉及多个编程组织的情况，尤其是那些争夺项目份额的组织。[需要引用]
极端编程的其他潜在争议方面包括
- 需求以自动验收测试的形式表达，而不是规范文档。
- 需求是增量定义的，而不是试图提前获取所有需求。
- 软件开发人员通常需要成对工作。
- 没有前期的大设计。大部分设计活动是在运行中和增量进行的，从 "最简单可行方案" 开始，只有在失败的测试要求时才添加复杂性。批评者将其比作"调试系统使其出现"，并担心这将导致比仅在需求发生变化时进行重新设计更多的重新设计工作。
- 项目中配备了客户代表。这个角色可能成为项目的单点故障，有些人发现它会导致压力。此外，还存在非技术代表进行微观管理的风险，他们试图规定技术软件功能和架构的使用。
- 对 XP 其他所有方面的依赖："XP 就像一圈毒蛇，串联在一起。只要其中一条蛇松脱，就会有一条非常愤怒、有毒的蛇朝你袭来。" [12]
从历史上看，XP 仅适用于 12 人或更少的团队。解决此限制的一种方法是将项目分解成更小的部分，并将团队分解成更小的组。据称，XP 已成功用于超过 100 名开发人员的团队中[需要引用]。ThoughtWorks 声称在多达 60 人的分布式 XP 项目中取得了合理的成功[需要引用]。
2004 年，工业极端编程 (IXP)[13] 作为 XP 的演变而被引入。它旨在带来在大型分布式团队中工作的能力。它现在有 23 种实践和灵活的价值观。由于它是敏捷家族的新成员，没有足够的数据来证明其可用性，但它声称是 XP 缺陷的解决方案。
2003 年，Matt Stephens 和 Doug Rosenberg 出版了《重构极端编程：反对 XP 的论据》，该书质疑 XP 流程的价值，并提出了改进 XP 的方法。这在文章、互联网新闻组和网站聊天区引发了长时间的辩论。这本书的核心论点是，XP 的实践是相互依存的，但很少有实际组织愿意/能够采用所有实践；因此整个过程都会失败。这本书还提出了其他批评，并以负面方式将 XP 的"集体所有权"模型比作社会主义。
自从《重构极端编程》（2003 年）出版以来，XP 的某些方面已经发生了变化；特别是，XP 现在允许对实践进行修改，只要满足所需目标。XP 还使用越来越通用的术语来表示过程。有些人认为这些变化使之前的批评失效；另一些人声称这只是在淡化流程。
RDP 实践是一种定制极端编程的技术。该实践最初是在由 Philippe Kruchten 和 Steve Adolph 组织的研讨会中作为一篇长篇研究论文提出的（参见 APSO 研讨会 在 ICSE 2008 ），但它是唯一提出的和可用于定制 XP 的方法。RDP 实践背后的宝贵理念在短时间内为其在行业的适用性提供了理由。RDP 实践试图通过依赖 XP 规则技术来定制 XP。
其他作者试图将 XP 与更早的方法协调起来，以形成一种统一的方法。XP 试图取代其中一些，例如瀑布模型；例如：项目生命周期：瀑布、快速应用开发等等。摩根大通公司尝试将 XP 与能力成熟度模型集成 (CMMI) 和六西格玛的计算机编程方法结合起来。他们发现这三个系统相互加强，从而导致更好的开发，并且没有相互矛盾。[14]
极端编程最初的炒作和有争议的原则（例如结对编程和持续设计）引起了特别的批评，例如来自 McBreen[15] 和 Boehm 和 Turner[16] 的批评。然而，许多敏捷实践者认为，这些批评是对敏捷开发的误解。[17]
特别是，Matt Stephens 和 Doug Rosenberg 的《重构极端编程》对极端编程进行了审查和批评。[18]
批评包括
- 方法论的有效性取决于参与人员，敏捷无法解决这个问题
- 通常用作通过缺乏可交付成果的定义从客户那里榨取金钱的手段
- 缺乏结构和必要的文档
- 仅适用于高级开发人员
- 包含不足的软件设计
- 需要频繁的会议，给客户带来巨大的开销
- 需要太多的文化变革才能采用
- 可能导致更困难的合同谈判
- 效率低下：如果代码一个区域的要求在多次迭代中发生变化，则可能需要多次重复执行相同的编程。而如果有一个计划要遵循，则预计只需要编写一个代码区域。
- 无法制定提供报价所需的实际工作量估计，因为在项目开始时，没有人知道整个范围/需求
- 由于缺乏详细的需求文档，可能会增加范围蔓延的风险
- 敏捷是功能驱动的；非功能质量属性很难作为用户故事来设置
- ↑ "2005年以人为本的技术研讨会"，2005，PDF 网页：Informatics-UK-report-cdrp585.
- ↑ a b "设计模式和重构"，宾夕法尼亚大学，2003，网页：UPenn-Lectures-design-patterns.
- ↑ a b "极限编程"（讲座论文），USFCA.edu，网页：USFCA-edu-601-lecture.
- ↑ "敏捷软件开发宣言"，敏捷联盟，2001，网页：Manifesto-for-Agile-Software-Dev
- ↑ a b "每个人都是程序员"，作者：克莱尔·特里斯特拉姆。技术评论，2003年11月。第 39 页
- ↑ a b c d e f g h i j k l m "极限编程"，计算机世界（在线），2001年12月，网页：Computerworld-appdev-92.
- ↑ 重构极限编程：反对 XP 的论点. ISBN 1590590961.
{{cite book}}: 未知参数|coauthors=被忽略 (|author=建议) (帮助) - ↑ 布罗迪，莱奥 (1984)。思考 Forth (平装本). 普伦蒂斯-霍尔. ISBN 0-13-917568-7. 检索于 2006-06-19.
{{cite book}}: 引用中存在空的未知参数：|origmonth=，|month=，|chapterurl=，|coauthors=，以及|origdate=(帮助) - ↑ 肯特·贝克和马丁·福勒的访谈
- ↑ 唐·韦尔斯
- ↑ 肯·奥尔
- ↑ 反对极限编程的论点：一个自指安全网
- ↑ Cutter 联盟 :: 工业 XP：在大型组织中使 XP 奏效
- ↑ 极限编程 (XP) 六西格玛 CMMI.
- ↑ 麦克布林，P. (2003)。质疑极限编程. 波士顿，马萨诸塞州：艾迪生-韦斯利. ISBN 0-201-84457-5.
- ↑ 博厄姆，B. (2004)。平衡敏捷性和纪律：困惑之人的指南. 波士顿，马萨诸塞州：艾迪生-韦斯利. ISBN 0-321-18612-5.
{{cite book}}: 未知参数|coauthors=被忽略 (|author=建议) (帮助) - ↑ sdmagazine
- ↑ 重构极限编程，马特·斯蒂芬斯和道格·罗森伯格，出版商：Apress L.P.
- 肯·奥尔和罗伊·米勒。应用极限编程：为胜利而战，艾迪生-韦斯利。
- 肯特·贝克：极限编程解释：拥抱变化，艾迪生-韦斯利。
- 肯特·贝克和马丁·福勒：计划极限编程，艾迪生-韦斯利。
- 肯特·贝克和辛西娅·安德烈斯。极限编程解释：拥抱变化，第二版，艾迪生-韦斯利。
- 阿里斯特·科伯恩：敏捷软件开发，艾迪生-韦斯利。
- 马丁·福勒：重构：改进现有代码的设计，艾迪生-韦斯利。
- 哈维·赫雷拉 (2005)。案例研究：克莱斯勒综合薪酬系统. 盖伦实验室，加州大学欧文分校。
- 吉姆·海史密斯。敏捷软件开发生态系统，艾迪生-韦斯利。
- 罗恩·杰弗里斯，安妮·安德森和切特·亨德里克森 (2000)，极限编程安装，艾迪生-韦斯利。
- 穆罕默德·米拉克霍尔利 (2008)。RDP 技术：定制 XP 的一种实践，国际软件工程大会，2008 年关于审查敏捷实践或敏捷牛仔竞技场枪战的国际研讨会论文集，德国莱比锡 2008，第 23-32 页。
- 克雷格·拉曼和 V. 巴西利 (2003)。“迭代式和增量式开发：简史”，计算机 (IEEE 计算机协会) 36 (6): 47-56。
- 马特·斯蒂芬斯和道格·罗森伯格 (2003)。重构极限编程：反对 XP 的论点，Apress。
- 瓦尔德纳，JB. (2008)。“纳米计算机和群体智能”。在：ISTE，225-256。
- 极限编程
- 一个简要介绍
- 工业极限编程
- XP 杂志
- XP 实施中的问题和解决方案
- 在离岸开发中使用敏捷软件开发流程 - ThoughtWorks 在大型分布式项目中实施 XP 的经验