小强快跑~~

薪水支付第一次迭代S1

Proxy 和 Stairway To Heaven 模式

Abstract Server、Adapter 和 Bridge 模式

Observer 模式

Composite 模式

包的设计原则

Null Object 模式

Singleton 和 Monostate 模式

Facade 和 Mediator 模式

Template Method 和 Strategy 模式

Command 和 Active Object 模式

接口隔离原则（The Interface Segregation Interface）

依赖倒置原则（The Dependency Inversion Principle）

Liskov替换原则（The Liskov Substitution Principle）

开放-封闭原则（The Open-Close Principle）软件实体（类、模块、函数等）应该是可以扩展的，但是不可以修改的。两个特征1、对于扩展是开放的（Open for extension）；2、对于更改是封闭的（Close for modification）。关键是抽象既不开放又不封闭的Client Client类和Server类都是具体类。Client类使用Server类。如果我们希望Client对象使用另外一个不同的服务器对象，那么就必须把Cl...

单一职责原则（The Single Responsibility Principle，SRP）就一个类而言，应该仅有一个引起它变化的原因。为何要把两个职责分离到单独的类中？因为每一个职责都是变化的一个轴线（an axis of change）。当需求变化时，该变化会反应为类的职责的变化。如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个。Rectangle 类具有两个职责1、提供了一个矩形几何形状的数学模型；2、在一个图形用户界面上绘制。一个较好的设计是把这

思维导图：https://www.processon.com/view/link/60d46dfb5653bb049a469068

1、客户作为团队成员 谁是客户？XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或团体。最好是客户和开发人员在一个房间中工作。2、用户故事 对于做计划而言，了解需求只需要做到能够估算它的程度就足够了，需求的特定细节很可能会随着时间而改变。新系统问世是关注需求的最好时刻。 在XP中，我们和客户反复讨论，以获取对于需求细节的理解，但是不去捕获那些细节。用户故事（user stories）就是正在进行的关于需求谈话的助记符。它是一个计划...

1、我们最优先要做的是通过尽早的、持续的交互有价值的软件来使客户满意。2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。3、经常性地交付可以工作的软件，交付的间隔可以几周~几月，交付的时间间隔越短越好。4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。5、围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并信任他们能够完成工作。6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。7、工作的软件是首要的进度度量