《敏捷软件开发 ——原则、模式、与实践》学习笔记(1)

    这是一本名副其实的经典著作！既有清晰的理论介绍、又有详细的实践分析，两者互彰，加之Martin的丰富的开发阅历，我为自己的选择感到兴奋。

      无奈自己的见识太少，在“肯定——否定——否定之否定”的螺旋式上升的过程中免不了多走几个来回。要理解这样的著作，不但要反复地拜读，还应该不断地实践、思考。

      其实阅读这本书最初的动机是学习设计模式和UML的基本知识，所以，在第一遍阅读时，注意力主要集中在书中的第二部分、第三部分和附录A。

 

第一部分 敏捷开发

 

原则、模式和实践都是重要的，但是使它们发挥作用的是人！

 

敏捷软件开发宣言：

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

 

原则：

1.     我们最优要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

2.     即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3.     经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付时间越短越好。

4.     整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

5.     围绕被激励起来的个人来构建项目，给他们提供所需要的环境和支持，并且信任他们能够完成工作。

6.     在团队内部，最有有效果并且富有效率的传递信息的方式，就是面对面的交谈。

7.     工作的软件会是首要的进度度量标准。

8.     敏捷过程提倡可持续的开发速度。责任人、开发者和用户能够保持一个长期的、恒定的开发速度。

9.     不断地关注优秀的技能和好的设计会增强敏捷能力。

10. 简单——使未完成的工作最大化的艺术——是根本。

11. 最好的构架、需求和设计出自于自组织的团队。

12. 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

 

理解：这些原则都是在围绕敏捷开发的概念，阐明如何利用最小的代价，满足客户的需求，应对客户的变化。

极限编程概述：

1. 客户作为团队成员
2. 用户素材（计划工具）
3. 短期交付（迭代计划、发布计划）
4. 验收测试（Acceptance Tests）
5. 结对编程
6. 测试驱动的开发方法（测试用例和代码共同演化）
7. 集体所有权
8. 持续继承（不稳定的状态不应该保持太长时间）
9. 可持续的开发速度
10. 开放的工作空间
11. 计划游戏
12. 简单设计（使之对正在实现的用户素材而言始终保持在最有状态）
13. 重构
14. 隐喻

 

计划：

1. 发布计划
2. 迭代计划
3. 任务计划

 

测试驱动的开发方法：（优点）

1. 程序中的每一项功能都有测试来验证它们的操作的正确性。
2. 首先编写测试可以迫使我们使用不同的观察点（直接关注接口，程序的调用方式）。
3. 迫使我们把程序设计成可测试的（可以帮助解耦）。
4. 测试可以作为一种无价的文档形式。

 

重构：

软件模块的三项职责：

1. 可以运行，完成所需功能。
2. 可以应对变化（便于修改）。
3. 可以和阅读它的人进行沟通。