.. Kenneth Lee 版权所有 2019-2020
:Authors: Kenneth Lee :Version: 1.0
常无欲以观其妙，常有欲以观其缴
今天评审一个技术分析文档。有些复杂的公共逻辑需要解释一下才能说明我的意见，我把 公共部分的逻辑写在这里。
提到的这个技术分析文档，主要有两个问题（这两个问题是一个问题，后面我们就会看到 ）：
写得面面俱到，表面上看不到破绽（但有一个只有我这类要用这东西的人才会注意的破 绽，我们一会儿再说）
技术分析一上来就直入细节，缺乏完整的数据流模型
这个技术文档是在我们的硬件上支持某种软件协议栈的加速的，按惯例，我换一个完全不 相干的技术来作为例子：比方说，我们要在一款新的计算机上支持uboot（一种初始化软件 ，用于启动真正的操作系统）。你要分析要让uboot这个软件支持你的计算机需要做多少工 作。你的目标就的是“分析支持我的计算机需要做的所有工作”，而不是“uboot入门”，或者 “uboot的网卡驱动入口在哪里”，“探讨uboot的具体实现”这种东西。
但我能猜到为什么目标会写成那样，因为作者没有分析完，他不敢戴这么高一个帽子，但 这样的结果是他后面的目标确实就没有聚焦到这个目标上，既少了东西，也多了东西。我 不反对少了东西（你可以写todo，也可以写“这部分没有分析”），也不反对多了东西（你 可以放到附录中，以后再用），但你不能离开目标。离开目标我们做这一切的事情图个啥 ？
这种行为其实更多是照顾自己的面子，而忘掉了我们要解决的问题本身。也是一种失败者 策略（“赢不赢我不知道，我先保证输的时候不要被人骂得太狠”）。
关键是这个方向错了，我也没法帮你，因为你一切都“圆满”了，面面俱到了，我明明知道 uboot的中断处理构架不能处理我们挂在PCIE接口上的硬盘的，但你根本就不提这摊子事， 还用一层层其他的逻辑把这个问题隔离在外了，我怎么帮你？
这就是我以前说过的，一个设计文档如果面面俱到，通常是有问题的。面面俱到的是科普 读物，不是技术设计，技术设计没理由面面俱到的
第二个问题是一样的，你谈uboot支持，最高层的数据模型是：输入我的计算机的特征描述 文件（比如devtree）和一个定制的uboot（包括我需要的驱动），最终实现从我的EPROM中 读出操作系统映像和用户指定的启动参数，启动操作系统。
有了这个全集，我们再谈我们计算机的入口向量在哪个地址上，uboot怎么放到这个地址上 （或者桥接到这个地址上），然后是怎么启动每个驱动，怎么找到EPROM等等。
你不定义那个全集，上来就给我谈细节（细节是无限的呀，你要不要把所有代码每行都来 谈一遍？不够的话，你要不要再来谈谈C99不够先进影响你启动过程的语义表达，先优化一 波gcc？），看起来好像在解决问题，我根本不知道你这个问题的规模有多大，重点应该放 在哪里，在有限的时间内能否完成，我怎么确定策略？或者说你自己怎么确定后面的开发 策略？我们是否可以陷在细节中不出来。
这是很多技术文档的问题，如果你不是对着马上就要安排人力解决问题去，你还会觉得这 文档写的洋洋洒洒，有条有理，挺好的——其实没法用。
好了，下面是一个关于《道德经》问题的扩展，我原版本接下来是这样写的：
| 这又是个《道德经》的“有无”问题了。《道德经》说“常有，欲以观其妙；
| 常无，欲以观其徼”总结的就是这个问题：我们怎么会注意到“有”这个概
| 念的？因为我们遇到了一个问题（例如我们这里谈到的uboot），然后我们
| 就被吸引过去了，我们开始研究它的细节，研究它的外延，越研究越多，
| 我们就完全迷失在这个名字中了。所以“有”，来自“妙”（也许是指
| Interesting，有趣，有利益的东西，也许指“小”，你细看下去的东西），
| 而“无”，来自我们要考察整个问题的规模，在我们进入“小”之前，
| 我们得看到大，看到大，我们看到了全集（这个问题的边界），
| 看到了我们的知道，和不知道部分的边界，这样这个问题该如何解决，
| 我们就知道了（至少是有底了）。所以“无”同样是一个“有”，
| 一个不同特点的“有”，一个我们不知道它的“细节”的“有”。
| 我们用这个“有”，去规定了整个问题或者我们在乎的东西和不在乎的东西，
| 已知的东西或者未知的东西之间的边界。我们很多时候，解决不了问题，
| 是因为我们总是关注“有”，不去关注“无”的部分。要改变这种情况，
| 我们需要守稳我们的目标，而不是关注我们自己“有没有面子”，
| “说得对不对”，或者总安慰自己“完成任务就行，怎么做有其他人关注”。
上面这个版本发出来后，有读者提醒我这个引用是错的，因为《道德经》的原文是：常无 欲以观其妙，常有欲以观其缴。是“无，才观其妙”，“有”才“观其徼”。
我犯这个错误不止一次了，因为我能感受到的意思其实就是最初表达的意思。但如果非要 圆，也是可以得，只要把关注点改一下（因为有无本来就是同出而异名，他们效果是一样 的，只是看你关注点是啥），这也能解释。但我不愿意那样解释再一次，因为我的直接感 受不是那样的。简单说，我不知道原文作者本来是啥意思，但不管是他是哪个意思，我看 到的上下文和直接的理解其实是上面这个理解。
所以，我尝试留下那个版本，以及说明这个问题的文字。这样才表示我本来想表达的意思 。
这也是想说明那一堆“守弱”，“心如赤子”和“聚焦目标”之类的概念的本来意思——我说得对 不对是不重要的，我们互相知道对方在说什么才是重要的。东西说错了，如果我们都知道 对方在说什么，我们这个信息传递过去，这才是我们交流的本心。我不需要把自己封装为 一个“圣人”，然后我说什么都是对的，我（在交流中）只是制造这个“徼”（名字突出来， 左右本身无所谓），让这个要沟通的“名”被吐出来，而不是被“我是圣人”这个名包住，我 们的沟通就成功了。
同样，我们写设计文档，我们在乎的是我们对外传递的是“uboot如何支持我的计算机”这个 名，而不是“我完成了领导交给我的任务”这个名，这个设计文档才是成功的。