仓库源文

.. Kenneth Lee 版权所有 2017-2020

:Authors: Kenneth Lee :Version: 1.0

“病病”


这篇博文延续这个讨论:概要设计不是代码。但为了进行那个讨论,我需要拉起很多其他 概念,所以,把这一篇作为这个专栏的一个补充说明来看吧。

前面写过一篇关于知不知上的:知不知上——控制调查范围,那里只谈了“知”这个问题,没 有谈“病”这个问题。这个星期看一本据说还比较著名的关于中国思想史的书,发现里面的 逻辑实在不能令人信服,我相信这个作者应该是看过很多书的,但我想他们实在是没有做 过事,求礼的意识实在太重,他们认知的事实,和我认知的事实相差得太远(我不是说谁 比谁差,我是说两个有距离,不一致),我都不能明白他们怎么会认为古人会那样认知事 实的。这个事情令我想到,人如果一直工作在“学”,或者说“道理”上,无论是多么专注和 努力,真的是非常危险的。研究思想史,比起研究“历史”,加倍的危险,因为历史我们还 有认知的事实,比如挖出来的墓,经济统计数据,哪怕是史家的一家之言,都是“事实”, 但思想,一个人怎么看待一个问题,你不和他做的事联系起来,你根本不可能知道他什么 意思。这样的研究,穷经皓首,可能到头来还是什么都没有。

病病这个问题也很像,看一些道德经解读的书,大部分把这一段问题解释成人要“谦虚”, 这种解释,说起来“很有道理”,其实如果你还是从“做事”这个角度来,你就会发现,这其 实是“求礼”,“谦虚”针对的是个人的属性,不是事实本身。别人说你这个饭做得挺好吃的 ,你说“哪里哪里”,你明明做得比大部分人做的好吃,你认为“哪里哪里”,针对事实来说 ,这就是错误。你说“哪里哪里”来对人表现“谦虚”,这个对事情没有伤害,但你用“哪里哪 里”来做针对执行的逻辑判断,你就错了。比如明天晚上要招待重要客人,几个人里面你去 做饭是最优选择,你“哪里哪里”了,上去一个做饭不好吃的,导致明天晚上的的生意谈崩 了,这个“谦虚”就是一个错误了。

我前面谈“守弱”其实也始终是这么一个问题,我们要针对事实“对”,不是要针对“道理”“对 ”,不是“有道理”,是“解决问题”,如果我们始终在“名”和“学”上旋转徘徊,我们就一直无 法讨论问题本身。

《中庸》里其实也有类似的说法:天下国家可均也,爵禄可辞也,白刃可蹈也,中庸不可 能也。再难的事情都可以做出来,但做“对”就难了。能慎独,不被外人的看法所左右,这 才是《大学》之道。

病病本身也是一种守弱,病病不是谦虚。我们要解决一个问题,需要知道一个事实,我们 不知道这个事实,这是“病”。我们明明不知道这个事实,却基于一个不存在的“事实”作为 我们战略判断的基础,这个战略就很危险(病)了。所以,要想“不病”,就要知道自己不 知道什么(病病)。这样,你的战略总是依赖“知”,而不是依赖“不知”,这样你的战略执 行就可以“不病”。这才是“病病”的核心,这是可以指导成功的战略,而不是“道理”。为什 么它是可以指导成功的战略,这要用你的实际操作来证明,我不能在这里用“道理”来给你 证明。

说明白这个问题,我们才能谈那个概要设计的问题,我发现不少人(我不是指知乎的读者 ,而是我写的目标读者(后面我会解释这一点)),还是会认为:我还是要把代码写完了 ,才能把概要设计写好啊。你们注意到没有,你们的目的还是“写好概要设计”,而不是“解 决问题”,你总是这样思考问题,我们就无法谈下去了。

为什么要做概要设计?因为不构思直接进入代码折损率确实很高啊。比如你写一个基于UDP 的Server,你一开始总要计较你打算支持多少用户,请求量有多大,然后你要预判一下你 用单核还是多核才能处理这个请求,整个请求的瓶颈在哪里,所以你要在哪里开始把请求 的业务流Hash开,用线程,进程还是epolling对用户进行分隔……你有这个准备了,你才能 开始组织函数和模块啊。

