敏捷笔记

面向对象设计的原则

---

SRP 单一职责原则

就一个类而言，应该仅有一个引起它变化的原因。

理解：前两天在优快云中看到一个网友提出PetShop4.0中将实体类（Model项目中的类）和操作类（BLL

项目中的类）合并，这样有利于简化程序结构。我觉得有悖于这条原则。

OCP 开放-封闭原则

软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。

理解：面向对象设计是要成本，代码比结构化程序多而且牺牲一定的效率，所获得的收益是代码复用，应付多变的需求。

修改软件实体将影响到已有的客户程序，等于没有复用，这种做法属于只有投入没有产出的，只干活不拿钱的事，

我们千万不能干。

LSP Liskov 替换原则

子类型必须能够替换掉它们的基类型。

理解：子类型无法替换基类型，将会导致在派生类对象作为基类对象进行传值时的错误。

这样多态机制处于瘫痪状态了。封装是面向对象的基础，继承可以算是实现手段，

多态是面向对象的核心。头可断，血可流，小JJ不可切。

DIP 依赖倒置原则

抽象不应该依赖于细节，细节应该依赖于抽象。

理解：这可能是程序员违反最多的原则，Gof23种设计模式，

好象没几个是和这条原则没关系的。

把程序比做建筑，细节是房子的地基，抽象是房子的装璜。

扒地基搞装修的，我这辈子都没见过。

往事不堪回首，翻开我的代码，发现我也是有钱人啊，搞装修算什么，偶扒地基搞装修，抽象依赖于细节的地方多得海了去了。

不知者不为过，我很大度地原谅了自己。

ISP 接口隔离原刚

不应该强迫客户依赖于他们不用的方法。接口属于客户，不属于它所在的类层次结构。

理解：接口是客户程序和类库交流的一个通道。不同的客户程序可能用到类库的不同方法，

因此对不同的客户程序要设计一套不同的接口。类库恒久远，接口天天变啊。类库是老婆，

要保持稳定，接口是哄老婆的花言巧语，要在不同的场合，随时进行切换。

REP 重用发布等价原则

重用的粒度就是发布的粒度。

CCP 共同封闭原则

包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，

则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。

CRP 共同重用原则

一个包的所有类应该是共同重用的。如果重用了包的一个类，那么就要重用包中的所有类。

ADP 无环依赖原则

在包的依赖关系图中不允许存在环。

SDP 稳定依赖原则

朝着稳定的方向进行依赖。

SAP 稳定抽象原则

包的抽象程度应该和其稳定程度一致。

---

 

敏捷宣言遵循的原则

---

1。我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意。

2。即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3。经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间越短越好。

4。在整个项目的开发期间，业务人员和开发人员必须天天都在一起工作。

5。围绕被激励起来的个体莱构建项目，给他们提供所需的环境和支持，并信任他们能够出色的完成工作。

6。在团队内部，最具有有过并且附有效率的传递信息的方法，就是面对面的交谈。

7。工作的软件是首要的进度度量标准。 

8。敏捷的过程提倡可持续的开发进度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

9。不断得关注优秀的技能和好的设计会增强敏捷能力。

10。简单------是来完成工作最大化的艺术---------是根本的。

11。最好的架构、需求和设计出自于自组织的团队。

12。每隔一段时间，团队会在如何才能更有效的工作方面进行，然后对应的对自己的行为进行调整。

 

---

 

极限编程实践

 

 

---

1、    完整团队

         XP 项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队 的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。

2、    计划游戏

         计划是持续的、循序渐进的。每 2 周，开发人员就为下 2 周估算候选特性的成本，而客户则根据成本和商 务价值来选择要实现的特性。

3 、客户测试

         作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。

4 、简单设计

         团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想 表达的所有东西，并且包含尽可能少的代码。

5 、结对编程

         所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。

6 、测试驱动开发

         编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避 免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们 先增加一个失败的测试，然后使之通过。

7 、改进设计

         随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。

8 、持续集成

         团队总是使系统完整地被集成。一个人拆入（ Check in ）后，其它所有人责任代码集成。

9 、集体代码所有权

         任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责， 每个人都可以参与任何其它方面的开发。

10 、编码标准

         系统中所有的代码看起来就好像是被单独一人编写的。

11 、隐喻

         将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显 直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。

12 、可持续的速度

         团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是 马拉松长跑，而不是全速短跑。

 

    极限编程是一组简单、具体的实践，这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。

         极限编程的核心思想在于：从长远看，早期发现错误以及降低复杂度可以节约成本。极限编程强调我们将任务 / 系统细分为可以在较短周期解决的一个个子任务 / 模块，并且强调测试、代码质量和及早发现问题。通常，通过一个个短小的迭代周期，我们就可以获得一个个阶段性的进展，并且可以及时形成一个版本供用户参考，以便及时对用户可能的需求变更作出响应。

 

---