极限编程 - 实践


极限编程有四种基本活动。他们是 -

  • 编码

  • 测试

  • 听力

  • 设计

这四项基本活动需要根据极限编程原则来构建。为了实现这一目标,定义了极限编程实践。

这 12 种极限编程实践实现了极限编程的目标,只要其中一种实践的弱点,其他实践的优势就会弥补。

《极限编程解释》一书的作者 Kent Beck 定义了 12 种极限编程实践,如下所示:

  • 规划游戏

  • 简短版本

  • 隐喻

  • 简单的设计

  • 测试

  • 重构

  • 结对编程

  • 集体所有制

  • 持续集成

  • 每周 40 小时

  • 现场客户

  • 编码标准

极限编程的四个领域

极限编程实践可以分为四个领域 -

  • 快速、精细的反馈 -

    • 测试

    • 现场客户

    • 结对编程

  • 连续过程 -

    • 持续集成

    • 重构

    • 简短版本

  • 共同理解 -

    • 规划游戏

    • 简单的设计

    • 隐喻

    • 集体所有制

    • 编码标准

  • 开发者福利 -

    • 每周四十小时

在本章中,您将详细了解极限编程实践以及每种实践的优点。

极限编程实践概览

下图显示了极限编程是如何围绕极限编程实践编织的 -

极限编程实践

规划游戏

极限编程中的主要规划过程称为规划游戏。该游戏是每次迭代发生一次的会议,通常每周一次。规划游戏是为了通过结合业务优先级和技术估算来快速确定下一个版本的范围。当现实超越计划时,更新计划。

业务和开发需要同时做出决策。业务决策和开发的技术决策必须相互协调。

商界人士需要决定 -

  • 范围- 必须解决多少问题才能使系统在生产中有价值?商人能够了解多少是不够的,多少是太多。

  • 优先级- 如果给你一个选择,你想要哪个?业务人员比开发人员更有能力根据客户的意见来确定这一点。

  • 版本的组成- 在使用该软件比不使用该软件的业务效果更好之前,需要做多少工作?开发人员对这个问题的直觉可能是非常错误的。

  • 发布日期- 软件(或某些软件)的存在会产生重大影响的重要日期是什么?

技术人员需要决定 -

  • 估计- 功能需要多长时间才能实现?

  • 后果- 只有在了解技术后果后才应做出战略业务决策。发展需要解释后果。

  • 流程- 工作和团队将如何组织?团队需要适应其运作所在的文化。软件必须写得好,而不是保留封闭文化的非理性。

  • 详细的计划- 在一个版本中,应该首先完成哪些故事?开发人员需要首先自由地安排风险最高的开发部分,以降低项目的整体风险。在这种限制下,他们仍然倾向于在开发的早期阶段转移业务优先级,从而减少由于时间限制而在版本开发结束时不得不放弃重要故事的机会。

因此,计划是客户、业务人员和开发人员之间协作的结果。

规划游戏——优势

规划游戏具有以下优点 -

  • 减少时间,浪费在无用的功能上

  • 客户更加欣赏某项功能的成本

  • 减少规划中的猜测

简短版本

您应该将一个简单的系统快速投入生产,然后在很短的周期内发布新版本。每个版本都应该尽可能小,以便它 -

  • 可在短周期内实现

  • 包含最有价值、最直接的业务需求

  • 一个工作系统

短周期的持续时间可能因需要构建的软件而异。然而,需要确保选择尽可能短的持续时间。

简短版本 – 优点

简短版本的优点是 -

  • 频繁反馈

  • 追踪

  • 减少整体项目延误的可能性

隐喻

根据剑桥在线词典,隐喻是一种经常出现在文献中的表达方式,通过引用被认为与该人或物体具有相似特征的事物来描述一个人或物体。例如,“思想是海洋”和“城市是丛林”都是隐喻。

您应该通过一个关于整个系统如何工作的简单共享故事来指导整个开发。您可以将隐喻视为要以参与开发的每个人都容易理解的方式构建的系统架构。

该隐喻由特定领域的元素组成,并显示了它们的互连性。使用的语言是域语言。为了识别技术实体,隐喻中使用的词语需要保持一致。

随着开发的进行和隐喻的成熟,整个团队将从研究隐喻中找到新的灵感。

一个好的架构的目标是为每个人提供一个连贯的工作故事,一个可以轻松地被业务和技术成员共享的故事。因此,在极限编程中,通过要求一个隐喻,我们很可能获得一个易于沟通和阐述的架构。

比喻——优点

隐喻的优点是 -

  • 鼓励系统使用一组通用术语

  • 减少流行语和行话

  • 一种快速简单的方法来解释系统

简单的设计

在任何给定时刻,系统的设计都应该尽可能简单。额外的复杂性一旦被发现就会被消除。

在任何给定时间,软件的正确设计是 -

  • 运行所有测试

  • 没有像并行类层次结构那样的重复逻辑

  • 陈述对开发人员重要的每一个意图

  • 具有尽可能少的类和方法

要获得简单的设计,请在不违反前三个规则的情况下消除任何可以消除的设计元素。这与“为今天实施,为明天设计”的建议相反。如果你相信未来是不确定的,并且你可以快速增强设计,那么就不要对任何功能进行猜测。

