首页 理论教育 设计与编码的关系对于完美软件开发的方法与逻辑

设计与编码的关系对于完美软件开发的方法与逻辑

时间:2023-11-21 理论教育 版权反馈
【摘要】:设计和编码确实都属于第二步,因此说设计即是编码也没什么不对,它们本质相同。关于软件架构设计与设计相关的概念里最吸引眼球的应该是软件架构设计。但对什么是软件架构设计事实上并没有定论,反倒是从架构设计所要做的事情上更能看清什么是架构设计。在《软件架构设计》一书中,温昱先生提到了5视图法,这可以让人比较清楚地一窥架构设计的概貌。

设计与编码的关系对于完美软件开发的方法与逻辑

在1992年,Jack W·Reeves发表了一篇名为“Code as Design”的文章,这篇文章可以在《敏捷软件开发原则、模式与实践》一书的附录中找到。这篇文章的核心观点是:编码也是设计,而软件开发中与建筑行业中的施工所对等的工作,已经被编译器代理了。

这是20多年前的文章,但时至今日,类似的争论仍未休止。解释这一问题并不复杂,但需要用到一点辩证法。我们可以讲:设计即是编码,也不是编码。

在前文我们曾经一再论及,软件是一种固化的思维。从这一角度看,软件构建的核心步骤只有两个:一是明确固化什么;二是对思维进行固化。设计和编码确实都属于第二步,因此说设计即是编码也没什么不对,它们本质相同。但分类的时候,有一个很有趣的现象就是:区别个体差异的往往并非该物种最本质的特征,而是某些微小差别。比如区分不同人的,并非心脏、神经系统,而是肤色、脸型等。

当软件出现之后,人们定义设计,编码这样的名词时,所想到的估计并不是它们本质上一样不一样,而是它们哪里不同。设计和编码的相同点在于它们本质相同,不同点则是它们考虑的问题层次不同。也就是说考虑架构和考虑某个函数的实现时,本质并无差别,有差别的只是层次。从这个角度看,说设计不是编码也没什么不对。

如果我们认为思维固化过程中确实需要层层分解,而这种层次是连续的,那确实很难讲清楚从哪个层次开始就不是设计,而是编码了。所以这种争议本身,起源于词汇自身的定义,并不是特别有意义。在这本书里,我们强调的是思维的固化,因此并不会努力区分设计和编码的边界,而认为它们是同一工作的不同层次。

设计所处的层次较高,但服务的对象却是更底层的编码,毕竟只有最终的代码才与软件等价,只有好的代码才代表好的软件。只是现实中这种依赖关系往往被倒置,变成了设计指挥编码。

关于软件架构设计

与设计相关的概念里最吸引眼球的应该是软件架构设计。但对什么是软件架构设计事实上并没有定论,反倒是从架构设计所要做的事情上更能看清什么是架构设计。

在《软件架构设计》一书中,温昱先生提到了5视图法,这可以让人比较清楚地一窥架构设计的概貌。

(1)逻辑架构

逻辑架构关注功能。不仅包括用户可见的功能,还包括为实现用户功能而必须提供的“辅助功能模块”,它们可能是逻辑层、功能模块和类等。

(2)开发架构

开发架构关注程序包,不仅包括要编写的源程序,还包括直接使用的第三方SDK和现成框架、类库,以及开发的系统将运行于其上的系统软件或中间件。

(3)运行架构

运行架构关注进程、线程、对象等运行时概念,以及相关的并发、同步、通信等问题。(www.xing528.com)

(4)物理架构

物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器,以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。

(5)数据架构

数据架构关注持久化数据的存储方案,不仅包括实体及实体关系的数据存储格式,还可能包括数据传递、数据复制和数据同步等策略。

—温昱,《软件架构设计》

这一分类的好处是让人比较容易找到架构设计的切入点,坏处则是把架构设计这一工作无边界化。按照这种归类方法,几乎没什么不属于架构设计的范畴

我们这里的归类与上述略有不同。

本书认为持续打造概念的边界和定义概念间的逻辑关系是设计和编码的核心任务,其他方面的内容对这一核心任务形成约束。也就是说,认为上面5视图法中的逻辑架构和运行架构,数据架构是设计的核心任务,而开发架构和物理架构(乃至其他)则只是约束的一种。与之类似的约束还有很多,要根据需求自身来逐一考虑。

这与Brooks在《人月神话》中所陈述的观点更为类似,Brooks认为:

所有软件活动包括根本任务—打造构成抽象软件实体的复杂概念结构;次要任务—使用编程语言表达这些抽象实体,在空间和时间限制内将它们映射成机器语言

本书中认为开发架构和物理架构这类的约束诚然必要,有时甚至很关键,但更类似于Brooks所说的次要任务,其复杂度要逊于打造概念边界和定义概念间的逻辑关系。

比如说,当我们要开发一个网站的时候,是否选择Hadoop作为基础平台无疑是非常关键的,甚至可能决定产品未来的成败。但究竟选择哪个平台却绝对不是软件开发中要解决的本质问题,否则就等价于认为软件开发是一种组装工作。也即是说,平台自身并不是软件,只有平台上的开发东西才能决定软件的差异。

因此本书中并不会去探讨:如何考虑究竟是自己开发还是使用现成(开源的或者购买)的产品?依据什么样的原则来部署软件到不同电脑?如何组织代码的文件和目录结构?如何保证编译速度最佳?如何选择合适的数据库等?

但这并不意味着开发产品时判断应该使用什么框架、使用哪个数据库等并不重要或者意味着这种选择很简单,而只是说这是另外一个非常独立的话题,需要一些特别的考量,比如说,框架与需求的匹配程度,是否是开源的,是否可以得到良好的支持,license是否合适等,而本书中不会对此进行覆盖。

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

我要反馈