敏捷开发

敏捷开发的布道者Scott Ambler在回答有关敏捷的争论时，提到四个检验团队是否敏捷的标准。如果你违背了四个标准的任意一条，你的团队都可能不是敏捷的。

重构是敏捷开发人员工具箱中的一项核心实践。按照重构的定义——修改内部结构(设计)而不影响外部行为——来讲，它并不能为客户创造可衡量的价值。在精益世界中，任何不能为客户创造价值的做法都是浪费，客户所能够感知到的只是行为/功能，而非结构。

异地分布式软件开发（Distributed Software Development）是指由多个位于不同地理位置的团队进行同一个软件项目的开发过程。这个词越来越频繁的出现在各种技术媒体中。

一件用户通过系统完成其一个有价值的目标（买一罐饮料）的事。这样的过程就叫“用户案例(user case)”或者“用户例事(user story)”。也就是说，上面客户所说的话就是在描述一个用户例事（user story）。为什么用例事这个词，是指在一个系统前，每个用户要完成同样的目标，都做这个系统设定的例行的事。

这是一个会议管理系统。该系统记录每个参会者的ID、姓名、电话和所属地区。参会者ID是会议组织者分配的唯一的数字标识。参会者的姓名是必须要提供的。电话则不是必填的。所有的参会者只能来自三个地域：中国、美国或者欧洲。

本章讲述的是因为一些类的依赖造成的无法重用的问题。这是一个处理zip的程序。用户可以在主窗口中输入要生成的目标zip的路径，比如c:\f.zip，然后输入想压缩到这个zip的源文件的路径，比如c:\f1.doc和c:\f2.doc 。

当我们想让一个类继承自另一个类时，我们一定要再三检查：子类会不会继承了一些它不需要的功能（属性或方法）？如果是的，我们就得再想想：它们之间有没有真正的继承关系？如果没有，就用代理；如果有，将这些不用的功能从基类转移到另外一个合适的地方去。

异味这个词可能有点抽象，所以我们先看下面的例子。这是一个CAD系统。现在，它可以画三种形状：线条、长方形和圆。

这是一个会议管理系统，它用来管理所有参会者的信息。刚开始的时候，我们只需要记录每个参会者的ID（这是会议组织者分配的）、姓名、电话和地址就行。

这是一个会议管理系统。在会议中，每个参会者都会戴一个牌子，牌子上面有该参会者的信息（比如姓名等）。在该系统中，Badge类用来存放参会者的信息。请看下面的代码跟注释。

每日会议只有项目开发人员参加，一般情况下只会持续10分钟。当然，根据项目人数不同，时间也会有多有少。而且为了让这个会议尽量简洁，所有与会者采用站立的方式开会，所以每日会议有一个别名：站立会议。

做完今天计划的事情，还剩下一些空余的时间，这可不能浪费。已经是培训最后一天，还有一些简单但关键的东西需要掌握呢！首先我要跟大家讲的是配置管理，从某种意义上来说等同于版本控制（但不能划等号）。

2月15日晚，项目正式开张。为了阐明测试驱动开发与传统软件开发方法的不同和优点，我给大家提了一个有趣的问题：

2月16日上午，第一天的培训开始。今天的重点是测试驱动开发的体验。为了方便实施自动单元测试，一个成熟易用的测试框架当然必不可少。我们项目采用C++开发，CppUnit当然成了最佳选择。

重新检查大家的代码，我有种想重写的冲动，不过这正合我意，因为今天的工作就是清扫战场，做清扫的人当然是大家。

今天实在是很漫长，到重构练习完成，我们还有时间做下一个活动的演练：计划游戏。作为一个最不专业的解释，计划游戏就是在现场客户、开发人员、相关负责人员的参与之下，分解、分配和估计任务的活动。

软件开发实在不应该是一个令人厌恶的工作，而更应该像一种艺术家的创作，充满新意和乐趣。可是，我看过不少软件开发者却一直在写令自己都厌恶的代码，做连自己都不敢正视的测试，最后在项目完成时长叹一口气，将自己的成果束之高阁、不敢再碰。

2月21日，项目正式开始第二天。依照昨天设计的框架和接口，我们开始实现这些功能。不过似乎大家的进展都比较慢，特别是XophiiX，似乎陷入了困境之中。

迭代开发就蕴含在测试先行、每日会议、重构和计划游戏之中。计划游戏确定最近的一次迭代目标，每日会议确定每天的工作重点，测试先行和重构就是一个一个迭代周期当中更加细微的迭代。迭代开发更多的是一种思想，而不是一种可以让每个人“掌握”的东西。

2月22日，转眼就开发的第三天。项目刚开始的时候会遇到很多问题，特别是架构的设计会出现很多变故。昨天刚经历了“过度设计”事件，使我更加认识到真实项目的艰险——这仅仅是一个实验项目，难度也不高，但前两天过的就那么有声有色，还是有点出乎意料。可以想像，今天也绝对不会平淡。