简单的设计 – 优点

简单设计的优点是 -

  • 时间不会浪费在添加多余的功能上

  • 更容易理解发生了什么

  • 重构和集体所有权成为可能

  • 帮助程序员保持正轨

测试

开发人员不断编写单元测试,需要通过这些测试才能继续开发。客户编写测试来验证功能是否已实现。测试是自动化的,因此它们成为系统的一部分,并且可以连续运行以确保系统的工作。结果是一个能够接受变化的系统。

测试 – 优点

测试的优点是 -

  • 单元测试促进测试完整性

  • 测试优先为开发人员提供了一个目标

  • 自动化提供了一套回归测试

重构

在实现某个功能时,开发人员总是会询问是否有一种方法可以更改现有代码以使添加功能变得简单。添加功能后,开发人员询问他们现在是否可以了解如何使代码更简单,同时仍然运行所有测试。他们在不改变系统Behave的情况下重组系统,以消除重复、改善沟通、简化或增加灵活性。这称为重构。

重构——优点

重构的优点是 -

  • 促使开发人员主动改进整个产品

  • 增加开发人员对系统的了解

结对编程

在结对编程中,整个代码由两名开发人员在一台机器上编写,使用一个键盘和一个鼠标。

每对有两个角色 -

  • 第一个开发人员(拥有键盘和鼠标的开发人员)在这里思考实现此方法的最佳方式。

  • 另一个开发商的思考更具战略性

    • 这整个方法会起作用吗?

    • 还有哪些其他可能无法正常工作的测试用例?

    • 有没有什么方法可以简化整个系统,从而使当前的问题消失?

配对是动态的。这意味着A和B这两个角色可能会交换位置,也可能会与其他团队成员配对。更多时候,团队中的任何人都会充当合作伙伴。例如,如果您负责一个您不熟悉的领域的任务,您可能会要求最近有经验的人与您结对。

结对编程——优点

结对编程的优点是 -

  • 三个臭皮匠顶个诸葛亮

  • 重点

  • 两个人更有可能回答以下问题 -

    • 这整个方法会起作用吗?

    • 有哪些测试用例可能还无法工作?

    • 有没有办法简化这个?

集体所有制

在极限编程中,整个团队对整个系统负责。尽管每个人都对每个部分有所了解,但并非每个人都同样了解每个部分。

如果两人正在工作并且他们看到了改进代码的机会,他们就会继续改进它。

集体所有制——优点

集体所有制的优点是 -

  • 有助于减轻离开团队成员的损失。

  • 促进开发人员对系统整体而不是系统的某些部分负责。

持续集成

代码每天会集成和测试多次,一次进行一组更改。一个简单的方法是拥有一台专门用于集成的机器。一对已准备好集成的代码 -

  • 当机器空闲时坐下。

  • 加载当前版本。

  • 加载他们的更改(检查并解决任何冲突)。

  • 运行测试直到通过(100%正确)。

一次集成一组更改有助于了解谁应该修复失败的测试。答案是当前的一对,因为最后一对的测试结果为 100%。他们可能不得不放弃已经做过的事情并重新开始,因为他们可能还没有足够的知识来编写该功能。

持续集成——优点

持续集成的优点是 -

  • 减少持续时间,否则会很长。

  • 启用短期发布实践,因为发布前所需的时间很短。

每周 40 小时

极限编程强调每个团队成员每周的工作时间有限,根据其可持续性,每周最多 45 小时。如果有人工作的时间超过这个时间,就被视为加班。最多允许加班一周。这样的做法是为了确保每个团队成员都充满新鲜感、创造力、细心和自信。

每周 40 小时 – 优势

每周工作 40 小时的优点是 -

  • 大多数开发人员在 40 小时后就会失去效率。

  • 开发商的福祉受到重视。

  • 管理层被迫寻找真正的解决方案。

现场客户

在团队中包含一名真实的实时用户,他可以全职回答问题、解决争议并设置小规模的优先事项。该用户可能不必只在这个角色上花费 40 小时,还可以专注于其他工作。

现场客户 – 优势

拥有现场客户的优势是 -

  • 能够对真正的开发问题给出快速且知识渊博的答案。

  • 确保开发的内容正是需要的。

  • 功能的优先级正确。

编码标准

开发人员按照以下规则编写所有代码:

  • 通过代码进行通信。

  • 尽可能少的工作量。

  • 符合“一次且仅一次”规则(无重复代码)。

  • 整个团队自愿采用。

这些规则在极限编程中是必要的,因为所有开发人员 -

  • 可以从系统的一个部分更改为系统的另一部分。

  • 每天交换几次伙伴。

  • 不断重构彼此的代码。

如果不遵守规则,开发人员将倾向于采用不同的编码实践,随着时间的推移,代码会变得不一致,并且无法确定团队中的谁编写了哪些代码。

编码标准 – 优点

编码标准的优点是 -

  • 减少开发人员重新格式化其他人的代码所花费的时间。

  • 减少内部评论的需要。

  • 需要清晰、明确的代码。