《敏捷软件开发》读书笔记（一）

1、敏捷开发是一种面临迅速变化的需求快速开发软件的能力。 为了获取这中敏捷性，我们需要：

（一）使用一些可以提供必要的纪律和反馈的实践。

（二）需要使用一些可以保持我们的软件灵活、可维护的设计原则。

（三）我们需要知道一些已经被证明针对特定问题可以平衡这些原则的设计模式。

2、原则（Principle）、模式（Pattern）和实践（Practice）都是重要的，但是使它们发挥作用的是人。

3、人不是“插入即兼容的编程装置”（——Kent Beck）。如果想要项目取得成功，就必须构建起具有合作精神的、自组织的团队。

4、个体和交互胜过过程和工具。

     合作、沟通以及交互能力要比单纯的编程能力更为重要。

5、可以工作的软件胜过面面俱到的文档。没有文档的软件是一场灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。编写并维护一份短小的（20页左右）文档将总是一个好主意。

6、客户合作胜过合同谈判。你不能够仅仅写下一份关于想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。

7、响应变化胜过遵循计划。计划不能考虑得过远。为下两周做详细的计划，为下三个月做粗略的计划，在以后就做极为粗糙的计划。

8、必须要对软件项目进行持续不断的引导。

9、敏捷团队默认的沟通方式是交谈。敏捷团队不需要书面的规范、书面的计划和书面的设计。

10、所有的敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。他们不会制造混乱然后告诉自己等有更多的时间时再来清理它们。如果他们在今天制造了混乱，他们会在今天把混乱清理干净。

11、简单——他们在今天以最高的质量完成最简单的工作。深信如果明天发生了问题，也会很容易进行处理。

12、反身。

13、敏捷软件开发的原则和价值观构成了一个可以帮助团队打破过程膨胀循环的方法。

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

15、XP中的用户素材（也称用户故事， user stories）。开发人员将用户素材分解成开发任务（task）。

16、用户素材的验收测试是在就要实现该用户素材之前或实现该用户素材的同时进行编写的。并且验收测试使用能够让它们自动并且反复运行的某种脚本语言来编写。

17、重构。代码往往会腐化。随着我们添加一个一个的特性（功能），处理一个又一个的错误，代码的结构会逐步退化。如果对此置之不理的话，这种退化最终会导致纠结不清，难于维护的混乱代码。

18、重构是持续进行的，而不是在项目结束时、发布版本时、迭代结束时、甚至每天快下班时才进行的。重构是我们每隔一个小时或者半小时就要去做的事情。

19、隐喻（metaphore）通常可以归结为一个名字系统。这些名字提供了一个系统组成元素的词汇表，并且有助于定义他们之间的关系。

20、XP中的任务计划。开发人员把用户素材（user story）分解为开发任务（task），一个任务就是一个开发人员能够在4-16小时内能完成的功能。开发人员在客户（业务人员）的帮助下对这些用户素材进行分析，并尽可能完全地列举出所有的任务。

21、一个迭代周期结束时必须有一个演示会。在演示会上，客户会对当前可运行的程序的外观、感觉和性能进行评价。客户会以新的用户素材的方式提供反馈。

22、当然、使用敏捷方法并不意味着涉众就可以得到他们想要的。它只不过意味着他们将能够控制着团队以最小的代价获得最大的商业价值。

23、编写单元测试是一种验证行为，更是一种设计行为。同样，它更是一种编写文档的行为。

24、为了编写单元测试，我们必须把程序设计为可测试的。迫使我们让程序和它的周边环境解耦。

25、PPP一书的大部分内容都是依赖性管理方面的设计原则。

26、验收测试是用来验证系统满足客户需求的黑盒测试。验收测试使用实际的真实数据和外部文件。验收测试也是程序，因此也是可以自动化运行的，通常通过脚本实现。

27、编写验收测试的行为对于系统的架构方面具有深远的影响。为了系统可测试，就必须要在很高的系统架构层面对系统进行解耦合。例如，为了使验收测试无需通过用户界面（UI）就能够获得对于业务规则的访问，就必须要以满足这个目的的方式来解除用户界面和业务规则之间的耦合。

28、在项目迭代的初期，会受到用手工的方式进行验收测试的诱惑。但是，这是非常不明智的。正如单元测试可以促使你在小的方面做出优良的设计决策一样，验收测试可以促使你在大的方面做出优良的系统架构决策。

29、我们绝不允许系统倒退！因此需要测试套件（包括单元测试和验收测试）来保证。

30、每一个软件模块都具有三个职责。

        第一个职责是它运行起来所完成的功能。这也是该模块得以存在的原因。

        第二个职责是它要应对变化。几乎所有的模块在它们的生命周期中都要变化。或早或晚。开发者有责任保证这种改变应该尽可能地简单。

        第三个职责是要和阅读它的人进行沟通。

        做到这些，除了需要掌握一些原则和模式外，还需要编程者的注意力，需要纪律约束，需要创造美的激情。

33、重构就好比用餐后对厨房的清理工作。若不清理，脏乱会一天天累积 ，最终我们得花费大量的时间和精力去寻找合适的烹饪器具，凿去盘碟上已经干硬的食物残余，还是得洗。

34、画一幅图来探究一个想法是没有错的。然而，画了一幅图后，不应该假定该图就是相关任务的最好设计。你会发现最好的设计在你首先编写测试，然后一小步一小步前进时逐渐形成的。