敏捷开发的宣言和原则

貌似有段时间没写什么博客了，有质量的博客更少，虽然写博客的初衷是记录自己的学习内容，类似笔记性质的东西，但也希望能更有内容，而不是空泛的一些东西。。。

最近一大堆琐事，公司、生活，心力俱疲。节后算是找回了一些状态，这个月的学习计划，大概就是《敏捷软件开发》这本书。。。

这篇博客，就大概介绍下敏捷软件开发的宣言、原则和面向对象设计的原则，以及个人的一些理解（楷体字体做区别）。。。

个人感觉，了解一种东西，一定要明白它的设计理念，才能更懂如何去学习。。。

 

一、敏捷软件开发宣言

个体和互动高于流程和工具

工作的软件高于详尽的文档

--注重产品本身，而不是形式和流程，文档应简洁易阅读，方便维护和同步

客户合作高于合同谈判

--主动拥抱变化，及时响应，持续交付

响应变化高于遵循计划

--制定可实现的短期清晰的目标，中期的粗略的计划，长期的大方向有大概目标即可

 

二、敏捷宣言遵循的原则

1、我们最重要的目标，是通过持续不断的及早交付有价值的软件使客户满意。

--持续交付，快速迭代

2、欣然面对变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程掌握变化。

--敏捷更多适用于互联网企业，移动端更甚，一个机会的存在期可能短的可怜，应尽量保持软件的灵活性，减小对系统造成的影响

3、经常交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

--尽早的、经常的交付可工作的满足需求的软件，在Google，甚至可以做到每天交付一个可工作的软件，即beta版本

4、业务人员和开发人员必须互相合作，项目中的每一天都不例外。

--及时沟通，避免信息断层，减少延时，随时调整

5、激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支援，辅以信任，从而打成目标。

--过程和方法对于项目的影响只有次要的影响，首要的影响是人

6、不论团队内外，传递信息效果最好效率最高的方式是面对面的交谈。

--邮件听不了语气，语音看不到表情，面对面沟通是最高效的办法

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

--最终产出物是可工作的软件，so，快速迭代交付的重要性不言而喻，这也是衡量一个项目进度的重要的element

8、敏捷过程倡导可持续开发，负责人、开发人员和用户要能够共同维持其步调稳定延续。

--目标清晰，设定可实现的短期的详细的目标，当然这种步调需要长时间的培养和锻炼

9、坚持不懈的追求技术卓越和良好设计，敏捷能力由此增强。

--拒绝平庸，追求卓越，良好的设计能减少很多工作中后期的麻烦，比如技术负债！

10、以简洁为本，它是极力减少不必要工作量的艺术。

--轻文档，轻流程，重产出，重目标

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

--想起一句话：管理的最高境界是为共同的目标，整个团队共同承担责任，而不是单一职权负责制

12、团队定期的反思如何能提高成效，并因此调整自身的举止表现。

--不断思考总结，调优，减少不必要的资源消耗

 

三、面向对象设计原则

SRP：单一职责原则

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

OCP：开放封闭原则

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

LSP：Liskov替换原则

　　 子类型必须能替换掉他们的基本类型。

DIP：依赖倒置原则

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

ISP：接口隔离原则

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

REP：重用发布等价原则

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

CCP：共同重用原则

　　 一个包中所有的类应该是共同重用的，如果重用了包中的一个类，那么就要重用包中的所有类，相互之间没有紧密联系的类不应该在同一个包中。

CRP：共同封闭原则

　　 一个包中所有类对于同一类性质的变化应该是共同封闭的，一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他包不造成任何影响。

ADP：无依赖原则

　　 在包的依赖关系中不允许存在环，细节不应该被依赖。

SDP：稳定依赖原则

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

SAP：稳定抽象原则

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

 

关于敏捷软件开发模式，其宣言和原则就是上面的一些内容，后续会不断更新相关的，关于开发设计，敏捷测试的一些内容。