极限编程 - 实践

极限编程中有四个基本活动。它们是 −

  • 编码

  • 测试

  • 聆听

  • 设计

这四个基本活动需要根据极限编程原则进行构建。为了实现这一点,我们定义了极限编程实践。

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

《极限编程解析》的作者 Kent Beck 将 12 种极限编程实践定义为如下 −

  • 规划游戏

  • 短期发布

  • 隐喻

  • 简单设计

  • 测试

  • 重构

  • 结对编程

  • 集体所有权

  • 持续集成

  • 40 小时周

  • 现场客户

  • 编码标准

极限编程的四个领域

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

  • 快速、精细的反馈 −

    • 测试

    • 现场客户

    • 结对编程

  • 持续过程 −

    • 持续集成

    • 重构

    • 简短发布

  • 共享理解 −

    • 规划游戏

    • 简单设计

    • 隐喻

    • 集体所有权

    • 编码标准

  • 开发者福利 −

    • 每周四十小时

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

极限编程实践一目了然

下图展示了极限编程如何围绕极限编程实践进行编织 −

极限编程实践

规划游戏

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

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

业务人员需要决定 −

  • 范围 − 必须解决多少问题才能使系统在生产中具有价值?业务人员能够理解多少是不够的,多少是太多的。

  • 优先级 − 如果给你一个选择,你想要哪一个?业务人员比开发人员更有能力决定这一点,因为他们需要从客户那里获得输入。

  • 发布的组成 − 需要做多少工作才能使业务在使用软件时比不使用软件时更好?开发人员对这个问题的直觉可能大错特错。

  • 发布日期 − 哪些重要日期是软件(或部分软件)的存在会产生重大影响的重要日期?

技术人员需要决定 −

  • 估计 − 实现某个功能需要多长时间?

  • 后果 − 一些战略性业务决策只有在了解技术后果后才能做出。开发需要解释后果。

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

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

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

规划游戏 - 优势

规划游戏具有以下优势和劣势;

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

  • 客户对功能成本的更高评价

  • 规划中的猜测更少

短期发布

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

  • 可在短周期内实现

  • 包含最有价值和最紧迫的业务需求

  • 可运行的系统

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

短版本 - 优势

短版本的优势是 −

  • 频繁反馈

  • 跟踪

  • 减少整体项目延误的机会

隐喻

根据剑桥在线词典,隐喻是一种表达方式,通常出现在文学作品中,通过指代被认为具有与该人或物体相似特征的事物来描述人或物体。例如,"心灵是一片海洋"和"城市是一片丛林"都是隐喻。

您应该用一个简单的共享故事来指导整个开发过程,讲述整个系统是如何工作的。您可以将隐喻视为要构建的系统架构,以便参与开发的每个人都能轻松理解。

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

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

好的架构的目标是为每个人提供一个连贯的故事,让业务和技术成员都可以轻松共享这个故事。因此,在极限编程中,通过要求使用隐喻,我们可能会得到一个易于交流和阐述的架构。

隐喻 - 优势

隐喻的优点是 −

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

  • 减少流行语和行话

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

简单设计

系统在任何时刻都应设计得尽可能简单。一旦发现额外的复杂性,就立即将其消除。

在任何给定时刻,软件的正确设计都是−

  • 运行所有测试

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

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

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

要获得简单的设计,请消除任何可以消除的设计元素,但不要违反前三个规则。这与建议"为今天实施,为明天设计"相反。如果您认为未来是不确定的,并且您可以快速增强设计,那么不要将任何功能放在猜测上。

简单设计 - 优势

简单设计的优势是 −

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

  • 更容易理解正在发生的事情

  • 实现重构和集体所有权

  • 帮助让程序员保持正轨

测试

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

测试 - 优势

测试的优势是 −

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

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

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

重构

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

重构 - 优点

重构的优点是 −

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

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

结对编程

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

每对中有两个角色 −

  • 第一位开发人员(使用键盘和鼠标的开发人员)正在考虑在此实施此方法的最佳方式。

  • 另一位开发人员则更具战略性地思考

    • 整个方法是否可行?

    • 还有哪些测试用例可能尚未奏效?

    • 是否有某种方法可以简化整个系统,以便当前问题消失?

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

结对编程 - 优势

结对编程的优势是 −

  • 三个臭皮匠顶个诸葛亮

  • 专注

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

    • 整个方法会起作用吗?

    • 哪些测试用例可能尚未起作用?

    • 有没有办法简化这一点?

集体所有权

在极限编程中,整个团队对整个系统。虽然每个人都对每个部分有所了解,但并不是每个人都对每个部分都同样了解。

如果一对搭档在工作,并且他们看到了改进代码的机会,他们就会继续改进它。

集体所有权 - 优势

集体所有权的优势是 −

  • 有助于减轻团队成员离职带来的损失。

  • 促使开发人员对整个系统而不是系统的部分负责。

持续集成

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

  • 机器空闲时坐下。

  • 加载当前版本。

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

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

一次集成一组更改有助于了解谁应该修复失败的测试。答案是现在的一对,因为上一对测试保持 100%。他们可能不得不放弃他们所做的一切并重新开始,因为他们可能没有足够的知识来编写该功能。

持续集成 - 优势

持续集成的优势是 −

  • 缩短了原本冗长的持续时间。

  • 由于发布前所需的时间很短,因此可以实现短时间发布。

每周 40 小时

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

每周 40 小时 - 优势

每周 40 小时的优势是 −

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

  • 重视开发人员的福祉。

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

现场客户

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

现场客户 - 优势

拥有现场客户的优势是 −

  • 可以对实际开发问题给出快速且知识渊博的答案。

  • 确保开发的是所需的。

  • 功能优先级正确。

编码标准

开发人员按照强调的规则编写所有代码-

  • 通过代码进行通信。

  • 尽可能少的工作。

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

  • 整个团队自愿采用。

这些规则在极限编程中是必需的,因为所有开发人员都可以−

  • 可以从系统的一个部分切换到系统的另一个部分。

  • 每天交换几次合作伙伴。

  • 不断重构彼此的代码。

如果不遵守规则,开发人员往往会有不同的编码实践,代码会随着时间的推移变得不一致,并且无法说出团队中谁编写了哪些代码。

编码标准 - 优势

编码标准的优势是−

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

  • 减少内部注释的需要。

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