D 的个人博客

开源程序员,自由职业者

小而美的 Java 博客系统 Solo
Golang 在线 IDE Wide
黑客与画家的社区 Sym
  menu
397 文章
1,688 评论
3306584 浏览
28 当前访客
ღゝ◡╹)ノ❤️

设计演化与设计

转载请保留作者信息:

作者:88250

Bloghttp:/blog.csdn.net/DL88250

MSN & Gmail & QQDL88250@gmail.com


我认为,要成为优秀的软件设计者,学习软件设计的演化(尤其是设计演化)比学习软件设计更为重要。只有从演化的过程中才能看清设计的本质。

 

以往,我们只注重设计,认为设计是优质软件制造的必要条件。但好的设计往往是依靠设计者多年从事此行的经验,特别是所谓的大规模软件,此类软件的设计过于依赖于经验,过于依赖于人的个体行为。这样的依赖过于具体。

 

记得OO原则中有一条 Dependence Inversion:抽象不应该依赖于细节,细节应该依赖于抽象。如果把软件设计比作是细节,而设计演化比作是抽象的话,可以这样理解:设计演化不应当依赖于涉及本身,设计本身应该依赖于设计演化。为什么这么说呢?

 

总所周知,软件设计的产出物是一系列的设计文档,最终产物是源代码,即软件设计的产出物是源代码。关于软件设计到底是什么的讨论一直没有最权威的定义。但我一直坚信源代码就是设计的论断(Jack W.Reeves 1992, 什么是软件设计),设计过程中产生的文档只能算是辅助文档,它们根本不是设计。

 

假若你也同意以上观点,那么一些问题出现了,其中我认为有一个问题是至关重要的:目前任何源代码都是特定语言编写的,代码一旦编写完毕,无论合理运用了多少优秀的模式,最后也是难于扩展的和维护的。

 

设计是软件过程的一部分,从宏观设计,即架构设计层次上看,设计必须要选定技术方案。一点点很关键,但技术方案是相当具体的,技术方案不只会对设计产生影响,也会对设计的演化产生巨大的影响。这样的做法就是让演化强烈依赖于设计了。

 

因此,我认为正确的做法应该是让设计依赖于演化,也就是应该重视软件设计的演化过程,而不是重视设计。这一点就是 Kent Beck 所提到的从迭代中演化架构,但这一观点引起了太多的争论。

 

前不久,作为架构设计师与主程序员,我参与了一个词典项目。这个项目提出了一种新颖的词典服务方式,围绕开放式、以用户在线工作平台为目标而展开。在设计前期,我花了很多时间分析需求。而实际上,所有需求都是我假设出来的。客户只说了要做一个这样的创新项目。在与项目经理商量后,我们决定以XP方式进行项目。

 

开始时,我们以用户素材(User Story)的方式归纳了需求,排序了它们,并以Java作了实现。随着迭代的进行,代码开始变多,集成开始稍微有些复杂了。最令人头疼的问题是我们自己定义的需求时常被我们自己更改,甚至一些在迭代1中认为是系统特性的需求,却在迭代2的计划中将它整个删除!

 

为了适应这样的经常性手术,我们不断地重构代码,并逐渐形成了自己的可扩展、类插件式的应用框架,其核心是一系列的抽象工厂与一系列的抽象接口层次。后来,在查阅了关于Java的可扩展应用后,我突然想起

了eclipse!我们的应用就是需要这样一个类插件系统,以方便扩展新的特性。在翻阅了eclipse的底层框架——OSGi的规范与一些参考文档后,我决定将我们的项目迁移到OSGi上来。

 

迁移过程是无痛的,因为我们迭代产生的设计一直拥有低耦合、组件化的特征;迁移过程也是痛苦的,因为我们抛弃了几乎所有我们自己框架的代码。不过,这次演化是成功的,因为我们的目的达到了,系统在OSGi框架上运行地很好!

 

我的经验与Garmma(eclipse项目负责人)是比不了的。当时eclipse2.x到eclipse3.0的时候不知道小了多少决心、做了多少时间与调研。的确,软件演化同任何生物进化一样,其过程是痛苦的,但结果应该是美好的!

 

举上面的例子,我只想说明一个事实:软件设计演化远远比软件设计本身重要。敏捷方法,尤其是XP,它能让你感觉到什么是真正的软件设计!

 
评论