本文介绍了敏捷软件开发宣言的核心理念，强调个体交互、工作软件、客户合作及响应变化的重要性。探讨了面向对象设计的多项原则，如单一职责、开放封闭、Liskov替换等，并讨论了极限编程实践中的美学与平衡概念。
1、敏捷软件开发宣言
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
2、面相对象设计的原则
单一职责原则
开放-封闭原则
Liskov替换原则
替换原则
依赖倒置原则
接口隔离原则
重用发布等价原则
共同封闭原则
无环依赖原则
稳定依赖原则
稳定抽象原则
3、极限编程实践
最好的软件开发人员都知道一个秘密：美的东西比丑的东西创建起来更廉价，也更快捷。构建维护一个美的软件系统所花费的时间、金钱都要少于丑的系统。软件开发新手往往不理解这一点。
软件设计最精髓的东西：平衡。
设计是人的思维的一种动态活动，是设计者针对自己的问题的思索、权衡、折衷、选择的过程。其中会出现很多在理想情况下不会出现的问题，对这些问题的处理水平才是真正的设计水平。
此外，本书中也讲述了很多的设计模式，但是和很多其他讲述模式的书不同的是，它更多的时候是在告诉你什么时候不要去使用模式，去抵制模式的诱惑，以免带来不必要的复杂性。在对模式狂热吹捧的今天，本书无疑是一剂纠偏良药，可以让你更加合理、有效地使用模式。
本书主要包含4部分内容，这些内容对于今天的软件工程师都非常的重要，它们是：
敏捷方法
面相对象设计原则
设计模式
UML
注：跟《UML和模式应用》有较多的重合之处，不知道谁讲得好。
但是有一件事我却比以往更加清楚，那就是：交付产品的关键因素是人，而不是过程。我们成功的诀窍很简单：和那些沉醉于交付软件的人一起工作，使用适合于自己团队的轻量过程进行开发，并且不断去适应。
第1部分 敏捷开发（跳过，暂时不看）
第2部分 敏捷设计
在敏捷团队中，全局视图和软件一起演化。在每次迭代中，团队改进系统设计，使设计尽可能适合于当前系统。团队不会花费许多时间去预测未来的需求和需要，也不会试图在今天就构建一些基础结构去支撑那些他们认为明天才会需要的特性。他们更愿意关注当前的系统结构，并使它尽可能地好。
注：有疑问
第7章 什么是敏捷设计
在这篇文章中，ReeVes认为软件系统的源代码是它的主要设计文档。用来描述源代码的图示只是设计的附属物而不是设计本身。结果表明，Jack的论文是敏捷开发的先驱。
最后，源代码就是设计。
注：以写文档的态度来写代码，换句话说，我们不是仅仅在写代码，我们实际在写文档，是给别人看的，不要写出看不懂的文档
如果设计中包含有当前没有用的组成部分，它就含有不必要的复杂性。当开发人员预测需求的变化，并在软件中放置了处理那些潜在变化的代码时，常常会出现这种情况。起初，这样看起来像是一件好事。毕竟，为将来的变化做准备会保持代码的灵活性，并且可以避免以后再进行痛苦的改动。
糟糕的是，结果常常正好相反。为过多的可能性做准备，致使设计中含有绝对不会用到的结构，从而变得混乱。一些准备也许会带来回报，但是更多的不会。期间，设计背负着这些不会用到的部分，使软件变得复杂，并且难以理解。
注：如何把握呢
敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持系统设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这些灵活性，持续改进设计，以便于每次迭代结束所生成的系统都具有最适合于那次迭代中需求的设计。
注：我们为什么不行呢，我觉得我们没有持续改进设计的驱动，每次改代码仅仅是为了添加功能，没有经常回顾设计，还有就是持续改进设计对开发人员的能力要求挺高，需要他们明白设计，设计是否出问题了，该如何走向，可是我们的编码人员哪有这能力
记住，在大多数软件项目中最不稳定的东西就是需求。
使用敏捷开发方法时，一开始编写的代码和程序7.1中的完全一样。在老板要求敏捷开发人员使程序可以从纸带读入机读取信息时，他们会做出这样的反应：修改设计并使修改后的设计对于那一类需求的变化具有弹性。
注：如果那一类需求没出现呢，呵呵
在要实现新需求时，团队抓住这次机会去改进设计，以便设计对于将来的同类变化具有弹性，而不是设法去给设计打补丁。从现在开始，无论何时老板要求一种新的输入设备，团队将都能以不导致Copy程序退化的方式做出反应。
有人会认为他们仅仅完成了一半的工作。他们在使自己免于不同的输入设备带来的麻烦时，本可以也使自己免于不同的输出设备带来的麻烦。然而，团队实在不知道输出是否会变化。现在就添加额外的保护没有任何现实意义。很明显，如果需要这种保护时，以后可以非常容易地添加。因此，实在没有现在就添加的理由。
注：因为刚开始的设计很简单，就算后面换成复杂的设计也不会带来更多的工作量，但是一开始就复杂的设计，需求没有时就浪费了，并且代码复杂。
设计必须要保持干净、简单，并且额由于源代码是设计最重要的表示，所以它同样要保持干净。职业特性要求我们，作为软件开发人员，不能忍受代码腐化。
注：谨记
第8章 单一职责原则
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
2、面相对象设计的原则
单一职责原则
开放-封闭原则
Liskov替换原则
替换原则
依赖倒置原则
接口隔离原则
重用发布等价原则
共同封闭原则
无环依赖原则
稳定依赖原则
稳定抽象原则
3、极限编程实践
最好的软件开发人员都知道一个秘密：美的东西比丑的东西创建起来更廉价，也更快捷。构建维护一个美的软件系统所花费的时间、金钱都要少于丑的系统。软件开发新手往往不理解这一点。
软件设计最精髓的东西：平衡。
设计是人的思维的一种动态活动，是设计者针对自己的问题的思索、权衡、折衷、选择的过程。其中会出现很多在理想情况下不会出现的问题，对这些问题的处理水平才是真正的设计水平。
此外，本书中也讲述了很多的设计模式，但是和很多其他讲述模式的书不同的是，它更多的时候是在告诉你什么时候不要去使用模式，去抵制模式的诱惑，以免带来不必要的复杂性。在对模式狂热吹捧的今天，本书无疑是一剂纠偏良药，可以让你更加合理、有效地使用模式。
本书主要包含4部分内容，这些内容对于今天的软件工程师都非常的重要，它们是：
敏捷方法
面相对象设计原则
设计模式
UML
注：跟《UML和模式应用》有较多的重合之处，不知道谁讲得好。
但是有一件事我却比以往更加清楚，那就是：交付产品的关键因素是人，而不是过程。我们成功的诀窍很简单：和那些沉醉于交付软件的人一起工作，使用适合于自己团队的轻量过程进行开发，并且不断去适应。
第1部分 敏捷开发（跳过，暂时不看）
第2部分 敏捷设计
在敏捷团队中，全局视图和软件一起演化。在每次迭代中，团队改进系统设计，使设计尽可能适合于当前系统。团队不会花费许多时间去预测未来的需求和需要，也不会试图在今天就构建一些基础结构去支撑那些他们认为明天才会需要的特性。他们更愿意关注当前的系统结构，并使它尽可能地好。
注：有疑问
第7章 什么是敏捷设计
在这篇文章中，ReeVes认为软件系统的源代码是它的主要设计文档。用来描述源代码的图示只是设计的附属物而不是设计本身。结果表明，Jack的论文是敏捷开发的先驱。
最后，源代码就是设计。
注：以写文档的态度来写代码，换句话说，我们不是仅仅在写代码，我们实际在写文档，是给别人看的，不要写出看不懂的文档
如果设计中包含有当前没有用的组成部分，它就含有不必要的复杂性。当开发人员预测需求的变化，并在软件中放置了处理那些潜在变化的代码时，常常会出现这种情况。起初，这样看起来像是一件好事。毕竟，为将来的变化做准备会保持代码的灵活性，并且可以避免以后再进行痛苦的改动。
糟糕的是，结果常常正好相反。为过多的可能性做准备，致使设计中含有绝对不会用到的结构，从而变得混乱。一些准备也许会带来回报，但是更多的不会。期间，设计背负着这些不会用到的部分，使软件变得复杂，并且难以理解。
注：如何把握呢
敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持系统设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这些灵活性，持续改进设计，以便于每次迭代结束所生成的系统都具有最适合于那次迭代中需求的设计。
注：我们为什么不行呢，我觉得我们没有持续改进设计的驱动，每次改代码仅仅是为了添加功能，没有经常回顾设计，还有就是持续改进设计对开发人员的能力要求挺高，需要他们明白设计，设计是否出问题了，该如何走向，可是我们的编码人员哪有这能力
记住，在大多数软件项目中最不稳定的东西就是需求。
使用敏捷开发方法时，一开始编写的代码和程序7.1中的完全一样。在老板要求敏捷开发人员使程序可以从纸带读入机读取信息时，他们会做出这样的反应：修改设计并使修改后的设计对于那一类需求的变化具有弹性。
注：如果那一类需求没出现呢，呵呵
在要实现新需求时，团队抓住这次机会去改进设计，以便设计对于将来的同类变化具有弹性，而不是设法去给设计打补丁。从现在开始，无论何时老板要求一种新的输入设备，团队将都能以不导致Copy程序退化的方式做出反应。
有人会认为他们仅仅完成了一半的工作。他们在使自己免于不同的输入设备带来的麻烦时，本可以也使自己免于不同的输出设备带来的麻烦。然而，团队实在不知道输出是否会变化。现在就添加额外的保护没有任何现实意义。很明显，如果需要这种保护时，以后可以非常容易地添加。因此，实在没有现在就添加的理由。
注：因为刚开始的设计很简单，就算后面换成复杂的设计也不会带来更多的工作量，但是一开始就复杂的设计，需求没有时就浪费了，并且代码复杂。
设计必须要保持干净、简单，并且额由于源代码是设计最重要的表示，所以它同样要保持干净。职业特性要求我们，作为软件开发人员，不能忍受代码腐化。
注：谨记
第8章 单一职责原则
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
