仓库源文

:Authors: Kenneth Lee :Version: 1.0

弱者道之用——谈技术工作中的守弱问题

本文从那个性能分析的系列中暂时抽出来一下，发表一下感想，谈谈技术团队的互相协助问题。

道德经的模型我在这里总结抽象过一次：老子哲学思想的精髓是什么？ - in nek 的回答。那里是从类似“哲学”思考这个角度来总结的。这里我再从工作实践的角度来抽象一次。

“名”是个非常强大的东西，它不但用于交流，还用于思考，它直接影响你的决策模型。但名并不是事实，我们很容易会被名掩盖了对事实的认识和判断。

人的思考除了有“名”这个缺陷，其实还有“实时性”这个缺陷，很多东西轮不到你面面俱到地进行穷举，所以我们才有“守”这个概念。“守”的意思，是说，你在决策的最后一刻，你能使用的最后几个逻辑要素。

你把什么作为你瞬时决策的依据？

这个在战略阶段你的决策和在战术阶段你的决策依据是不同的。比如你要从城东家里到城西，在家里研究地图的时候，可能你的判断是出门先往东，然后在2公里处掉头，再往西直达目的地。这个分析作为你出门以后守的一个条件，就是“出门后一定不能直接往西，要先去东边的绕过西边的屏障以后才往西”。

而你不研究地图就出门，很可能你出来就直接奔西边去（这时你守的只有方向），结果发现前面是个工地，你根本走不过去，你就只能回头，可能走更长的路才能到达目的地，甚至到不了目的地。

但如果你研究了地图，但你出门的时候往东的路在堵车，你又知道往西的路修通的可能性接近0，你就可能可以考虑往北去，辗转走到掉头的路口，继续向西去。我们解决具体的问题总是在战术上，战术最大。但如果你事前可以准备，战略可以为战术提供无与伦比的帮助。人的思考深度，比的正是你可以在视觉上拉高多少来看整个问题的逻辑。

这就是战略的作用。战略“守”的东西，和“战术”守的东西是不一样的。战略是经过一些研究，把一些在战术中要“守”的东西贯彻给战术，加大战术成功的筹码。

这种东西在工作中无处不在。我们写完设计文档就要Review，Review的目的是别人给你提意见，你想避免犯错误。但直觉上我们听到意见又会很不爽。如果在战略上考虑过这个问题，你就会在Review中就守一个原则“意见其实是越多越好，别人是来帮我的”，但如果如果你顺应自己的眼前观感，你就会本能拒绝别人给你的Review意见，当作是一种挑事了。

这就是为什么反者道之动。因为构架决策基本上都是和战术相反的，如果战术层面就能搞定的东西，根本不需要构架决策干什么事。你在家里研究去城西的战略，会加入“走人行道 ”这一条吗？不会，因为那是战术层面的东西，根本不需要你去“守”。那是你在战术阶段本来就会守的东西，浪费在战略阶段毫无意义。

道德经是帝王之术（不是小人眼中那种只想荣华富贵，妻妾成群，驾驭下属，得点个人小便宜的所谓的“帝王之术”，而是真正把要成事的领导者的艺术），它的战略决策思路是，无论你想干什么，首先的工作是让布朗运动变成有向运动。因为我们首先要承认，“我”，个人在成事上几乎作用可以忽略。就算你当了总裁，当了皇帝，你让你手下的员工都不要领工资，让身边的大臣统统自杀，你看看行不行？集体是个平衡系统，力量在集体本身上，而不是在你个人身上。你做的是系统的平衡，不是取代集体去努力。集体中的每个个体都有一个动力，他们互相作用，变成“热”（布朗运动就是热），而你的工作是把热能变成动能，把这个集体移动到你想他们去的那个位置上。

而要让集体形成力量，他们必须能够匹配起来，我们看看这副图：

    .. figure:: _static/守弱3.png

如果人和人之间都是这种突出的形状，他们是不可能匹配的，你得让不同的性格，不同目标的人在一定的外力下，匹配在一起，像这样：

    .. figure:: _static/守弱4.png

很多时候，其实这样也是不够的，因为这表面看来匹配了，但看他们的细节，他们仍是有分歧的，比如这样：

    .. figure:: _static/守弱5.png

这就是为什么我们和人沟通，不熟的时候还是好朋友，住到一起就成了仇敌了。或者某人是总统候选人的时候你很喜欢他，当了总统你就恨他了。

