《敏捷软件开发:原则、模式与实践(C#版.修订版)》一第二部分 敏捷设计-阿里云开发者社区

开发者社区> 开发与运维> 正文

《敏捷软件开发:原则、模式与实践(C#版.修订版)》一第二部分 敏捷设计

简介: 在敏捷团队中,愿景和软件一起演化。在每次迭代中,团队改进系统设计,使设计尽可能适合于当前系统。团队不会花费许多时间去预测未来的需求和需要,也不会试图在今天就构建一些基础设施去支撑那些他们认为明天才会需要的特性。他们更愿意关注当前的系统结构,并使它尽可能地好。

本节书摘来异步社区《敏捷软件开发:原则、模式与实践(C#版.修订版)》一书中的第2章,作者: 【美】Robert C. Martin , Micah Martin 译者: 邓辉 , 孙鸣 责编: 杨海玲,更多章节内容可以访问云栖社区“异步社区”公众号查看。

第二部分 敏捷设计

敏捷软件开发:原则、模式与实践(C#版.修订版)
如果敏捷是指以微小增量的方式构建软件,那么究竟如何设计软件呢?又如何保证软件具有灵活、可维护以及可重用的良好结构呢?如果以微小增量的方式构建软件,难道不是先制造许多无用的代码碎片,然后再打着重构的旗号返工吗?难道不会让人只见树木,不见森林吗?

在敏捷团队中,愿景和软件一起演化。在每次迭代中,团队改进系统设计,使设计尽可能适合于当前系统。团队不会花费许多时间去预测未来的需求和需要,也不会试图在今天就构建一些基础设施去支撑那些他们认为明天才会需要的特性。他们更愿意关注当前的系统结构,并使它尽可能地好。

这种做法并不是要放弃构架或者设计,而是一种增量地演化出系统最佳构架和设计的方式。同样也是一种保持设计和构架一直适合于不断增长和演化的系统的方式。在敏捷开发中,设计和构架的过程是持续不断的。

我们如何知道软件设计的优劣呢?第7章中列举并描述了拙劣设计的症状。这些症状,或者说设计臭味,常常遍及整个软件结构。第7章演示了那些症状如何在一个软件项目中累积,并描述了如何避免它们。

这些症状定义如下:

  • 僵化性(rigidity)——设计难以改变。
    -脆弱性(fragility)——设计易于遭到破坏。

-顽固性(immobility)——设计难以重用。
-粘滞性(viscosity)——难以做正确的事情。
--不必要的复杂性(needless complexity)——过分设计。
-不必要的重复(needless repetition)——滥用鼠标进行复制、粘贴。
-晦涩性(opacity)——混乱的表达。
这些症状在本质上和代码的“臭味”(smell)相似,但是它们所处的层次稍高一些。它们是遍及整个软件结构的臭味,而不仅仅是一小段代码的。

设计中的臭味是一种症状,是可以主观(如果不能客观的话)进行度量的。这些臭味常常是由于违反了一个或者多个设计原则而导致的。第8章~第12章中描述了一些面向对象设计的原则,这些原则有助于开发人员消除拙劣设计的症状(设计臭味),并帮助他们构建出最适合于当前特性集的设计。

这些原则如下。

-第8章:单一职责原则(The Single Responsibility Principle,SRP);
-第9章:开放—封闭原则(The Open-Close Principle,OCP);
-第10章:Liskov替换原则(The Liskov Substitution Principle,LSP);
-第11章:依赖倒置原则(The Dependency-Inversion Principle,DIP);
-第12章:接口隔离原则(The Interface Segregation Principle,ISP)。



这些原则是数十年软件工程经验来之不易的成果。它们不是某一个人的成果,而是许许多多软件开发人员和研究人员思想和著作的结晶。虽然在此把它们表述为面向对象设计的原则,但是事实上它们只是软件工程中一直存在的原则的特例而已。

敏捷团队应用这些原则只是为了除去臭味。当没有臭味时,他们不会应用这些原则。仅仅因为是一个原则就无条件地遵循它是错误的。这些原则只是为了帮助我们去除一些坏味道,而不是可以随意在系统中到处喷洒的香水。过分遵循这些原则会导致不必要的复杂性的设计臭味。

本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章