1.PPP指的是敏捷软件开发中原则（principle），模式（pattern）和实践（practice）。
敏捷宣言：
1.个体和交互优于过程和工具。
2.可以工作的软件优于面面俱到的文档。
3.客户合作优于约束合同。
4.拥抱变化优于遵循需求。
2.12条原则
1.客户满意
2.拥抱变化，即使是后期，增强客户竞争优势。
3.业务人员和开发人员坐在一起
4.规范开发进度标准
5.开发周期越短越好
6.面对面交谈沟通
7.即使反馈，复核。
8.信任个体完成任务。
9.关注新的技术
10.团队建设
11.恒定开发速度。
12.简单
3.XP编程
实践：客户和开发人员在一起
结对编程
用户素材
重构
测试驱动
隐喻：宏观上将关联的部分汇总，定义他们之间的关系
消除重复，有且只有一次
简单即可（不必一开始就考虑未来的事情）
开放的工作空间，讨论的效率比安静的环境的效率还高
可持续的开发速度
持续集成
集体所有权，不对单独特地的模块或技术负责
验收测试
第三章主要写了XP中计划游戏的流转。从user Story到真正feature上线期间的方法。基本上和现在所在的团队一致。
初始探索，拆分任务
发布计划
迭代计划（每个迭代周期里的任务数，代价）
任务计划（估算任务点数，领取任务，确定优先级）
迭代的中点：在迭代周期的中间时间段会来查看任务完成的情况，理想的情况是完成了一半，并且是可交付的功能，如果没有，需要及时调整资源，或者调整任务的发布。
迭代：UAT
第四章讲的是测试
单元测试和验收测试
单元测试主要是开发人员进行编写，用于检验一小部分功能的实现，
验收测试由QA或者客户编写。验收测试的要求是简单易懂，甚至可以帮忙设定开发框架。验收测试比较全面，覆盖广。
越是具有可测性，耦合性越弱。
第五章重构
软件模块有三个职责
正确运行所有功能
应对即将有的变化
让阅读者理解
作者把重构比作去餐厅吃饭，第一次你很快就吃完了，看到有点脏乱，不去清理，日积月累。一段时间你再去吃饭的时候，你会发现餐具不知道在哪，食物也是杂七杂八，需要花费更大的时间去清理。
重构某种意义上是为了更好的理解，适当的增加可读性比所带来的微小性能的开销，长久来看是值得的。
第六章讲的是结对编程
作者通过一个有趣的保龄球的积分规则，像人格分裂一样通过对话的方式描述了在结对编程中两个人扮演的角色和任务，humorous。看似复杂的积分规则可以通过简单的测试，一步一步构建出来，最终再将可执行的程序重构一下，使之更加表意。过程让我想起过年前一次结对，主导对静态类职责的扩展和重构，Alex给予了很大的帮助，自己也认识到OOP设计方面的缺失，需要加强。
第七章什么是敏捷设计
作者宏观上展示了软件开发过程中因需求变化，导致代码出现bad smell。需要开发人员实时关注软件腐化（僵化，脆弱，牢固，粘滞，不必要的复杂，不必要的重复，晦涩）。最后强调敏捷是一个持续的过程，不是事件。需要人员在开发过程中变动时应用敏捷设计原则。
第八章 单一职责原则（SRP），一个类中应只含有一个能够引起它变化的职责。但是也不是绝对的，有些杂糅在一起的职责类，只要调用者尽可能的少，还是可以接受的。比如在给硬件的编码过程中。
第九章 开放-封闭原则（OCP），对本身不修改，允许派生。尽可能对系统中频繁变化的部分做抽象。该原则主要机制就是抽象和多态。
第十章 里氏替换原则（LSP），子类可以替换基类，是OCP成为可能的重要原则之一。这条规则主要是用来检验。
第十一章 依赖倒置原则（DIP），高层模块不应该依赖于底层模块。抽象不依赖于细节，细节应该依赖于抽象。简单的button和lamp例子，button要去开灯，所以button依赖于lamp，但是DIP要求所有权倒置（细节和策略都依赖于抽象）。button依赖于interface，然后lamp实现该接口。相当于把主动权给了button。这样lamp相当于提供了一种可调用的服务，便于扩展。
（续）