细节需要打磨才能最后匹配。一个集体要实现非布朗运动，就要通过一定的动力，把非主目标的动力分量平衡掉，剩下进步的动力。圣人的工作，不是提供集体前进的动力，而是提供让细节匹配的力量。进步的动力是集体本身的，不是圣人的。这就是无为。不提供集体前进的动力就是无为。所以构架师的工作不是写代码，而是让大家可以好好写代码和进行配合，实现系统的成功，如果构架师把“写代码”作为“守”的目标，这个架构师就离开进行战略引路的工作职责了。

好了，现在我们再理解一下为什么要不争。圣人需要为天下溪，为集体积累一点一滴的力量，把集体的力量释放出来，变成洪水，如果圣人自己就去和个体的力量对抗，这个集体哪里有什么力量？真正的圣人，是要让这个集体中的每个个体在目标方向去张牙舞爪，在偏离的力量上让他们互相平衡，实现匹配，类似这样：

    .. figure:: _static/守弱6.png

如果圣人跑出来秀存在感，就成这样了：

    .. figure:: _static/守弱7.png

这就变成新一轮的布朗运动，只是产生热，目标就不可能达成的。所以，君子不欲碌碌如玉，不求落落如石。

这是道德经整个战略的基础。理解这个基础，我们现在可以谈一下个人战略上的"守弱"。道德经说知其雄，守其雌，知其白，守其黑。这个策略的背后的考虑是什么呢？

我练形意拳的时候，有一个心法学会以后，经过一定练习，对整个技术水平有很大提升的，那就是：守中节。中节，对于整个手臂来说，就是前臂。我们无论防守还是攻击，手（拳头的位置）的距离是最长的，前臂相对来说更短。所以，我们下意识是守在稍节，就是手上，这就是守强，但我们不守强，我们守弱，解决问题的时候，总首先用前臂来进攻和防守，这个结果是，无论是进攻还是防守，手（拳头）永远都会突出去，都会成为对方的威胁。这就是守弱的作用，因为强就是强，强是不需要守的，强会自动发挥作用。强是已经解决的问题，守要守在还没有解决的问题上。你要去城西，别人没有自行车，你有，你要解决的问题是好好看路，骑这么快，会撞着人的，而不是老想着：我噻，我有自行车耶，看到没有？我有自行车耶……这于解决问题有何收益？忘掉强，守着弱，你就一直走在向前的路上，这就叫夫唯不居，所以不去。

这就是战略上的守弱原则。你爸是李刚，你吃个饭把李刚抬出来，上个厕所又把李刚抬出来，转眼李刚进去了，你也进去了。所以，我们取弱不取强，让弱变成强，这样你才是安全的。

我突然想起来谈这个，涉及到前一篇博文，那个Cache Invalidation引起的性能下降的问题，我和相关硬件的设计人员交流过多次，发现他们经常很容易守强，他们总是说，"这个东西表现出来就是巴拉巴拉，其他东西你不用管"，其实根本就不是不用管，因为在那个模型中，他们根本就保证不了性能，如果软件不考虑他们的这个要素，他们根本就保证不了性能输出。他们坚持（守）在不能作为可靠依靠的"外面"，而不是他们真正有信心的"里面 "。这样整个交流就失败了。其实不光做硬件的人会这样，很多软件工程师，也会把自己的一亩三分地看得非常神圣，在外面加上一层厚厚的保护壳，抽象一个非常粗糙的外部接口，希望把自己保护在里面，这样是实现不了团结和竞争力的。很多人守强，也是因为对自己缺乏自信，不想漏怯。所以拼命用各种自己没有信心的概念来“武装”自己，让自己看起来很强大，却不知道自己最强大的正是你自己看起来最弱的部分。我不懂Linux的 driver-bus-device模型，但我确切知道我写driver的probe函数的时候是有人传给我一个 struct device来知会我中断和IO的位置在哪里的。这一点上我有坚定的信心。这就是守弱。我对driver-bus-device模型有粗浅的认识，这个可以作为我讨论的基础，但我在别人的有道理的意见上不会刻意坚持（特别是不会为了面子而坚持），因为我真正的信心是建立在“我写过一个能正常工作的Sensor驱动”这样的东西上的。这就叫守弱。

守弱的工程师，应该形成这样另一个沟通结构：

    .. figure:: _static/守弱8.png

看见没有，我们的整个设计有确切不可更改的部分，有不可退让的原则（黑色部分），也有柔软的部分，我们要坚守在后面的部分，而不是非可相信的部分，这就是守弱，我们守弱了，才后可能真正知道如何合作才是最好的，如果我们一方守强，守弱一方才控制整个合作的主动，所以强者死之徒，弱者生之徒，这还是有可能合作的。但如果两方都强，就没有合作的机会了：

    .. figure:: _static/守弱9.png

