【设计 = 编码】 VS 【设计 ≠ 编码】

在1992年,Jack W.Reeves发表了一篇名为:Code as Design的文章,这篇文章可以在《敏捷软件开发 原则、模式与实践》一书的附录中找到。

 

这篇文章的核心观点是:编码也是设计,而软件开发中与建筑行业中的施工所对等的工作,已经被编译器代理了。

这是几近20年前的文章,但时至今日,类似的争论仍未休止。

好像是在《软件架构设计》里,在讨论架构设计时,作者就点了一句:这总不能说是设计就是编码了吧。

 

解释这一问题并不复杂,但需要用到一点辩证法。

 

我们可以讲:设计即是编码,也不是编码。

 

在别的文章里我们曾经提及,软件是一种固化的思维。

 

从这一角度看,软件构建的核心步骤只有两个:一是明确固化什么,二是对思维进行固化。

设计和编码确实都属于第二步,因此说设计即是编码也没什么不对,他们本质相同。

 

但分类的时候,有一个很有趣的现象就是:

区别个体差异的往往并非该物种最本质的特征,而是某些微小差别。比如区分不同人的,并非心脏,神经系统,而是肤色,脸型等等。

 

当软件出现之后,人们定义设计,编码这样的名词时,所想到的估计并不是他们本质上一样不一样,而是他们那里不同。

 

设计和编码的相同点在于他们本质相同,不同点则是他们考虑的问题层次不同。

 

也就是说考虑架构和考虑某个函数的实现时,本质并无差别,有差别的只是层次。

从这个角度看,讲设计不是编码也没什么不对。

 

如果我们认为思维固化过程中确实需要层层分解,而这种层次是连续的,那确实很难讲清楚,从那个层次开始就不是设计,而是编码了。

所以这种争议本身,起源于词汇自身的定义,并不是特别的有意义。

当我们不需要努力区分设计和编码的边界时,尽可以认为他们是同一工作的不同层次。

但这样给设计留下了个难题,那就是究竟应该停在那个层次才最为合适--这并不是能够简单回答的问题。

 

最后说一句:设计处的层次较高,但服务的对象却是更底层的编码,毕竟只有最终的代码才与软件等价,只有好的代码才代表好的软件。

只是现实中这种依赖关系往往被倒置,变成了设计指挥编码。

 

--------------------------------------------------------------

 

理想流 + 软件 = 《完美软件开发:方法与逻辑》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和逻辑推演本质,追求真理。

 

 

 

posted on 2012-03-21 00:16  理想流  阅读(1820)  评论(2编辑  收藏  举报