.. Kenneth Lee 版权所有 2019-2020
:Authors: Kenneth Lee :Version: 1.0
一个例子：名的边界效应
举自己身边的例子说明问题，总是很容易涉及到个人的问题，需要进行改编，改编以后效 果就打折扣，所以很多问题都不容易讨论清楚。今天看到一个实际的，可以公开讨论例子 ，我借来比喻性地讨论架构决策中名的边界效应问题，由于知乎上的人都是虚拟身份，预 计也不会对谁造成实质的伤害，这个讨论仅仅是针对这个事情，希望我们讨论的时候也不 去讨论具体的人的问题。
前两天回答了这样一个问题：用 VS Code 替代 Vim 可行吗？。我给出的论断是：“Vim做 了足够有用的功能，这些功能只有长期编程的工程师才能体会，所以VSC等工具长期有新东 西出来，但永远取代不了Vim和Emacs。”
这个论断不是题主的关注点，题主的关注点其实是：“我到底应该选择什么编辑器作为我的 主编译器”。但我觉得我给了他一个直接的理由：“长期编程的人优选Vim和Emacs”。所以， 我确实在这个问题上提供了帮助。至于题主最终决策是否采纳这个观点，这要综合他的场 景才能给出结论，比如他需要考虑“我是否长期编程？”，“那些说长期编程的人优选Vim和 Emacs是否可信？他是否真的长期编程？他说的‘长期编程’是否仅在他们Unix程序员的范围 内？”，“我的环境中有没有vim？”，“那些人说的vim到底是vim还是某些编辑器的vim模式 ？”……
这些问题，其实就是架构师每天面对的问题。你要做的只是一个选择，但信息是无限而且
有置信度的，何况你还有“未知”的问题。你要选择把什么放进你的逻辑链中，然后进行投
资选择。所以我们做架构设计的人，很在乎“道纪”（:doc:道纪 ），我们不是特别关心
结论，我们关心结论之前的信息，因为只要你多提供一个信息给我，我的结论随时可以反
过来。我今天还和人讨论了一个驱动和驱动框架的关系问题：为了获得连续物理内存，到
底应该框架通过alloc_pages()分配内存还是驱动通过dma_alloc_coherent()分配内存，驱
动的兄弟说应该是后者，因为前者有MAX_ORDER的限制，最大不能分配超过2M的内存。我反
对，因为物理连续是框架承诺的，不是驱动承诺的，如果让驱动做这个事情，框架就变成
二传手，这是架构设计要极力反对的。我们的结论是应该框架分配。但我又分析了一下框
架的最初承诺，这个承诺是源于框架可以控制iommu的，既然你都用到连续内存了，说明你
根本不用iommu，那么框架其实不该做这个承诺，应该作为驱动的一个“特例”来出来。但这
个“特例”又需要在其他地方得到框架的支持……最终我们的结论是，我们应该让框架使用cma
来分配连续内存，而不是让设备透过dma api来使用cma来得到连续内存（而cma本身要作为
一个没有iommu的特例来使用，限制其应用范围，要加上tainted kernel标记）……
这就是架构设计的日常，我们讨论的东西都不能用来运行（要运行我几个月前就可以运行 了，但这样玩后面加不了代码和特性而已），只能是在脑子里过，为了保证可靠性，我们 基本上尽讨论些“名分”，“承诺”这样的鬼东西，但做大系统：仅仅能跑是远远不够的）
但我们今天不讨论这个“道纪”的问题。我们讨论我们如何接纳和取信新的信息。所以我们 回到最初的问题。如果我们作为架构师，要对我们是否使用vim这个问题进行推演，我们应 该如何关注获得的新信息？
回到前面的例子。在我给出了我的观点后，有人这样讨论：
| 我也喜欢VIM，熟练使用几乎现有的所有插件，但是我不极端，
| 很多时候ide要做的事情vim永远做不到，深知这一点后，
| 再看到任何极端把vim说成咋么样的人，我都当他**。
| 不知道答主是不是一样
我们来把这些新的信息整理到我们最初的逻辑链：
.. figure:: _static/vim逻辑链1.jpg
这个人其实挺不友善的，但我们在乎结论（至少表面上得如此吧），所以，我们不能被情 绪左右，我们得在逻辑链上给证据。所以，到此为止，我们仍在讨论的逻辑链上，问题仍 值得讨论。所以我的证据是这样的：
| 我也喜欢VIM，但我根本不熟悉各种插件，我只是当过网络设备操作系统首席，
| Android STB软件首席，ARM服务器的软件栈的首席，完整写了里面的独立模块，
| 全局分析过系统性能，从用户态，内核态到Hypervisor到UEFI各种软件修改都
| 进行决策，都只用VIM……可能这就是我们的区别。你不过是个工具玩家，根本
| 就不是用家。
其实，我也是挺不友善的，但还是那句话，我们还是冷冰冰看逻辑链：
.. figure:: _static/vim逻辑链2.jpg
我的逻辑其实不好，更优的逻辑其实是出来一个统计：有多少工程师，资深工程师占比是 多少，编辑工具的使用分布如何等等。但这个信息我没有。
还有，我没有给出更多的可验证信息，比如：我的身份证明。
但我没有或者不能提供这些信息，我给的信息到此为止，是否采信，就看使用者是否能拿 到更加Solid的信息了。
但有一点，我仍在指向原来目标的逻辑链上。
然后对方这样说：
| 是啊，你也是vim的使用者而已，vim有很多好用的插件，
| 没有这些插件的配合vim会失去不少色彩，vim在github上
| 也经常感谢这些插件的开发者对吧？你没用过任何插件真
| 的很遗憾，连一个自动补全，自动语法检查都不用是不是
| 真的很影响生产里呢？可能您是人肉编译器吧。再者，
| vim才真正只是一个工具而已对吧？现在很多ide本身就是
| 完美支持vim模式的，你既然不用插件，那你应该喜欢的是
| vim的各种快捷键吧，起码我是咯，那些不就是vim的升华
| 了吗？既有ide的强大，又有vim的爽快。在服务器ssh的时
| 候毕竟也只是修改某些部分的时候对吧，毕竟开发机和本
| 地才是我们写代码的地方。
|
| 其次，没有人质疑你的资历哦，你说的这些用文本编辑器
| 其实也可以呀。和讨论vim有什么关系呢。再者，我并无恶
| 意，您何必来势汹汹的说一堆你做的什么？
| 什么工具者？什么用家？工具者不是用vim的用家？您给
| vim贡献了什么吗？对vim的某个模式做了优化？你不过也
| 只是这个工具的使用者罢了。
我仍把逻辑链整理上去：
.. figure:: _static/vim逻辑链3.jpg
你看，到这里为止，这个讨论已经偏离了原来的逻辑链条，变成了对“我们间，谁可以成为 做这个结论的‘代理’！”
我以前分享过亚马逊CEO的一段讲话：
:doc:`../道德经直译/阶段小结：食母`
其中就提到过“代理”这个概念，代理其实就是道德经的名。我们开始在讨论“选”什么，向 前建证据链，就会产生代理。我们通过打破前置证据来证明后面的不成立。但最终最容易 陷入的陷阱就是“身份”的问题：到底是我有权做这个判断，还是你有权做这个判断？
但这样最终就离开逻辑链了。
这就是《道德经》中说，大曰逝，逝曰远，远曰反的意思。我们用代理来代替原本的东西 ，代理越多，结论就反了。
要避免掉入这个陷阱，我们尽量不把人本身放进来。我知道装逼自己是资深工程师对我有 利，还知道说出自己是资深工程师会让人认为装逼而对我不利。这些考量，偏左也不好， 偏右也不好，干脆从逻辑链中删除，回到逻辑链条上，看什么证据可以支持逻辑链。
这就叫君子与其练达，不若朴鲁，与其曲谨，不若疏狂。想太多，就忘掉本来要干那个事 情啦。而离开那个事情，你什么都不是。
所以，我们做事情，做架构，都是这个问题，你的决策在事情上，事实成了你要的那个样 子，你怎么都亏不了（无论名上如何表现），但总落在名上……算了，说多了没啥意义。
最后说一句，请不要讨论人。我对该讨论的参与者没有任何恶意。因为不但他会这样，我 受到冒犯的时候也会这样。我只是想说明我们平时评审设计文档时候的困难。因为每次质 疑设计不对的时候，最后就变成“我没错”的解释，我只是想找一个例子告诉我们的工程师 ，不要对自己的“身份”想太多——我甚至不是说不要想，我只是说，你保护完你的尊严了， 没有人说你本人有问题了，能否把眼光重新放到问题上？