ThoughtWorks 文集 II：敏捷实践的秘密
核心观点
这是一本 ThoughtWorks 2010 年出版的敏捷实践文集，收录了 10 篇来自 InfoQ 的专栏文章，涵盖测试、数据迁移、富客户端开发、持续集成、版本管理等多个主题。
关键章节
1. 我和敏捷团队的五个约定（覃其慧）
测试人员与团队协作的五大约定：
- 约定1：业务分析师参加客户需求会议，早期介入预防缺陷
- 约定2：开发人员听取测试人员对自动化测试的意见
- 约定3：项目经理不要要求测试所有路径，按价值优先级测试
- 约定4：迭代经理有交付风险疑问时询问测试人员
- 约定5：测试人员也要用敏捷实践（结对、INVEST原则）
核心观点：预防胜于治疗，测试人员应尽早介入需求阶段。
2. 如何在敏捷开发中做好数据迁移（章昱恒）
数据迁移在敏捷开发中的实践方法：
- DBA 需要制定目标并管理自己的任务（故事墙）
- 思考实施策略：数据质量、对原有系统的了解、业务数据映射
- 测试驱动数据迁移：期望数据测试 + 异常数据测试
- 持续集成：开发沙盒、系统级测试沙盒、生产环境测试沙盒
- 工具选择：尽量使用 SQL 脚本，避免引入过多第三方工具
- 保留中间结果用于脚本调试
核心观点：数据迁移看似简单但挑战巨大，需要 DBA 具备良好的沟通能力。
3. RichClient/RIA 原则与实践（陈金洲）
富客户端开发原则：
- 一切皆异步：所有耗时操作应异步进行，避免阻塞 UI 线程
- 视图管理：视图生命周期管理、导航管理
- 事件管理：统一管理事件，避免事件风暴
- 线程管理：合理的线程模型
- 缓存与本地存储：提高性能
核心观点：富客户端开发借鉴 Web 开发经验，但需要考虑本地环境的特殊性。
4. 为什么我们要放弃 Subversion（胡凯）
分布式版本控制相比 SVN 的优势：
- 离线工作能力强
- 分支操作更轻量
- 更适合分布式团队协作
- Git 已成为事实标准
5. “持续集成”也需要重构（乔梁）
持续集成系统的演进：
- 从简单的构建触发到复杂的集成流水线
- CI 系统本身也需要持续重构
- 关注点：稳定性、速度、反馈质量
6. Mock 不是测试的银弹（胡凯）
Mock 框架的局限性和风险：
- Mock 对象的行为依赖风险：模拟对象与真实对象行为不一致
- 非法测试：看起来像测试，几乎没有价值，几乎不会失败
- 正确做法：
- 设计合理的等待策略
- 正确创建和销毁资源
- 设计合理的过滤策略
- 充分利用计算资源
核心观点：Mock 更多是设计工具而非测试工具，测试实践的关键是改进流程而非依赖框架。
7. 环境无关的环境（李光磊）
创建可复制开发环境的实践：
- 使用相对路径代替绝对路径
- 使用配置管理系统管理环境配置
- 环境变量作为缺省值
- 缺省值 + 用户自定义属性机制
核心观点：环境是软件的一部分，应该纳入配置管理。
8. Tech Lead 的三重人格（熊节）
Tech Lead 的三大职责：
- 技术决策者：架构设计、攻克技术难题、确定设计方案
- 流程监督人：开发环境、持续集成、测试
- 干扰过滤器：与客户技术团队沟通、与 BA/QA 协作、打杂
核心观点：Tech Lead 是超级忙的角色，需要通过团队成长逐步分担责任。
9. 自动化测试的分层结构（李贝）
测试自动化代码分层：
- 测试用例层：表达测试逻辑，使用业务领域语言
- 领域层：封装 HTTP 请求、浏览器控制、结果解析
- 待测系统层：实际被测系统
解决的问题：
- 测试逻辑难以理解和修改
- 测试脆弱性
- 维护开销大
核心观点：分层结构可以提高测试代码的可读性和可维护性。
10. TDD 实践之实用主义（李光磊）
TDD 实践中的灵活变通：
- 为沟通选择语言：中文函数名在特定场景下更有效
- 用大量测试来驱动：提前写出所有测试用例名称（空实现），提醒未完成的验收条件
- 一个环境，多个断言：共享环境设置，提高测试效率
核心观点：原则背后的思想比形式更重要，应根据实际情况灵活调整。
可行动点
- 测试人员应早期介入需求会议，预防缺陷
- 数据迁移需要测试驱动和持续集成
- 富客户端开发遵循异步原则
- 考虑从 SVN 迁移到 Git
- Mock 测试有风险，需要功能测试补充
- 环境配置纳入版本控制
- Tech Lead 需要关注技术、流程、干扰三个层面
- 自动化测试采用分层结构
- TDD 实践要灵活，注重实效
与其他知识的关联
- 高效程序员的45个习惯-敏捷开发修炼之道 - 测试驱动开发
- 敏捷软件开发：原理、模式与实践 - 敏捷实践
- SICP-计算机程序的构造和解释 - 编程思维