我把本书当作四人帮著的《设计模式》的后续之作来读。借以提高对设计模式的理解力。
本书浅显易懂，开篇还介绍了看此书的方法。
对一个开发人员，从头到尾，通读全书，先学习实践，接着是原则，然后是模式，最后是把它们联系起来的案例。
如学习UML，先看附录A，B，再看案例“薪水支付系统”。
敏捷软件开发价值观(4条)
[1]个体和交互胜过过程和工具
一个平均水平的程序员可以是一个优秀的团队成员。
使用过多过笨重的工具，跟缺少工具一样，都是不好的。合适最好，从小的工具开始，直到无法满足需要再去更换。
[2]可以工作的软件胜过面面俱到的文档
注重文档而导致进度拖延，是常见的致命错误！
有关系统结构的文档应该短小而突出。
[3]客户合作胜过合同谈判
成功的项目需要有序，频繁的客户反馈。不要指望告诉开发团队想要的东西，然后让开发团队消失一段时间后就可以拿出满足需要的系统。
[4]响应变化胜过遵循计划
计划不能考虑地过远。较好的计划是为下2周做详细的计划；为下3个月作粗略的计划。再远就作非常粗略的计划。。。
从以上价值观可以得出敏捷软件开发的原则(12条)
1.我们最优先要做的是尽早地持续地交付有价值的软件来使客户满意;
2.即使到了开发的后期,也欢迎改变需求;
3.经常性地交付可以工作的软件,交付的间隔从几周到几个月,越短越好;
4.在整个开发周期中,开发人员和业务人员应该天天在一起;
5.围绕被激励起来的个人购建项目;
6.团队内部,传递信息最有效的方法就是面对面交谈;
7.工作的软件是首要的工作度量标准;
8.提倡可持续的开发速度;
9.不断关注好的设计和优秀的技能;
10.简单是最根本的;
11.最好的架构需求和设计出于自组织的团队;
12.每隔一段时间团队应对工作效率进行自省.
面向对象设计的基本原则(5条)
单一职责原则：SRP
就一个类而言,应该仅有一个引起它变化的原因
开放-封闭原则：OCP
软件实体(类,模块,函数等)应该是可扩展的,但是不可修改的
Liskov替换原则：LSP
子类型应该能替换掉它们的基类型
依赖倒置原则:DIP
高层模块不应依赖于底层模块,两者都应依赖于抽象.抽象不应依赖于细节,细节依赖于抽象.
接口隔离原则:ISP
不应强迫客户依赖于它们不用的方法
阅读(1094) | 评论(0) | 转发(0) |
