第一章：敏捷实践
敏捷开发要点节选：
- 结对编程
- 集体代码所有权：所有人可以在任何时候改进所有代码
- 隐喻：团队提出一个程序工作原理的公共景象
如果把程序员团队当做是组件（component），那么就无法对他们进行管理。人不是“插入即兼容的编程装置”。如果想要项目取得成功，就必须构建具有合作精神的，自组织的（self-organizing）的团队。
一个大而笨重的过程会产生它本来企图去解决的问题。它降低了团队的开发效率，使得进度延期，预算超支。它降低了团队的相应能力，使得团队经常创建错误的产品。
代码是唯一没有二义性的信息源。
计划会遭受形态（shape）上的改变，而不仅仅是日期上的改变。所以预先制定好的详细的计划图是不适用的。正确做法是：为下两周做详细计划，为下三个月做粗略的计划，再以后做极为粗糙的计划。
跑得过快会导致团队经理好景，出现短期行为一直与崩溃。敏捷团队会测量他们自己的速度。他们不允许自己过于疲惫。他们不会借用明天的经理赖在今天多完成一点工作。他们工作在一个可以使在整个项目开发期间保持最高质量标准的速度上。
敏捷团队会不断地对团队的组织方式，规则，规范，关系等进行调整。敏捷团队知道团队所处的环境在不断地变化，并且知道为了保持团队的敏捷性，就必须随环境一起变化。
第二章：极限（eXtreme Programming）编程概述
在离真正实现需求还很早时就去补货该需求的特定细节，很可能会导致做无用功以及对需求不成熟的关注。在XP中，我们和客户反复讨论，以获取对需求细节的理解，但是不去捕获那些细节。
测试驱动的开发方法：编写所有产品代码的目的都是为了使失败的单元测试能够通过。
简单的设计：XP 团队使他们的设计尽可能地简单，具有表现力（expressive）。这意味着 XP 团队的工作可能不会从基础结构开始，他们可能并不先去选择使用数据库或者中间件。团队最开始的工作是以尽可能最简单的方式实现第一批用户素材。
因为添加特性和处理错误导致代码结构逐渐退化，XP 团队通过经常性的代码重构来扭转这种退化。重构是持续进行的，是每个一个小时或者半个小时就要去做的事情。通过重构，我们可以持续低保持尽可能干净，简单并且具有表现力的代码。
第三章：计划
所有大的用户素材（user stories）都应该被分解为小的素材，过小的素材应该和其他过小素材合并。
“用户能够安全的进行存款，取款，转账活动。”可以被分解为：
- 用户可以登录
- 用户可以退出
- 用户可以向其账户存款
- 用户可以从其账户取款
- 用户可以从其账户向其他账户转账
团队的开发速度在实现数个素材后可以估算出来，确定素材和开发速度后就可以估算开发时间。
客户挑选在某个发布中他们想要实现的素材，并大致确定这些素材的实现顺序。
分配的任务应该是 4~16 小时内实现的一些功能，多个任务组成一个素材。
迭代进行到一半的时候，此时半数素材应该被完成，如果没有完成，团队会设法重新法分配任务和职责。如果不能重新分派，则由客户决定从迭代中去掉一个任务或素材，或指出哪些最低优先级别的任务和素材。
如果完成了 90% 任务，但却没有完成素材，这是没有意义的。
迭代结束后，应该给客户演示当前可运行的程序，让客户评价并以新的用户素材进行反馈。
第四章：测试
测试驱动开发使你的代码都是对测试友好的。
测试可以作为一种无价的文档形式，如果想知道如何调用一个函数或者创建一个对象，会有一个测试战士给你看。
在实现钱，现在测试中陈述你的意图，使你的意图尽可能地简单，已读，你相信这种简单和清除会给程序指出一个好的结构。
MockObject 用于配合目标类的功能测试，相对比真实实现类好更好控制一些。
单元测试是白盒测试，验收测试是黑盒测试。
在项目迭代的初期，会受到用手工的方式进行验收测试的诱惑。但是，这样做使得在迭代的初期就丧失了由自动化验收测试的需要带来的对系统进行解耦合的促进力。
测试套件运行起来越简单，就会越频繁地运行它们。运行的越多，就会越快地发现和那些测试的任何背离。
第五章：重构
每一个软件都具有三项职责：
- 运行起来所完成的功能
- 应对变化，开发者有责任保证这种改变应该尽可能简单
- 和阅读它的人沟通
代码应能够清晰的表述各个子流程的意义，最常用的方法是将其封装为一个函数。
版权所有，转载请注明出处：
https://sickworm.com/?p=1678