你不能说,“我连Socket编程都不熟呢,哪有空想你这些问题?我先把Socket打通了再说吧 。”你Socket不熟这个事情我没有意见(这是“病病”),所以我才说你概要设计的时候没有 必要陷入“完美”这个误区。但你没有从“数据逻辑”上先想清楚你最后要的是什么,你去研 究Socket怎么用也控制不了投资啊。到你写得越来越多的时候,发现你用的每个Socket Folk一个进程的方式根本支撑不了你的用户量,你的代码再来改?当所有的细节都已经依 附上去的时候,伤害已经造成了,这个代码如何维护下去?

最近我们还在定位一个问题,我们有一个IP,启动SMMU(设备通过SMMU翻译来访问内存) 后就没有响应了,这玩意儿已经变成芯片的一部分了,本来也能跑得好好的,但设计的时 候没有考虑可调试性,反正现在软件怎么动作都没有反应,现在设备到底在什么状态也不 知道,你说怎么查?

有段时间还评审了一个设计,方案是让Linux内核调度器同时调度外设上的线程,这个方案 ,不可能被Linux主线接受,那你卖一个私有版本的Linux吗?如果不是,你就不能选这个 方向,这种判断,在推演阶段,不是顺理成章要进行判断的吗?你非要写完代码才来讨论 吗?

你觉得你写不出概要设计,或者要等到代码都写得才不多了,才能写出概要设计,说到底 ,你的心没在解决问题上,而是在“道理”上啊。信言不美,美言不信,好的概要设计不是 你想象那个完美的样子,但它是解决问题的啊。这个事情不难,但你追求“道理”完美,就 永远不可能走上正确的道路上啊。

就着这个主题,我在谈谈我在这里写的东西和针对它的讨论。我在这里写东西有两个原因 ,一个是,我每开始做一件事情,无论是设计,出差,解决家庭问题,我都会写一个“概要 设计”(也不一定是写出来,也可能是在脑子里过一遍),把这个事情的重心摆清楚了,把 要“守”的要点厘清了,我执行的时候就可以很自由,就可以凭直觉来做最快的决策。如果 这样的“设计”是通用的,没有什么私密可言的,我就愿意放在一个公共的地方,无论是好 的意见,还是坏的意见,它能提醒我有可能忘了什么东西。

另一个原因是,读者应该也注意到了,我思考很多问题的逻辑链都是很长的,这在面对面 讨论中很难说清楚,所以每个独立的“引理”,我都要解释半天,所以我通常会把这样的“引 理”写出来,这样在其他讨论的时候我会把这个地方的链接发一下就可以了。

所以,我这里的讨论是以“我所认知的事实”为准绳的,我在这里参与的讨论,我只讨论到“ 我想清楚了”,或者“我表述了我想表述的东西”,我就不谈了,对于某些讨论,我判断“这 个人的思路离我很远,没有什么帮助”,我就直接拉黑,这不一定是我不喜欢这个人,而是 我觉得这种交流没有意义,不想讨论了。

其实我原来是在单位内部写这些东西的,在那里的我的读者量远远超过在这里,所以有时 碰到其他部门的同事,别人会用这个来称赞我,说我的博文很有影响力。每次听到这种称 赞,我都极为不舒服,我会拉开去谈我最近的业务进展,或者在博文中得罪一批人,省得 成为焦点,因为对于一个做事的人来说,被人说“说得很好”,这很大程度上是种侮辱。

我想说的是,我这里的讨论,并不想有很多读者,也不想有很多赞,如果各位对某个观点 ,有想法,有你认知的事实,来参与讨论,无论是赞成还是反对,这是我最希望看到的。 我不一定会赞成你,但我们都表述到我们认知的事实上为止,这才是君子之交。

所以如果你觉得这里写的东西对你还有点参考价值,少点点赞,关注太高了,我就只好换 一个帐号玩了。

至于打赏,我现在基本上都会开,这有时打开看看,发现居然有几百块钱在里面,还是会 有点路边捡到钱的快感的。不过几百块钱不够我吃两顿饭,所以也没有什么意义,就是个 好玩,读者没有必要去特别在意它。

如果你也觉得我的思路或者认知的事实和你相差太远,我觉得你也应该考虑拉黑我,人没 有必要为其他人怎么想浪费自己对事实的探求,你说服不了全世界的人的,做好自己的事 情就好了。