生之徒的工程师坚持的是不可变更的"弱"的一部分，外在表现是柔软的，所以他们才能和人配合，找到可以和对方合作的细节，形成坚不可摧的力量（集体的力量），我们每个工程师，如果有心要取得很大的进展，就需要学习圣人之道，学会借用集体的力量。

也就是，虚心实腹。你做一个中断控制器，就老老实实说你会遇到上升沿会如何，遇到下降沿会如何，多高频率的抖动会过滤，之后怎么报到总线上，怎么设置VMID让CPU知道是哪个虚拟机的中断。你不要自以为是地给软件抽象为：“我会通知你的虚拟机的，不用担心” 。担你个头，我虚拟机什么意思估计你都不知道（因为每个平台的虚拟机方案在硬件设计阶段，它的概念还在设计阶段，硬件是不可能知道软件概念中的“虚拟机”到底是指什么的，比如你把ARMSecureFW看作虚拟机或者虚拟机调度器的一部分吗？），什么叫“通知虚拟机”你更不知道。你守在你根本就搞不清楚的概念上，那整个合作就变得非常粗糙，从而也失去力量了。

我经常说软件工程师应该好好学习一下《哈利波特》，因为哈利波特能在复杂的逻辑中找到出路，是因为哈利波特的思考方式就是很典型的守弱思维。比如说，他要办DA的时候，要找一个地方和其他同学一起练习魔法，向多比求助的时候他怎么描述的？“我需要一个地方，能让28个人练习黑魔法防御术而不被老师们发现，尤其是‘乌姆里奇教授’”。看见没有，这才是“原始需求”，而我们更多工程师如果描述这个需求，他们会描述为“我需要一个房子，100平方米，有软垫，有洗手间，有……”。如果你这样描述，多比就不会提供“Room of Requirement”了。我们很多技术讨论中，工程师就是被那种看似专业，实际被自己的误解带偏，最后还要被自己的面子锁死的错误观点所左右，最终让整个沟通和合作失效的。

其实，我这里说的“弱”，只是看起来的弱。从置信度和坚强度上来说，这个弱其实是一个强。我们很多工程师（中国工程师尤甚，欧美，乃至印度的工程师都比我们好）写技术文档，特别喜欢用大而不当的概念来包装自己的设计。比如，“本设备支持流表Offloading，流表格式如下……”。我每次看到这种描述就发毛：什么叫“流”？什么是流表Offloading？在很多评审会议上，常常只有我才会问这种不合时宜的问题：什么叫流？然后整个会议室的人看着我，用同情的态度来说：“Kenneth老大，下来我们给你解释一下”。我说“不用，你们给我一句话的定义，什么是‘流’？”。然后，你会发现，其实没有一个人对“流”有清晰的定义，他们说，“流啊，就是流啊，就是那些Socket啊什么的……”。最后大家就会发现，其实我们都不知道流是什么，却为流offloading谈得不亦乐乎。这种情况，我会先给一个我的定义：“流是具有相同数据特征的，流过（发送或者接收）本网络设备的一组包的有序序列”。然后有人开始说，“对，差不多，不过发和收我们是看作不同的流的……”，OK，那我修正如下：“流是具有相同数据特征的，单向的，流过本网络设备的一组数据包的有序序列" ，好了，现在没有反对意见了吧？那我提出第二个问题：“我们的NIC可以匹配那些特征？支持哪些调度目标？”……这种讨论和思维模式就叫守弱。其实这个弱是非常强的，因为我们的基础非常坚实，看起来定义一些非常显浅的，直白的，基础的东西，但以这个为基础抽象的高层概念非常坚实。但如果你没有这样的基础概念，所有看起来的“强”不过是海市蜃楼。我们很多人看不起自己实实在在做的东西。比如NIC的设计师其实肯定是知道他如何处理每个特定的包的，但他们觉得那个东西不够高大上，非要封装很高级的，自己其实没有把握的概念，其他人看到这样的概念，自己其实也不懂，但又不好意思显得自己太蠢，也不敢问，结果就是大家都在一个糊糊涂涂的讨论中，形成一些不可依赖的意见。结果就是战略阶段一事无成，战术阶段修修补补。不少中国工程师觉得架构没有什么用，其实道理也在这里，他们不懂守弱，就不会懂怎么做架构设计，从而也就体会不到架构能给他们带来的强大的力量了。

守弱的思维策略，是我们真切认识世界，构建有效战略逻辑的开始（战略逻辑自由度极高，评判只能在战术阶段，所以，是否有效时战略逻辑的唯一评判标准，这个靠看样子是看不出来的），不但可以用于工程师，也可以用于任何行业，不但可以用于集体，也可以用于个人，我们对世界的认识，坚固的逻辑要落在不可退让的事实上，而不是落在抽象的概念上。这就是虚心实腹或者守弱。