编码工作也是一种设计

【设计 = 编码】 VS 【设计 ≠ 编码】
服务器君一共花费了221.497 ms进行了5次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

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

这篇文章的核心观点是:编码也是设计,而软件开发中与建筑行业中的施工所对等的工作,已经被编译器代理了。这是几近20年前的文章,但时至今日,类似的争论仍未休止。好像是在《软件架构设计》里,在讨论架构设计时,作者就点了一句:这总不能说是设计就是编码了吧。

解释这一问题并不复杂,但需要用到一点辩证法。我们可以讲:设计即是编码,也不是编码。

在别的文章里我们曾经提及,软件是一种固化的思维。从这一角度看,软件构建的核心步骤只有两个:一是明确固化什么,二是对思维进行固化。

设计和编码确实都属于第二步,因此说设计即是编码也没什么不对,他们本质相同。但分类的时候,有一个很有趣的现象就是:区别个体差异的往往并非该物种最本质的特征,而是某些微小差别。比如区分不同人的,并非心脏,神经系统,而是肤色,脸型等等。

当软件出现之后,人们定义设计,编码这样的名词时,所想到的估计并不是他们本质上一样不一样,而是他们那里不同。设计和编码的相同点在于他们本质相同,不同点则是他们考虑的问题层次不同。

也就是说考虑架构和考虑某个函数的实现时,本质并无差别,有差别的只是层次。从这个角度看,讲设计不是编码也没什么不对。

如果我们认为思维固化过程中确实需要层层分解,而这种层次是连续的,那确实很难讲清楚,从那个层次开始就不是设计,而是编码了。所以这种争议本身,起源于词汇自身的定义,并不是特别的有意义。

当我们不需要努力区分设计和编码的边界时,尽可以认为他们是同一工作的不同层次。但这样给设计留下了个难题,那就是究竟应该停在那个层次才最为合适——这并不是能够简单回答的问题。

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

本文地址:http://www.nowamagic.net/librarys/veda/detail/1652,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/1652

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《程序员修炼之道:从小工到专家》 亨特(Andrew Hunt) (作者), 托马斯(David Thomas) (作者), 马维达 (译者)

《程序员修炼之道:从小工到专家》内容简介:《程序员修炼之道》由一系列独立的部分组成,涵盖的主题从个人责任、职业发展,知道用于使代码保持灵活、并且易于改编和复用的各种架构技术,利用许多富有娱乐性的奇闻轶事、有思想性的例子及有趣的类比,全面阐释了软件开发的许多不同方面的最佳实践和重大陷阱。无论你是初学者,是有经验的程序员,还是软件项目经理,《程序员修炼之道:从小工到专家》都适合你阅读。

更多计算机宝库...