关于云原生:工程设计论如何写好工程代码

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

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

一 内容概述

• 从形象的工程设计论角度论述了如何写好一份代码。论述了设计模式和设计准则的底层原理。
• 解释了设计模式与设计准则实用的场景及局限性。工程设计论是在无限设计能力下对被设计对象进行的认知和进行逆运算的过程。在不合乎这一条件的畛域，不该当死扣设计模式与设计准则。在软件畛域，一个不言而喻的例子就是不要在极度谋求性能的代码中死扣设计模式与设计准则。
• 解释了设计准则中的繁多职责准则为何难以把握和使用。
• 面向接口设计是软件系统设计的最终状态，对开发流程中先写单例再开发的起因做了解释。

二 实践根底

• 哲学根底：罗素《哲学问题》。
• 数学根底：矩阵实践，工程控制论。
• 工程根底：肯定工程设计教训，如代码开发等。
• 设计迷信根底：谢友柏老师的《设计迷信与设计竞争力》，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 个节点中的双指针就是一个典型。对于人体而言，也并不遵循什么繁多职责准则，甚至能够说耦合地不像，人在饥饿的时候，能够合成蛋白质来供能；咱们在飞机设计过程中，有思考过在液压油泄露时，拿燃油来充当液压油么？一些经典设计也并不遵循设计实践与准则，例如活塞环既可能避免漏气，又可能升高摩擦磨损，这显然也不是合乎独立公理的。

只有对设计迷信的底层逻辑有着深刻的钻研，能力使得这门迷信施展其真正的作用。尽管本文尽可能地对这个畛域进行了一些减法地操作，略去了一些不外围的因素，然而无论在实践上，还是例子上，都没有可能提供一个真正可能被验证成为正确或是谬误的想法或是命题。本文甚至连谬误都算不上，这无论如何都是让人不称心的。

六 附——利用分拆来设计零碎的一个例子

很多设计畛域的文章提出的例子，都是一些已有的设计；或是拿着基本没有市场的需要来设计一款产品。这种先射箭后画靶的行为并不能促成迷信的倒退。因而找一个大家都熟知的畛域，提出解决起来较为有难度，然而需要明确的问题来作为探讨的例子。很侥幸的是，我确实解决了我本人提出的问题。

在机械畛域，立体杆件机构的设计是最根本的问题。例如对下图中这种四杆机构，咱们常常会进行摆角的设计等工作。那么，咱们能不必匀速的电机和立体杆件，使得立体杆件上的某一点有着指定的轨迹？例如用立体杆件画一只兔子？

对于这个问题，咱们梳理咱们曾经晓得的常识，来给出一些弱束缚：

那么，咱们再由拆分给出另外的弱束缚，以解决这一问题：

在这样一个弱束缚下，咱们的问题就变为了：

如何通过一些圆周运动，及建设在其上的加法体系，拟合任意一个周期静止。

• 如何找到一个连贯组，使得其具备上述条件。
• 问题一的答案由傅里叶变换给出：

问题二能够由如下杆组实现，转动副 2 始终为转动副 1，3 的中点：

最终的设计，我用了 16 个被动件，及 16 个连贯组，共计 80 个杆件，失去的后果曾经在上图中展现了。

诚恳而言，我认为这个例子在阐明弱束缚和强束缚，以及拆分对于工程设计的必要性方面，仍旧难以解脱先射箭后画靶的嫌疑。然而至多，我不认为我设计的机构，就是本问题的最优解；我想本问题用以阐明工程设计并不能失去最好的设计这一点，还是足够的。

原文链接
本文为阿里云原创内容，未经容许不得转载。