工程设计论——如何写好工程代码

简介：设计是在对需求的认知不完整的情况下，对被设计对象进行求解的一个过程。这就迫使我们需要一边认识被设计对象，一边进行求解。为了并行化地进行这一过程，也为了使得对被设计对象地认识有初步的研究工具和基础，我们总结出了一套利用分拆提供弱约束，并基于这种分拆，来并行进行不同组件之间的设计的流程。

作者 | 任增
来源 | 阿里技术公众号

一内容概述

从抽象的工程设计论角度阐述了如何写好一份代码。阐述了设计模式和设计原则的底层原理。
解释了设计模式与设计原则适用的场景及局限性。工程设计论是在有限设计能力下对被设计对象进行的认知和进行逆运算的过程。在不符合这一条件的领域，不应当死扣设计模式与设计原则。在软件领域，一个显而易见的例子就是不要在极度追求性能的代码中死扣设计模式与设计原则。
解释了设计原则中的单一职责原则为何难以掌握和运用。
面向接口设计是软件系统设计的最终形态，对开发流程中先写单例再开发的原因做了解释。

二理论基础

哲学基础：罗素《哲学问题》。
数学基础：矩阵理论，工程控制论。
工程基础：一定工程设计经验，如代码开发等。
设计科学基础：谢友柏老师的《设计科学与设计竞争力》，Nam Suh的《公理设计》。

三什么是设计——设计和计算与认知之间的联系

一门科学的建立，应当首先明确本学科的局限性，确定本学科最基本的问题与框架。明确的基本框架应能够迅速得到一门学科的基础结论与研究方法；明确的基本问题可以用于检验上述的结论与方法。指出自然界中每一杯水中都有金元素并不能对金矿的发现起到什么促进作用。设计科学的现在的发展应该做减法而不是做加法。对于设计所具备的特征，有很多描述。这些描述最基本的共同点是设计是需要达到一定的目标的（即需求）。其他特征并不是设计最基本的特征。例如最优化设计中就没有需求变更，logo设计中就没有系统故障。

如果认同需求是设计的共同点，那么搞清楚需求是什么则是重要的。大部分人都认为，在我们的实际工作中，需求是不明确的，不完整的。那我们不妨用辩证的思维来考虑这个问题的反面，什么是明确的，完整的需求？一份完整的需求，对于所有人而言都是清晰的，不会产生什么不一样的理解。那么对于什么样的产品能够满足相应的需求，也应该是清晰的。用集合论的话来说，一个集合被其外延所完全确定。换句话说，如果需求能够被一个确定的验收方式来定义，比如说单元测试，那么这份需求可以说是明确和完整的。

我们还需要更进一步地探讨什么是验收。以单元测试为例，我们用单元测试来输出一个True或是输出一个False；如果认为单元测试本身是一个函数，那验收就是要求被设计对象在该函数下的相必须为True。那么，如果我们的需求足够简单，会发生什么情况？比如说我们的需求是找到一个x，使其满足x+1=0，我们一般称这种问题为求解，或者是逆运算。可以看到，当我们对需求及其实现方式的认识完全清晰的时候，需求将退化成为一个函数，设计将退化成为逆运算的过程。

设计的过程中，我们对于需求及实现方式的认识是不全面的，这是其与逆运算不同的核心点（而不是需求不明确或者是需求会发生变更）。例如化工产品的合成路线设计，例如高效排序算法的设计，都不存在需求本身不明确的问题。认知的不全面迫使我们需要在设计的过程中，一边对需求及其实现方式进行认知，获取更多的知识，一边进行求逆运算，找到能够满足需求的实现方式。

四工程设计的过程

在进行工程设计的过程中，对于认知和计算的交替流程，我们总结了一套行之有效的经验，即对需求的拆分和组合。

我们刚刚已经说过，需求本质上是要求一个对象，在某个函数下的像具备某些特征，这本质上是一种约束。而“被设计对象由A，B两个组件构成，A具备123特征，B具备456特征”，这和需求的描述方式没有什么不同，本质上也是一种约束。也就是说，分拆本身也是对被设计对象的一种约束，只不过满足分拆约束的对象并不一定满足需求的约束。因此我们不妨把分拆的约束当作一种对被设计对象的弱约束。

因而工程设计可以被总结成为如下的流程：

根据对需求的相关研究，给出实现方式的弱约束，我们一般采用对系统拆分的方式来进行弱约束。在软件领域，最常见的弱约束就是对组件划分的约束，各个部件之间的依赖关系，接口的定义，数据交互方式之间的约束。（认知过程，我们一般称之为需求拆解与架构设计）
利用第一步的弱约束，来对需求中的强约束的实现方式进行具体的分析和求解。（逆运算过程，我们一般称之为编码）

我们刚刚已经说明了，分拆本质上也是一种约束。第二步中的求解结果，仍旧有可能是一种对子系统需求，此时就需要我们继续进行更加细化的设计。

引入弱约束这个概念，是因为在我们对被设计对象一无所知的情况下，研究如何实现相应的需求是相对困难的。那么我们不妨假设被设计对象具备某些性质（这种假设往往也强依赖于个人经验），并将这些假设性质（比如说接口）作为研究如何实现的一种工具和框架。

