.. Kenneth Lee 版权所有 2022
:Authors: Kenneth Lee :Version: 1.0 :Date: 2022-02-24 :Status: Draft
天网恢恢
前几天和别人讨论设计的原理的问题，这里作一个总结。
我认为，设计的本质是建模，而建模的本质是创建“逻辑闭包”。
为什么呢？因为如果代码（或者更广义来说是“实现”）是我们的目的，设计就是在没有达 到目标前抽取部分“要素”进行“因果”的逻辑判断：因为我们目标手机是Android或者iOS的 ，所以，我们需要实现Android或者iOS两个版本。因为两者都支持JS Rendering UI，所以 我们的程序的UI可以统一使用JS来绘制。因为我们要用户根据我们的问题反馈答案，所以 UI上必须同时显示问题的Decoration和回答用的Panel，两者要共用一个线程，所以两者的 事件处理不能超过10ms。因为回答用的Panel需要根据回答的阶段需要显示成不同的样子， 所以我们的状态机变迁必须是……这些判断都没有代码细节在其中，但如果我们直接写代码 ，我们都不知道第一步迈向哪里。
所以，这些高层判断和选择是必要的，如果我们跳过了这个判断，眼睛只看见代码，我们 就控制不了整个代码的发展。也许你认为你的代码中包含了，线程模型，状态机，UI分类 所有这些逻辑，但你的脑子里面没有，你脑子对着这些代码，是不知道状态机是否能自恰 的。
所以，只要是个设计，就是建模，就是一个“模型”，一个丢失了细节的泥胚，一个尝试在 某个角度模拟目标系统的Digital Twins，我们不是要得到这个泥胚，我们是要得到最后 的那个系统。那么我们就不能关心模型自己的细节，我们需要聚焦到模型模拟的那些逻辑 自身的逻辑判断上，所以它必须是个逻辑闭包。一个模型本身能运行得性能很高，功能很 正确，这毫无意义，因为我们又不用这个模型。所以，把模型当作黑盒，谈这个黑盒的外 在特性，毫无意义。比如，你用Gem5（一个时间精确的模拟器）模拟一个CPU，优化它，说 它的性能提高了30%，这没有意义。作为模型，我们关心这个东西实施到真实的CPU上的时 候，它的性能真的能提高30%，而不是Gem5提高30%。所以，你要建模就得打开它，分析清 楚你模拟了什么CPU的执行行为，对比原来的总线协议，你换上了你新的总线Ordering算法 ，在这批业务流上性能确实提高了30%。这就有参考价值了。
作为逻辑闭包，我们关心的一直是逻辑本身，而不是Digital Twins模拟这个逻辑的时候不 得不用到的那些细节引起的边际效应。
再举一个例子。我有一段时间做操作系统，有些子团队经常拿他们性能数据出来说他们实现 的线程接口，锁接口性能比对手提升了多少。这些我都不当回事的，因为事实最终常常证明， 这些“优化”只要正式用起来，都会因为补上了安全保护，异常流程处理，泄漏资源跟踪释放， 可调试性，可测试性，可靠性保护而重新掉下来。你要找到性能提升的机会，就要找到对比 对手不同的“逻辑”，比如他必须保护某个功能，而这个功能你有手段可以保证它不需要做。 这样，大家补上细节的时候你才能有优势。否则你只是在模型的边界效应上取得优势而已， 目标上你是没有优势的。
从这个角度就能理解《道德经》中“天网恢恢，疏而不失”的含义了：每个独立的逻辑，只 要你分析合理，这个逻辑都是不能违背的。所以，每个简单的高层逻辑，虽然很抽象，但 它就是不可违背的。UI用一个线程处理，如果单个事件处理的时间太长，UI就是会失去响 应。虽然这个设计要求很简单，很抽象，但只要你不遵守，你最终的UI就是会不流畅。你 一开始就把代码写成Java的，它就是只能在Android上运行，不能在iOS上运行。每个粗疏 的逻辑，最终都是会发生的。我们进行高层设计，无论是不是软件的，每个设计，虽然不 包含细节，但其实都真的可以起保护最终目标的作用的。但它真正的敌人，其实是大部分 人对这种“尚未发生的，在能在头脑中运行的逻辑”无法保持信心，在下一层细节中遇到障 碍了，工作中遇到工作量的问题，都忍不住故意掩耳盗铃，有意无意当作看不见。
但看不见，天网一样地罩下来，该死还是死。死了，你连原因都不会知道，因为逻辑是人 脑中的东西，包含所有细节的天地里并不存在。