我们正通过亲身实践以及帮助他人实践，提示更好的软件开发方法。
通过这项工作，我们认为：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
(虽然右项也具有价值，但左项具有更大的价值)
敏捷宣言遵循的12个原则
1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2.即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势。
3.经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交流。
7.工作的软件是首要的进度度量标准。
8.敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9.不断地关注优秀的技能和好的设计会增强敏捷能力。
10.简单--使未完成的工作最大化的艺术---是根本的。
11.最好的构架、需求和设计出自于自组织的团队。
12.每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
面向对象设计的原则
SRP:单一职责原则
就一个类而言，应该仅有一个引起它变化的原因
OCP:开放－封闭原则
软件实体（类，模块，函数等）应该是可以扩展的，但不可修改
LSP: Listov替换原则
子类型必须能够替换他们的基类型
DIP:依赖倒置原则
抽象不应该依赖于细节，细节应该依赖于抽象
ISP: 接口隔离原则
不应该强迫客户依赖他们不用的方法，接口属于客户，不属于他所在的类层次结构。
REP:重用发布等价原则
重用的粒度就是发布的粒度
CCP:共同封闭原则
包中所有类对于同一类性质的变化应该是共同封闭的，一个变化若对一个包产生影响，则将对该包中有类产生影响，而对于其他的包不造成任何影响
CRP:共同重用原则
一个包中所有类应该是共同重用的，如果重用了包中的一个类，那么就要重要包中所有类
ADP: 无环依赖原则
在包的依赖关系图中不允许存在环
SDP: 稳定依赖原则
朝着稳定的方向进行依赖
SAP:稳定抽象原则
包的抽象程度应该和其稳定程度一致
极限编程实践
1. 完整团队:
XP项目的所有参与者（开发人员、业务分析师、测试人员等等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
2. 计划游戏:
计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。
3. 客户测试:
作为选择每个所期望的特性的一部分，客户定义出自动验收测试来表明该特性可以工作。
4. 简单设计:
团队保持设计恰好和当前的系统功能项匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。
5. 结对编程:
所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
6. 测试驱动开发:
程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。
7. 改进设计:
随时改进糟糕的代码。保持代码尽可能的干净、具有表达力。
8. 持续集成:
团队总是是系统完整的被集成。
9. 集体代码所有权:
任何结对的程序员都可以在任何时候改进任何代码。
10.编码标准:
系统中所有的代码看起来就好像是被单独一个——非常胜任的——人编写的。
11.隐喻：
团队提出一个程序工作原理的公共景象。
团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作。他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。
单元测试的理解
1.优秀的单元测试，无需测试类中所有行为组合，也无需测试某些极其简单的方法（如Get和Set）
2.一个好的单元测试，无论系统如何混乱，它仅仅确认它所测试的类是否与预期的一致。
3.好的单元测试也应该检查子系统的行为。整合测试则负责单元测试与验收测试之间的灰色地带。
4.如果不经常运行测试，测试将失去价值。
极限编程的12个实践原则
1.计划的制定
2.小版本
3.简单设计
4.测试
5.持续整合
6.重构
7.配对编程
8.代码共享
9.每周只工作40小时
10.现场客户
11.隐喻
12.编码标准