2019你好！好好生活，好好工作！
原则(Principles)、模式(Patterns)与实践(Practices)
本书开篇就强调了4点：
可以理解为这是敏捷软件开发最重要的参考依据。
一、敏捷软件开发宣言
二、敏捷宣言遵循的原则
三、面向对象设计的原则
四、极限编程实践
ps：极限编程（eXtreme Programing，简称XP）
并且在之后的章节针对这四点也有详细的介绍
第一章：敏捷实践
主要是相对详细的介绍了敏捷软件开发宣言以及宣言遵循的原则
敏捷软件开发宣言：
1、个体和交互胜过过程和工具
应该先致力于构建团队，然后再让团队给予需要来配置环境
2、可以工作的软件胜过面面俱到的文档
对于新加入团队的成员，最好的两份文档是代码和团队！直到迫切需要并且意义重大时，才编制文档。
3、客户合作胜过合同谈判
和客户的真诚协作是项目成功的关键，而合同是为了指导协作而不是为了规定项目的细节以及进度。
4、响应变化胜过遵循计划
好的计划策略是：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。
敏捷宣言遵循的原则，是敏捷是在区别于重型过程的特征所在。
在一般的项目团队中可能很难满足这12条原则，但是可以以此为依据，尽量向这个方向靠近！
第二章：极限编程概述
文章开头就列出了极限编程实践的依据列表，本章是详细阐述了这个列表的内容！
项目团队可以直接拿来使用，也可以增加一些实践或对其中的一些实践进行修改之后再采用。
个人的理解就是理解敏捷开发过程以及其具体实践，在项目团队中，可以小范围开启，根据团队实际优化实践。
第三章：计划
初始探索：
探索、分解和速度，个人理解就是：将大模块拆分成小模块，逐步拆解，直到是其大小适用于可以被准确估算，这个估算包括：所需要的素材、以及开发速度。
发布计划：
根据开发速度以及客户的功能优先级，开发人员和客户对首次发布实践达成一致。（因为开发速度开始时并不准确，所以实践时间也是粗略的）
迭代计划：
迭代规模由开发人员和客户决定，一般是两周。
任务计划—迭代的中点：
将开发任务具体到每个人，并且每个任务所需时间和素材都是可见且可以作为下次任务的预算依据
迭代的中点：迭代进行到一半的时候，查看本次迭代中所安排的开发任务是否完成了一半。如果没有完成，团队会设法重新分配没有完成的任务和职责，以保证迭代结束时能够完成所有任务。如果开发这不能实现这样的重新分配，则需要告知客户。客户决定去掉某些优先级较低的任务。
迭代：
通过迭代，客户可以看到项目的进展，他们也可以度量开发进度。且每次迭代结束，客户会以心得用户素擦的方式提供反馈。客户对项目的整体控制也更强。
计划、迭代可以使团队的每个人都知道将要做什么、何时做。对于开发任务和开发进度的把控也可以更准确。
第四章：测试
测试驱动的开发方法
验收测试
实际上这个章节对我的想法改观很多。
在之前的团队开发过程中，基本属于产品驱动开发，开发完成之后提交测试。多次迭代之后会出现多次功能或者页面的反馈测试
之后需要主动学习的是单元测试的工具和测试驱动开发的思想。
第五章：重构
本章是针对素数产生的程度具体重构的示例
重构的原则：易于阅读、易于修改、程序结构的个部分隔离。实际上重构的过程也是对设计模式的原则的体现。
重构的目的：每天清洁你的代码，保持代码清洁，这个很重要！