在1992年，Jack W.Reeves发表了一篇名为：Code as Design的文章，这篇文章可以在《敏捷软件开发 原则、模式与实践》一书的附录中找到。
这篇文章的核心观点是：编码也是设计，而软件开发中与建筑行业中的施工所对等的工作，已经被编译器代理了。
这是几近20年前的文章，但时至今日，类似的争论仍未休止。
好像是在《软件架构设计》里，在讨论架构设计时，作者就点了一句：这总不能说是设计就是编码了吧。
解释这一问题并不复杂，但需要用到一点辩证法。
我们可以讲：设计即是编码，也不是编码。
在别的文章里我们曾经提及，软件是一种固化的思维。
从这一角度看，软件构建的核心步骤只有两个：一是明确固化什么，二是对思维进行固化。
设计和编码确实都属于第二步，因此说设计即是编码也没什么不对，他们本质相同。
但分类的时候，有一个很有趣的现象就是：
区别个体差异的往往并非该物种最本质的特征，而是某些微小差别。比如区分不同人的，并非心脏，神经系统，而是肤色，脸型等等。
当软件出现之后，人们定义设计，编码这样的名词时，所想到的估计并不是他们本质上一样不一样，而是他们那里不同。
设计和编码的相同点在于他们本质相同，不同点则是他们考虑的问题层次不同。
也就是说考虑架构和考虑某个函数的实现时，本质并无差别，有差别的只是层次。
从这个角度看，讲设计不是编码也没什么不对。
如果我们认为思维固化过程中确实需要层层分解，而这种层次是连续的，那确实很难讲清楚，从那个层次开始就不是设计，而是编码了。
所以这种争议本身，起源于词汇自身的定义，并不是特别的有意义。
当我们不需要努力区分设计和编码的边界时，尽可以认为他们是同一工作的不同层次。
但这样给设计留下了个难题，那就是究竟应该停在那个层次才最为合适--这并不是能够简单回答的问题。
最后说一句：设计处的层次较高，但服务的对象却是更底层的编码，毕竟只有最终的代码才与软件等价，只有好的代码才代表好的软件。
只是现实中这种依赖关系往往被倒置，变成了设计指挥编码。
--------------------------------------------------------------
理想流 + 软件 = 《完美软件开发：方法与逻辑》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和逻辑推演本质，追求真理。