貌似有段时间没写什么博客了，有质量的博客更少，虽然写博客的初衷是记录自己的学习内容，类似笔记性质的东西，但也希望能更有内容，而不是空泛的一些东西。。。
最近一大堆琐事，公司、生活，心力俱疲。节后算是找回了一些状态，这个月的学习计划，大概就是《敏捷软件开发》这本书。。。
这篇博客，就大概介绍下敏捷软件开发的宣言、原则和面向对象设计的原则，以及个人的一些理解（楷体字体做区别）。。。
个人感觉，了解一种东西，一定要明白它的设计理念，才能更懂如何去学习。。。
一、敏捷软件开发宣言
个体和互动高于流程和工具
工作的软件高于详尽的文档
--注重产品本身，而不是形式和流程，文档应简洁易阅读，方便维护和同步
客户合作高于合同谈判
--主动拥抱变化，及时响应，持续交付
响应变化高于遵循计划
--制定可实现的短期清晰的目标，中期的粗略的计划，长期的大方向有大概目标即可
二、敏捷宣言遵循的原则
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：稳定抽象原则
一个包的抽象程度应该和其他稳定程度一致。
关于敏捷软件开发模式，其宣言和原则就是上面的一些内容，后续会不断更新相关的，关于开发设计，敏捷测试的一些内容。
