image.png

1. 结对编程 Pair Programming

XP认为在项目中采用成对编程比独自编程更加有效。结对编程是由两个开发人员在同一台电脑上共同编写解决同一问题的代码，通常一个人负责写编码，而另一个负责保证代码的正确性与可读性。成对编程是一种非正式的同级评审（Peer Review）。它要求结对编程的两个开发人员在性格和技能上应该相互匹配

  • 师徒模式，老带新、技能复制（有人会有人不会）
  • 攻坚（两个水平差不多的人，合理解决）
  • 彼此遍历；一个电脑一个键盘，不在乎时间和人员角色；并非double 工作量

image.png

好处：

  • 代码共有、保障质量
  • 有更好的设计
    • 2个人可以讨论，一个人做的时候，另一个人可以看看这样的设计是否可以改得更好。
  • 减少缺陷
    • 一个人编程的时候，另一个在旁边检查，可以减少错误。
  • 减少文档
    • 减少程序员与测试员之间的沟通文档
  • 增加效率
    • 程序员与测试员面对面的沟通，最有效能与效率，不用等程序都写好之后才开始进行测试。

  • 减少技术债务

    • 如果有任何不符合组织规定的编程标准，由于是一个人编程，一个人当场检0，并立即修订，就可减少技术债务

      缺点：

  • 成本高

2. 重构 Refactoring

  • 重构（Refactoring）就是在不改变软件（外部的）现有功能的基础上，通过调整程序（内部）代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。
  • 重构不是XP所特有的行为，在任何的开发过程中都可能并且应该发生。XP提倡毫不留情的重构（Refactor mercilessly)
  • 重构是在不改变软件外部行为的前提下改善其内在结构

本质上说·：重构就是在代码写好后改进它的设计
简单来说：就是一种整理代码的方法，以提高代码的质量，容易维护
注：不是所有整理代码都是重构，重构有一个前提：自动测试，一个目标：设计原则
另外还有两个原则：小步快跑和两顶帽子

优点·

  1. 保持程序简洁
  2. 增加效能。
  3. 改善可维护性。

    重构 Vs不重构

  • 代码质量主要有正确性，可读性，可维护性，可扩展性、稳定性等
  • 补充：代码质量最重要的是“可读性“，同见《HW编程规范》

image.png

非功能需求 Nonfunctional Requirements

  • Safety, security, privacy, compliance, usability, accessibility, performance
  • Availability, reliability, resilience, backup, disaster recovery
  • Portability, operability, interoperability
  • Extensibility, maintainability, scalability

image.png

3. 简单设计 Simple Design

  • 团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。
  • Kent Beck认为对于XP来说，简单设计应该满足以下几原则：
    • 成功执行所有的测试；
    • 不包含的代码；
    • 向所有的开发人员清晰地描述编码以及其内在关系；
    • 尽可能包含的类与方法。
    • 举例：SRP，LoD

image.png

优点：

  1. 减少了可以用在做真正需要的功能的时间。
  2. 导致额外的维修和支持的成本。

制造没有必要的弹性，这会增加未来工作的成本。

4. 测试驱动开发 Test Driven Development

XP推荐测试先行，即先编写测试代码，之后以通过所有测试为目标来驱动实现源码的开发，这通常也称为测试驱动开发。
image.png

  • 测试驱动开发，简称TDD，是一种开发人员在为新特性编写代码之前先编写测试的技术。修改代码以使测试通过，随后对代码进行重构以满足功能和非功能需求。重复这个步骤序列，直到所有特性的所有测试用例通过，并被标记为成功完成。
  1. 第一步是理解需求、特性或用户描述，并为其编写相应的测试。测试用例可能类似于Junit或Nunit，这取决于所使用的编程语言。
  2. 第二步是运行测试用例，这显然会失败，因为没有有效的代码要执行。这是红色的步骤
  3. 在接下来的步骤中，编写成功编译的代码，并可以被测试用例调用。在这个阶段，如果测试运行，它应该调用代码存根，但仍然失败，因为它缺乏功能。
  4. 在这个阶段，已经编写了足够的代码使测试用例通过。可以硬编码返回值、使用常量、模拟对象和任何其他方法来满足测试条件。这是绿色行动的开始。
  5. 在下一个阶段，开发人员继续添加代码来处理功能和非功能需求，确保链接测试继续通过。如果要添加更多的特性，则必须首先编写新的测试用例，并且这个过程会自我重复。
  6. 在重构或清理阶段，更新代码以解决任何代码质量问题、简化设计、消除技术债务、删除任何硬编码、重复、未使用的参数、方法、类、不必要的日志语句等。请注意，在进行这些技术更改时，代码的行为保持完整，测试应该继续通过。
  7. 在所有迭代过程中，对每个故事、特性和功能都要重复上述循环。

image.png

好处：

  • TDD确保只添加必要和足够的代码。这遵循了“不要重复你自己 Don’t repeat yourself”（DRY）和“你不需要它 You aren‘t gonna need it”（YAGNI）的原则
  • 如果严格遵循TDD，可以带来更好的代码覆盖率和代码质量。
  • 由于成功标准是预先定义的，开发人员只专注于让测试用例通过。这样可以保持代码简单，避免不必要的混乱。
  • 遵循TDD的团队自然会确保用户描述在创建时是可测试的（T在INVEST中）。
  • 用相同的编程语言编写单元测试用例，并存储在代码签入的相同版本控制库中，这样开发人员不仅熟悉它，而且拥有它。没有必要在其他地方维护单独的测试用例文档。
  • 通过重构，持续关注于包含和消除技术债务，从而使代码更容易维护、进行更改并被团队理解。
  • 测试套件可以反复运行（每天多次），以证明软件可以继续工作，而无需添加新的功能。
  • TDD的使用缩短了反馈周期，因为一旦代码编写、构建和执行，测试结果就会在几分钟内立即准备好。这支持频繁验证和验证的概念。
  • TDD的成功结果有助于“DoD”。虽然我们已经讨论了TDD的好处，但有几句话需要注意。首先，如果编写测试的同一开发人员同时编写通过测试的代码，那么这就基本上留给该开发人员的想象力和解释水平了。因此，如果理解不正确，通过的测试用例可能会产生一种错误的安全感，并可能产生深远的负面后果。其次，并不是所有用户界面后面的代码都能可靠有效地进行单元测试。团队必须用其他形式的测试（如探索性测试）来补充TDD，以达到最终目的。第三，在项目的生命周期中维护一个测试套件是必要的，并且应该是团队在计划和评估过程中必须考虑的一个关键因素。最后，介绍另一个密切相关的术语
  • 测试优先开发（TFD）。这基本上与TDD相同，只是少了重构步骤。