XP

背景

变更成本曲线：变更成本随时间呈指数增长

传统瀑布模型方法只能早期做好一切

  • 需求必须一次锁死
  • 设计必须覆盖未来
  • 测试留到最后

极限：把测试先行、持续集成、重构这些实践做到极致，让改变不再昂贵

XP的核心在开发阶段 程序员把一个工程任务实现并集成系统

一次工程任务的十步循环 从一张任务卡出发，十步走完即测试已集成

  • 找一个结对伙伴
    • 领最前面的任务卡
  • 讨论任务
    • 不确定就求助
  • 设计测试用例
    • 先想清楚对的样子
  • 编写测试并让它失败
    • 红灯——确认测试有效
  • 编写业务代码
    • 写到测试通过为止
  • 跑全部测试
    • 绿灯——没打破已有能力
  • 迭代测试与代码
    • 加下一个用例
  • 按需重构
    • 结构变丑就重构，测试就是安全网
  • 立即集成
    • 进主干并跑集成测试
  • 领下一张卡
    • 循环再来

四条纪律

  • 结对编程
  • 测试驱动 TDD
  • 结对不只是让测试通过 加值
    • 结对为分析、设计、实现、测试同时加值
  • 即时集成

平坦曲线的五根支柱

  • 面向对象
    • 修改局部化，动一处不牵全局
  • 简单设计
    • 不写未来可能用但现在没用的元素
  • 自动化测试
    • 安全网：改完立刻知道是否打破行为
  • 重构技术
    • 让代码持续保持可维护
  • CI/CD
    • 频繁部署和集成

XP 通过把反馈周期从月级压缩到分钟级，阻止错误和错误假设长期累积，因此压平了变更成本曲线

十二项实践

四大价值观

  • 交流
  • 简单
  • 反馈
  • 勇气

尊重是底座

四项基本活动

  • 编码
  • 测试
  • 倾听
  • 设计

倾听决定编码什么；编码产生结果；测试验证结果；设计让循环持续跑下去

好设计的四条判据

  • 局部隔离
  • 唯一实现位
  • 逻辑近数据
  • 扩展单点

十二项实践

  • 计划游戏
    • 业务决策要建在技术评估之上，技术评估要服务业务价值，两者双向依赖
  • 小发布
    • 每次发布尽可能小但是作为整体有意义
  • 隐喻
    • 用一个简单、生动、团队共享的比喻来描述系统整体结构，让大家更容易沟通、设计和扩展系统
  • 简单设计
    • 四条判据
      • 运行所有测试
      • 没有重复的逻辑
      • 表面每一个对程序员重要的意图
      • 尽可能少的类和方法
  • 测试TDD
    • 程序员单元测试 客户功能测试
  • 重构
    • 触发：新功能进不去或很难进去
    • 识别信号：系统在要求你重构
    • 小步改
    • 改完再加新功能
  • 结对编程
    • 动态结对
  • 集体拥有代码
    • 谁发现能为代码增加价值，就随时去做
  • 持续集成
    • 责任明确可追溯
  • 40小时工作制
    • 不靠加班维持进度
  • 现场客户
    • 真实客户必须与团队同坐办公，随时解答问题、解决争议
  • 编码标准
    • 统一标准

截屏2026-05-16 15.13.17

TDD与演进式设计

传统计划设计的问题是设计离代码太远；纯 Code-fix 的问题是代码没有设计约束。XP 要找的是中间路线：让设计贴着代码持续演进

敏捷测试的四条纪律

  • 独立
  • 自动
  • 即时
  • 永存

五种测试类型

  • 单元测试
  • 功能测试
  • 并行测试
  • 压力测试
  • 随机测试

红绿重构

  • 红 写失败测试
  • 绿 最小代码过测 写刚好能让测试通过的最少代码（允许硬编码，目标仅让红变绿）
  • 三角测试 再补一条测试
  • 重构 在测试保护下

截屏2026-05-16 16.11.33

简单设计的四重准则

  • 通过所有测试
  • 消除重复
  • 清晰表达意图
  • 最小化元素数量

YAGNI You Aren‘t Gonna Need It 不要因为“以后可能需要”就提前开发功能。超前功能多数不会被使用，却会持续增加维护成本

重构的纪律：不改行为，只改结构

生长式架构 疼痛出现前不引入核心元素

  • 起步 什么都不上
  • 海量数据到来 引入数据库
  • 业务复杂度到来 引入领域模型
  • 存疑时 依YAGNI

UML 应该作为低成本的沟通草图，而不是高成本的最终设计文档。真正可靠的信息源是代码和测试，而不是长期维护的图

可逆性 把复杂性挤出系统

  • 如果决策可更改，就不必一次做对
  • 推迟决策到信息最充分的时刻
  • 让决策可逆转
  • 版本控制是代码级的可逆保险

设计

  • 保持代码清晰简洁
  • 通过重构改进代码
  • 精通设计模式 懂应用时机和演进路径
  • 预见变化
  • 以代码、图标、对话传达设计

持续集成

传统集成

  • bug难定位
  • 上下文切换
  • 回避重构

恶性循环 怕集成->回避重构->结构腐坏->集成更痛

开发者四步脚本（有三步是跑构建）

  • 从主线拉最新代码
  • 本地改+跑完整自动化构建
  • 推送前再pull一次，再构建一次
  • git push到主线

十条核心实践

  • 显性（开发者日常要做）

    • 维护单一主线代码库

    • 自动化构建

    • 让构建自测试

    • 每人每天向主线提交
    • 每次主线提交都触发构建
    • 保持构建快速

  • 隐含（平台层保障）

    • 在类生产环境里跑测试
    • 任何人都能方便取到最新可执行文件
    • 自动化部署

