设计演化与设计

转载请保留作者信息：

作者：88250

Blog：http:/blog.csdn.net/DL88250

MSN & Gmail & QQ：DL88250@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，它能让你感觉到什么是真正的软件设计！