例如在代码设计中，拆分为A，B两个模块并进行并行设计时，如果在A模块的实现流程完全不知道B模块的信息，那么将会对A模块的设计产生巨大的阻碍（比如前端完全不知道后端的数据格式）。但是，B模块的具体实现方式还未确定，此时A模块也不可能对B模块的信息由完整的了解，且并不是每一个B模块的信息对于其他模块都是有用的（比如后端选用的数据库格式，后端部署的位置，后端的实现方式）。所以我们需要折中的对B模块进行约束(比如规定接口)，使得A模块能够获得必要的相关信息。了解过认知论的同学也应该知道，这种接口本身就是一种对B模块的认知（参照罗素的感觉材料或是我在前序文章中所述的“关系”）。我认为这是依赖注入的底层逻辑，也是面向接口设计将成为软件设计的最终形态的底层依据。

在这个例子中，工程设计与科学研究后进行计算的最大区别即在于，第二步中的具体实现过程是并行的。各个组件的实现的并行在软件工程中是常见的（前后端分别编码，最后进行调试即是如此）。我们当然可以在完全研究清楚J(X)的性质下，再去进行设计。限制我们不去这么做的条件，并非是这样得到的产品效果一定不好，而是设计需要投入的工期与人力有限制。完全设计好前端之后，再去进行后端设计，当然是可以的，但是这种串行化的工作模式，显而易见的会对工期造成负面影响。

为了使得这种拆分方式可行，独立职责的原则就需要被引进以保证最后的组装工作顺利完成。在上一步中，我们的工作是并行的，意味着我们并不知道f(X),g(X),m(X)所需要取得的值是多少。如果我们最终研究得到

那我们显然是找不到相应的解的。这就需要我们保证f({X}),g({X}),m({X})之间的相互独立。我们对拆分地独立性及其负面影响进行进一步地探讨：

这一规则对应于软件领域中的单一职责原则，有人评论这一原则是较为难以运用和掌握的（“单一职责原则是最简单但又最难运用的原则”）。事实确实如此，接下来我们将对这一点进行探讨。

我们换一种看起来正确的模棱两可的表述更方便我们发现问题在哪。这个陈述是：独立的功能应当由独立的类来实现。那么，问题出现了。我们怎么去判断两个功能之间相互独立？熟悉哲学，并对哲学中对“Free”的讨论有接触的人会很快反应过来，“Free”这个词必然是建立于某种映射之上，单独说A与B“Free”没有任何意义。家庭教育和学校教育是否独立？道德教育和智力教育是否独立？从不同的角度会有不一样的答案。从时间上，家庭教育和学校教育相互独立；从评分标准上，道德教育和智力教育也相互独立。如果把教育也作为一种设计，我们是应该把教育划分成为家庭教育和学校教育，还是划分成为道德教育和智力教育？划分的依据究竟应该是什么？

显而易见的事情是，我们所能够接受的判断功能之间的相互独立的依据，应该是从其实现方式上相互独立。那么上面那句话，就可以改写成为：实现上独立的功能应当被独立地实现。这有点像一句政治正确的废话，其具体的运用强依赖于设计人员对于相关领域的事前经验与判断。不具备相关领域的经验，进行功能划分必然会出现一些搞笑的结果。这就是单一职责原则是最简单，也最困难的原则的原因。

五总结与局限

设计是在对需求的认知不完整的情况下，对被设计对象进行求解的一个过程。这就迫使我们需要一边认识被设计对象，一边进行求解。为了并行化地进行这一过程，也为了使得对被设计对象地认识有初步的研究工具和基础，我们总结出了一套利用分拆提供弱约束，并基于这种分拆，来并行进行不同组件之间的设计的流程。由于分拆只能提供关于被设计对象的较弱认识，因此依赖倒置和面向接口设计是必须的。为了使得并行化的设计最终可以被组装，单一职责原则（独立原则）是必须的。

可以看到，整个设计理论是必须基于对需求的认知不完整，且需要低成本（首要的是时间成本）地完成设计这一条件。对于设计周期比较长，认知较为充分的领域，设计理论并不适用。完全只用设计模式来衡量设计的好坏，也是不可取的。这方面的反例有很多，LeetCode上面的题目，恐怕没有哪一个符合了设计模式，比如说找链表倒数第k个节点中的双指针就是一个典型。对于人体而言，也并不遵循什么单一职责原则，甚至可以说耦合地不像，人在饥饿的时候，可以分解蛋白质来供能；我们在飞机设计过程中，有考虑过在液压油泄露时，拿燃油来充当液压油么？一些经典设计也并不遵循设计理论与原则，例如活塞环既能够防止漏气，又能够降低摩擦磨损，这显然也不是符合独立公理的。

只有对设计科学的底层逻辑有着深入的研究，才能使得这门科学发挥其真正的作用。虽然本文尽可能地对这个领域进行了一些减法地操作，略去了一些不核心的要素，但是无论在理论上，还是例子上，都没有能够提供一个真正能够被验证成为正确或是错误的想法或是命题。本文甚至连错误都算不上，这无论如何都是让人不满意的。