.. Kenneth Lee 版权所有 2019-2020
:Authors: Kenneth Lee :Version: 1.0
思维上的洞
昨天在知乎上看到推荐的一本叫“逻辑解释道德经”的书（以下简称书），我简单翻了一下 预览，突然对很对道德经为什么常常被解读得离题万里有了一些认识了。
要说这本书，作者的三观是很正的，他认为应该从训诂，逻辑，上下文这些角度找到《道 德经》想说的是什么。结果这么正的三观，居然可以把“天下皆知美之为美，斯恶已”解释 为：“天下都知晓美为什么是美的，那丑恶就消失了”。你说这就是“老子”原来的意思，我 也没法跟你争，但这除了证明老子是个傻逼，什么都说明不了。
结合文档讨论的4+1视图问题，我突然对思维上的洞的有了一个很直接的认识了。我试试看 能不能把这个事情说得清楚一些。
我们先科普一下4+1视图。我借用一张网上的图，作为引用：
.. figure:: _static/网上的4+1视图.jpg
这张图不怎么好，我看过更典型的图，在每个视图上还画了一个小小的UML图表示这个这个 视图大概对应着什么UML的图的。
这个方法其实不需要太多的计算机知识，你就可以理解它是干什么的。
架构设计这个东西，通常你是面对着一大群人，有些是你手下，有些是你领导（给你资源 的人），有些是你的合作伙伴，等等等等。大家要一起实现一个目的，但每个人都有自己 的观点，最终组合起来能不能实现那个目的呢，我们都不知道。
产品做出来了，可能你知道大概这个产品是什么样的，但其实在早期，你那群人根本不知 道要干什么。因为每个人都有自己的知识盲点。到底要干什么你（们）是不知道的。
这个没有组织过一件复杂的事情很难理解，即使你是资深的程序员，都不一定能理解这里 的工作。我见过非常资深的芯片工程师，各种投片陷阱，功耗设计，说起来头头是道，但 设计起来还是要问我：“你们软件的需求是什么？用哪个标准？”
问题是，我怎么知道？这些不是我们设计的动力啊。我们的动力是去卖钱，但你产品还没 有出来，你去问顾客：“您给我写个接口说明出来，我给你设计一款芯片，你再给我几个亿 好不好？”，顾客会觉得你是神经病吧？
我们需要有人操作一个逻辑设计，这个逻辑设计既不是代码，也不是芯片，也不是用户手 册，销售指导，但它决定了这些设计“为什么需要这样设计”，这个逻辑设计，就是架构设 计。
所以架构设计很难，难在它的驱动力是非常不直接的。它只设计了一部分，而这个部分必 须能控制其他所有部分的发展。4+1视图方法，是告诉架构师，要从哪些维度来构建这些逻 辑。4+1只是主要的视图集，这个方法并不拒绝你有更多视图。只是可以考虑的角度太多， 你可以从这4个方向开始看而已。
这些东西称为视图，强调的是你从哪个角度看这个问题，它可以用任何办法表述，并不需 要是一副UML图，只是很多概念关系用UML图比较容易说清楚而已。UML是辅助工具，是一种 典型做法的代表，不是这个视图的本质。
其中，逻辑视图是还原这是一件什么事。习惯了接到需求就开始编码的工程师，可能不知 道把这个需求给你有多难。我参加过一个架构评审，他们收到的原始需求是这样的：“通过 对‘能力’的管理，发现网络的性能瓶颈，实现对网络的‘整改’，提高网络效率30%”。
现在你告诉我，这里要写什么程序？程序的要求是什么？
这种东西，就需要“逻辑视图”。你先告诉我：怎么定义“能力”，“整改”，“网络效率”吧。
事是什么事清楚了，剩下的问题是做该怎么做，这就有：
开发视图（开发视角）：我们打算做几个部件？从哪里来？版本是啥？你可能要做一个管 理节点发行版，数据收集Daemon，说不定还要做一个环境温度检测Sensor，这些都是开发 工作量，直接决定了你的工程师投入，这个逻辑得通。处理视图（运行视角）：你的软件 部署多少份？跑多少个数据收集的Daemon？如果未来扩容，这些Daemon的数据一起往你的 管理节点送，你受得了吗？这个逻辑也得通。部署视图（部署视角）：你的软件分别放哪 里？怎么放过去？坏了怎么办？这个逻辑也得通
这些逻辑通了（但要推动这些视图的设计，需要不断用场景来驱动，这个因为本文不是谈 这种方法本身，我们忽略），才有你怎么写你那些代码，做你的Verilog/Chisel（芯片的 代码），写你的接口手册……。这些设计逻辑，不是用来给你做代码，做Verilog的，它是驱 动你怎么决定这些部分的需求的。它的逻辑一变，就是你几百人月的工作量的投入还是不 投入。这才是架构设计。拿架构设计的模型来决定代码如何分模块，这你当然觉得“架构设 计没什么用”，“UML完全没有存在的必要”了。这个工具设计出来就不是给你用的，跟你谈 完全就是对牛弹琴么。
类比起来，《道德经》是谈治国和战略设计方法的，如果你就不是干这种事情，写的人钻 在原文上，读的人也钻在原文上，你们之间就留下一个巨大的思维上的洞，让你们觉得“啊 ，这个就解释通了”，“这个说得好有道理”。其实根本就活在一个自己给自己打造的牢笼里 。这就相当于一个从来没有软件构架设计经验的英语10级的人翻译一本英文的架构设计的 书，写的没有任何架构经验，读的也没有任何架构设计经验，却要对原书进行“解读”，结 果当然就是越用力越错了。你会画几百张UML图（别笑，我是真见过产品这么弄的，维护 UML比维护代码的成本都高），其实和架构设计鸟关系没有。而平时我们看那么多《道德经 》的研究，这里6个考古版本，那里“道可道”的五种断句，用描述来解释描述，就算雕出花 了，它和“治国”和“战略设计”这件事情也全无关系啊，当然也是越用力越远了。
这说明什么呢？只有这个世界，才是我们思维的助力。没有现实世界，我们的通讯可能完 全就是噪声的传递（好比本文的架构设计和道德经的例子）。因为我们的目的永远都是改 造这个世界，顺着它也不过是决定我们可以改造的范围，不是要完全顺着他（否则就是死 了）。“我”存在的价值（形成名），恰恰就是“我”不顺着世界的那个部分，所以才有了“我 ”的存在。如果我存在和不存在都对这个世界没有影响，我们的概念中怎么会有“我”呢？
由此知之，“很有道理”通常是个思维陷阱，因为你的思维，和对方的思维完全一致，不是 你是死的，就是他是死的。我们看一个理论，学习一个理论，其实关键不是它自己有没有 道理，而是它怎么改变这个世界，否则你就会被“很有道理”的一个“学”囚禁起来，而你会 觉得自己“挺有道理”的。