.. Kenneth Lee 版权所有 2024
:Authors: Kenneth Lee :Version: 0.1 :Date: 2024-04-01 :Status: Draft
架构设计中猜的成分
之前总结架构设计的原理，总是强调了设计中谋划的关键要素部分。但很少强调设计中猜 的部分，本文补充这部分逻辑。
所谓谋划的部分，我经常用的例子是所谓出差：你要从深圳去一趟北京，必然先规划是坐 飞机还是做高铁，住酒店还是住朋友家，才去某规划如何出门，带多少衣服这些问题。
对应到开发，你必然先考虑业务需要多少线程才能支撑，分解多少模块，业务处理过程是 什么，然后才开始考虑某个函数怎么写。
这就是谋划部分，我之前的描述中对于有些写不出来的情况，认为是设计者经验不足。经 验不足就只能够先去一步步调研，包括写试探性的代码，对各种情况可以做的变化有了足 够的认识了，才决定如何进行设计。
但最近遇到一个例子，我发现这样归纳是不足的。最近在设计一个指令集的编码，我们第 一步把编码空间分成各多个子集，可以用于各种的应用场合。这确实是一种高层（架构） 设计了。但对于opcode有多长，支持寄存器有多少个。这个问题要从发展的眼光来看的， 这还只是一方面，更大的问题是，我们不在细节上先弄进去百来条指令，我们根本不知道 这个opcode的长度是否合理。
也就是说，你不做细节设计，你不可能做出正确的选择的，这种情况，还做不做设计？
我自然的反应当然是做，因为我做这个设计，是从需求来的，比如我们决定最大支持1000 条（种）指令，那么opcode就不可能少于10位，因为这样才能支持这么多指令。如果我们 要支持64个寄存器，寄存器下标就不可能低于6位。这些都是从需求开始引入的需求。细 节可能在特殊的地方改变这个结果，比如细节分析我们发现最终缺乏没法在某种分类的方 式下，实现所有功能的编码。但因为我们最初设定了这些逻辑，我们最终修改原来打算的 1000条指令，变成512条，这我们可以知道我们最终破坏了哪里。但如果你没有前面这个 假设（opcode必须10位以上），你那么多细节，组合在一起你知道细节推理过程出现障碍 了，你对最终目标的影响是什么吗？知道如何去权衡吗？
这样一想，我发现之前强调了太多的谋划的成分的，其实架构设计中“猜”的成分也是无处 不在的，因为高层设计确实没有碰过所有的细节（如果碰过所有的细节，你早写完代码了， 根本就不需要设计），所以高层设计的逻辑本身就是猜出来的，只是有些容易猜得很准， 有些没那么可靠而已。但无论如何，你都必须把这个猜的结果给出来，用这些结构去支撑 目标的成立。然后你才会知道，等你细节设计的时候，怎么都无法实现这个猜出来的规则 的时候，你要如何调整你的逻辑，让它重新成立。
这才是架构设计完整的故事，是我们做架构设计的常见情形。