自测试构建

  • 构建=编译+完整自动化测试

构建流水线要按“快反馈在前、重验证在后”的原则组织：先用编译、单元测试、静态检查快速拦截低级错误，再用集成测试、端到端测试、性能和安全测试逐层兜底

  • 提交阶段
    • 编译 单元测试 静态检查
  • 集成测试
    • 跨模块 真实数据库 外部服务
  • 端到端测试
    • UI API 真实业务场景
  • 性能测试
    • 安全扫描

构建坏了怎么办

  • 首选：Revert那次提交
  • 在revert后的主线上重修
  • 特殊情况才主线快修

未完成的功能

  • 代码里加配置开关
    • 未完成功能默认关
    • 按环境或用户分组开放
    • 上线后可灰度、可紧急关闭
  • 大规模重构时的“不开分支的分支”
    • 引入抽象层，新旧实现并存
    • 通过配置切换，逐步迁移
    • 完成后删旧实现和抽象层
  • 新功能部署到生产但对用户不可见
    • 只做内部监控和压测
    • 观察性能和稳定性
    • 信心足够后再开放

CI CD 持续部署

  • 持续集成（CI）

    • 自动化内容：构建 + 快速测试（编译、单元测试、静态检查）

    • 人工环节：后续测试、部署、发布

    • 目标：保证主线始终是可构建和初步验证过的状态

    • 典型做法：每次提交触发构建和单元测试

  • 持续交付（CD, Continuous Delivery）

    • 自动化内容：完整流水线到类似生产环境

    • 人工环节：上线生产只保留一个按钮触发

    • 目标：主线随时可以发布，用户随时获得最新版本

    • 特点：自动化流程更长，需要更高信心的测试

  • 持续部署（Continuous Deployment）

  • 自动化内容：流水线所有阶段直接上生产

  • 人工环节：只保留紧急刹车/发布控制

  • 目标：每次通过流水线的变更都能自动发布到生产

  • 特点：最极致自动化，依赖强大的测试和监控保障

feature branch 上跑自动化测试，只是“分支验证”；真正的 CI 要求开发者频繁把小变更集成回主线，让主线始终保持可工作状态

PR 前置评审能保证质量，但如果所有变更都被慢速评审卡住，就会让代码长期停留在分支上，从而破坏 CI 的核心：快速、频繁地集成到主线

XP 的沉寂与胜利

XP 后来作为“品牌”逐渐沉寂，但其核心工程实践并没有消失，而是以 DevOps、CI/CD、TDD、重构、持续交付等形式进入主流软件工程。

XP 品牌沉寂的原因：

  • 发源项目 C3 后来被取消，给批评者留下口实
  • 12 项实践整体性很强，难以部分采用
  • 结对编程存在文化阻力
  • Scrum 更容易被培训和认证市场包装
  • TDD、重构、CI 等实践门槛较高，短期不容易见效

Scrum 和 XP 的区别：

  • Scrum 更偏项目管理和团队协作
  • XP 更偏工程实践和代码质量
  • Scrum 不强制规定 TDD、CI、重构
  • XP 直接规定具体工程纪律
  • 只做 Scrum 仪式而没有工程实践，容易变成 Dark Scrum

XP 的实践扩散：

  • TDD 进入测试驱动和规格驱动开发
  • 重构成为现代代码维护的基本能力
  • CI/CD 成为 DevOps 工具链核心
  • 简单设计、YAGNI、持续反馈成为现代敏捷开发共识

CI 的进一步理解

真正的 CI 不是“有 Jenkins/GitHub Actions”，而是频繁把代码集成回主线。

feature branch 上跑自动化测试，只能算分支验证，不一定算真正 CI。

原因：

  • 分支没有及时合回主线
  • 代码仍然和团队最新状态隔离
  • 长期分支会积累冲突
  • 自动测试通过不代表已经完成集成

判断是否是真正 CI：

  • 是否每天至少合回主线
  • 分支生命周期是否很短
  • 主线是否始终可构建、可运行
  • 构建失败后是否立即修复

前置 PR 评审和 CI 存在张力：

  • PR 评审需要时间
  • CI 需要快速反馈
  • 如果每个 PR 都被慢速评审卡住，代码会长期停留在分支上
  • 这会破坏 CI 的快速集成节奏

应对方式：

  • 小步提交，降低评审成本
  • 结对编程，让评审前移
  • 重要变更重评审，琐碎变更轻流程
  • 集成后继续评审和修正

AI 时代的 XP

AI 让代码生成变得便宜，但验证变得更重要。因此 XP 的核心实践在 AI 时代反而更有价值。

AI 时代的变化：

  • 代码生成不是瓶颈
  • 需求澄清、规格定义、测试验证成为瓶颈
  • 工程师的价值从“写代码”转向“判断什么是正确的”

XP 实践的新形态：

  • TDD → 规格驱动开发
  • CI → 持续验证
  • 结对编程 → 人机协作 / 人机结对
  • 重构 → AI 生成代码后的结构治理

TDD 在 AI 时代的重要性：

  • 测试相当于可执行规格
  • 先写测试可以约束 AI 生成代码
  • AI 生成的是“看起来合理”的代码，不等于正确代码
  • 测试可以把自然语言需求转化成可验证目标

核心结论：

XP 的品牌可能沉寂，但它训练的是现代软件工程最关键的能力：

  • 快速反馈
  • 持续验证
  • 小步集成
  • 简单设计
  • 在测试保护下安全演进