《敏捷软件开发》--读书笔记

《敏捷软件开发》--读书笔记

前言：
        讲解如何用极限编程来设计、测试、重构和结对编程 。


态度：
        看重个体和交互胜过过程和工具
        看重可以工作的软件胜过面面俱到的文档
        看重客户合作胜过合同谈判
        看重响应变化胜过遵循计划


敏捷宣言遵循的原则：
        我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
        即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
        经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
        在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
        围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
        在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
        工作的软件是首要的进度度量标准。
        敏捷过程提倡可持续的开发速度。负责人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
        不断地关注优秀的技能和好的设计会增强敏捷能力。
        简单--使未完成的工作最大化的艺术是根本的。
        最好的架构、需求和设计出自于自组织的团队。
        每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。



原序中的一段话：
        有一个XP实践对我来说是一个新发现。当你第一次听到测试优先设计时会觉得它似乎很平常。它指示要在编写任何产品代码
前先编写测试用例。编写的所有产品代码都是为了让失败的测试用例通过。对于以这种方式编写代码所带来的意义深远的后果，我
始料未及。这个实践完全改变了我编写软件的方法，并把它变得更好了。


测试驱动的开发方法：
        若我们能够在设计程序前先设计测试方案，情况会怎样？
        若我们能够做到：除非缺乏某个功能将导致测试失败，否则就拒绝在程序中实现该功能，情况会怎样？
        若我们能做到：除非由于缺少某行代码将导致测试失败，否则就拒绝在程序中增加哪怕一行代码，情况又会怎样？
        若首先编写失败的测试表明需要一项功能，然后再逐渐地增加那项功能使测试通过，情况又会怎样？
        这对于我们正在编写的软件的设计有什么影响呢？若存在这样一组包罗万象的测试，我们能够从中得到什么好处呢？


        第一个也是最明显的一个影响，是程序中的每一项功能都有测试来验证它的操作的正确性。这个测试套件可以给以后的开发
提供支援。无论何时我们因疏忽破坏了某些已有的功能，它就会告诉我们。我们可以向程序中增加功能，或者改变程序结构，而
不用担心在这个过程中会破坏重要的东西。测试告诉我们程序仍然具有正确的行为。这样，我们就可以更自由地对程序进行改进。

        还有一个更重要但是不那么明显的影响，是首先编写测试可以迫使我们使用不同的观察点。我们必须从程序调用者的有利视角
去观察我们将要编写的程序。这样，我们就会在关注程序的功能的同时，直接关注它的接口。通过首先编写测试，我们就可以设计
出便于调用的软件。

        此外，通过首先编写测试，我们就迫使自己把程序设计为可测试的。把程序设计为易于调用的和可测试的，是非常重要的。
为了成为易于调用的和可测试的，程序必须和它的周边环境解耦。这样，首先编写测试迫使我们解除软件中的耦合。

        首先编写测试的另一个重要效果，是测试可以作为一种无价的文档形式。若想知道如何调用一个函数或者创建一个对象，会有
一个测试展示给你。测试就像一套范例，它帮助其他程序员了解如何使用代码。这份文档（测试）是可编译、可运行的。它保持最
新，不会撒谎。














注：
        敏捷软件开发  原则、模式与实践（Agile Software Development  Principles,Patterns,and Practices）
        (美) Robert C.Martin著  邓辉 译  孟岩 审    清华大学出版社     2003