AgilePPP 第一部分：敏捷开发

第1章： 敏捷实践

缺乏有效的实践会导致不可预测性、重复的错误以及努力的白白浪费。 一个大而笨重的过程会产生它本来企图去解决的问题。

敏捷开发宣言：

• 个体和交互胜过过程和工具。

• 可以工作的软件胜过面面俱到的文档。

• 客户合作胜过合同谈判。

• 响应变化胜过遵循计划。

第2章： 极限编程概述

敏捷方法很多，极限编程（cXtreme Programing，简称 XP）是最著名的一个，他是由许多相互依赖的实践组成。

• XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团体。

• 对于做计划而言，了解需求只需要做到能够估算它的程度就足够了。

• 可以以客户指定的验收测试（Acceptance Tests）的形式来捕获有关用户素材的细节。

• 编写所有产品代码的目的都是为了使失败的单元测试能够通过。

• XP的规则是不允许团队加班工作。

• 计划游戏（planning game）的本质是划分业务人员和开发人员之间的职责。

• XP团队通过经常性的代码重构来扭转这种代码退化。

第3章： 计划

当你能够度量你所说的，并且能够用数字去表达它时，就表示你了解了它；如果你不能度量它，不能用数字去表达它，那么说明你的知识就是匮乏的，不能令人满意的。

• 任何过大的素材都应该被分解成小一点的部分，任何过小素材都应该和其它小的素材合并。

• 如果知道了开发速度，客户就能够对每个素材的成本有所了解。

• 迭代期间用户素材的实现顺序属于技术决策范畴。

• 一旦迭代开始，客户就不能改变该迭代期内需要实现的素材。

第4章： 测试

编写单元测试是一种验证行为，更是一种设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。

• 首先编写测试可以：

  • 程序中的每一项功能都有测试来验证它的操作的正确性。
  • 迫使我们使用不同的观察点。
  • 迫使自己把程序设计为可测试的，从而迫使我们解除软件中的耦合。（forces us to decouple the software）
  • 作为一种无价的文档形式。

• 可以采用programming by intent（按照意图编程）的方式。

• 单元测试是用来验证系统中个别机制的白盒测试。

• 验收测试是用来验证系统满足客户要求的黑盒测试。

• 测试运行得越多，就会越快地发现和那些测试相背离的变动。

第5章：重构

在不改变代码外在行为的前提下对代码做出修改，以改进代码的内部结构的过程称为重构。

• 每一个软件模块都有三个职责：

  • 一是它运行起来所完成的功能。
  • 二是它要应对变化。
  • 三是要和阅读它的人进行沟通。

• 你也许担心提取出仅仅调用一次的函数会对性能造成负面的影响。我认为在大多数情况下，提取出函数所增加的可读性是值得花费额外的一些微小开销的。