第七章 什么是敏捷设计
软件项目的设计是一个抽象的概念.它和程序的概括形状/结构以及每一个模块/类和方法的详细形状和结构有关.可以用不同的媒介去描述他,但是他最终体现为源代码.源代码就是设计.
敏捷设计是一个过程,而不是一个事件.它是一个持续的应用原则/模式以及实践来改进软件的结构和可读性的过程.它致力于保持系统设计在任何时间都能尽可能得简单/干净和富有表现力.
实际上满足工程设计标准的唯一软件文档,就是源代码清单.–Jack Reeves
UML图只描绘了设计的一些部分,但是它并不是设计.
敏捷开发人员对待软件设计的态度要像外科医生对待消毒过程的态度是一样的.
设计需要保持干净/简单,并且由于源代码是设计最重要的展示,所以它同样需要保持干净.职业特性要求我们,作为软件开发人员,不能忍受代码腐化.
软件腐化的坏味道
僵化性(Rigidity):很难对系统进行改动,每个改动都会迫使许多对系统其它部分的其它改动.
脆弱性(Fragility):对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题.
牢固性(Immobility):很难解开系统的纠结,使之成为一些可在其它系统中重用的组件.
粘滞性(Visosity):做正确的事情比做错误的事情要困难.
不必要的复杂性(Needless Complexity):设计中含有不具有任何直接好处的基础结构.
不必要的重复(NeedLess Repetition):设计中包含有重复结构,而该重复的结构本可以使用单一的抽象进行统一.
晦涩性(Opacity):很难阅读/理解.没有很好的表现意图.
软件腐化的原因
- 变化而又改动急迫的需求/修改人员对原设计思路不熟悉/以上变化的日积月累
- 我们需要意识到,需求是项目中最不稳定的要素.大多数软件项目中最不稳定的东西就是需求.需求处在一个持续变动的状态之中.
- 如果设计因为持续/大量的需求变化而失败,就表明设计和实践本身是有缺陷的.
敏捷团队不允许代码腐坏
敏捷团队依靠变化来获取活力.团队几乎不进行预先设计,不需要一个成熟的初始设计.团队更愿意保持系统设计尽可能的干净/简单,并使用许多的单元测试和验收测试作为支援.
团队在开始设计的时候以最简单的方法编写.直到需求最终明确变化时,他们才修改模块的设计,是之对该变化保持弹性.
敏捷开发人员如何知道做什么.
- 遵循敏捷实践去发现问题(一二章内容)
- 应用设计原则去诊断问题(单一职责/里式替换/依赖倒转/开闭/接口隔离)
- 应用适当的设计模式去解决问题.
第八章 单一职责原则(SRP)
单一职责原则:就一个类而言,应该仅有一个引起它变化的原因.
- 如果一个类承担过多的职责,那么引起它变化的原因就会有多个.多个职责在一个类中后合在一起会导致脆弱(fragile)的设计.在发生变化的时候可能会遭受意想不到的破坏.
- 什么是职责?在SRP中,我们把职责定义为”变化的原因”.如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.
- 每一个职责都是一个变化的轴线. 该变化会反应为类的职责的变化.变化的轴线仅当变化实际发生时才具有真正的意义.如果没有征兆,那么去应用SRP或者其他原则都是不明智的.
- SRP是所有原则中最简单的之一,也是最难正确运用的之一.我们会自然地把职责结合在一起.软件设计真正要做的许多内容,就是发现职责并把这些职责相互分离.
第九章 开放-关闭原则(OCP)
开放-关闭原则:软件实体(类,模块,函数等等)应该是可以扩展的,但是不可以修改.
如果程序中因为一处修改就发生连锁反应,那么它的设计就有僵化性的坏味道.OCP建议在发生变化的时候,对系统的设计进行重构,确保以后在进行同样的改动的时候能够只增加新的代码,而不需要做更多的修改.
STARTEGY(策略)模式和TEMPLATE METHOD(模板方法)模式是实现OCP常用的方法.
无论模块多么封闭,都存在一些无法对之封闭的变化.设计人员必须对于他设计的模块应该对那种变化封闭做出选择.
封闭建立在抽象的基础上.
OCP的应用应该限定在可能发生的变化上(原因:OCP的代价是昂贵的,正确的抽象需要花费开发时间和精力,抽象也会增加系统的复杂性,开发人员有能力处理的抽象是有限的)
什么时候考虑/适合应用OCP
变化真正发生的时候.
- 只受一次愚弄.最初编写代码的时候,假设变化是不发生的.当变化发生的时候,重构系统,创建抽象隔离以后的同类变化.
- 刺激变化.通过编写测试/短迭代周期/首先开发重要特性/尽早的经常的发布软件.
遵循OCP原则可以带来面向对象技术所生成的巨大好处(灵活性,可重用性和可维护性)
抽象应该针对程序中频繁变化的那部分.
拒绝不成熟的抽象和抽象本身一样重要.
;
