这是一本名副其实的经典著作!既有清晰的理论介绍、又有详细的实践分析,两者互彰,加之Martin的丰富的开发阅历,我为自己的选择感到兴奋。
无奈自己的见识太少,在“肯定——否定——否定之否定”的螺旋式上升的过程中免不了多走几个来回。要理解这样的著作,不但要反复地拜读,还应该不断地实践、思考。
其实阅读这本书最初的动机是学习设计模式和UML的基本知识,所以,在第一遍阅读时,注意力主要集中在书中的第二部分、第三部分和附录A。
第一部分 敏捷开发
原则、模式和实践都是重要的,但是使它们发挥作用的是人!
敏捷软件开发宣言:
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
- 响应变化 胜过 遵循计划
原则:
1. 我们最优要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2. 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3. 经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付时间越短越好。
4. 整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
5. 围绕被激励起来的个人来构建项目,给他们提供所需要的环境和支持,并且信任他们能够完成工作。
6. 在团队内部,最有有效果并且富有效率的传递信息的方式,就是面对面的交谈。
7. 工作的软件会是首要的进度度量标准。
8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户能够保持一个长期的、恒定的开发速度。
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单——使未完成的工作最大化的艺术——是根本。
11. 最好的构架、需求和设计出自于自组织的团队。
12. 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
理解:这些原则都是在围绕敏捷开发的概念,阐明如何利用最小的代价,满足客户的需求,应对客户的变化。
极限编程概述:
- 客户作为团队成员
- 用户素材(计划工具)
- 短期交付(迭代计划、发布计划)
- 验收测试(Acceptance Tests)
- 结对编程
- 测试驱动的开发方法(测试用例和代码共同演化)
- 集体所有权
- 持续继承(不稳定的状态不应该保持太长时间)
- 可持续的开发速度
- 开放的工作空间
- 计划游戏
- 简单设计(使之对正在实现的用户素材而言始终保持在最有状态)
- 重构
- 隐喻
计划:
- 发布计划
- 迭代计划
- 任务计划
测试驱动的开发方法:(优点)
- 程序中的每一项功能都有测试来验证它们的操作的正确性。
- 首先编写测试可以迫使我们使用不同的观察点(直接关注接口,程序的调用方式)。
- 迫使我们把程序设计成可测试的(可以帮助解耦)。
- 测试可以作为一种无价的文档形式。
重构:
软件模块的三项职责:
- 可以运行,完成所需功能。
- 可以应对变化(便于修改)。
- 可以和阅读它的人进行沟通。