.. Kenneth Lee 版权所有 2021
:Authors: Kenneth Lee :Version: 1.0 :Date: 2021-08-18 :Status: Draft
一些架构设计引导的例子
因为我总在公开的地方写架构设计的总结，所以常常有同事私下找我引导一下他们的架构 设计，我平时都根据具体的案例提取一些总结写在不同的文档中了。但现在我发现，有一 些特征不那么明显的案例，可能对一些人来说，也是很有帮助的。我们不能把难的东西提 炼出来，因为在实际中很多人反而是被一些我们觉得不难的问题给拖住了。我希望通过这 个文档，收集各种架构设计中有疑问的案例，供在架构设计上遇到困难的读者参考。
和其他案例一样，为了避免和实际的产品拉上关系。这里的案例我都故意转换了设计主题 ，但基本上和问题是可以在很精细的范围上贴合的。比如明明是一个NoSQL数据库的存储问 题，我会变换成一个Json文件的存储问题，问题会是一样的问题，但对应不到任何产品上 去，而且如果那个设计涉及高级的，有专利的算法，我也会把它替换掉。我们把重点放在 构架设计思考问题的模式上，不讨论每个具体技术本身。
有一位做测试的同事找我，他说他手上有一个python脚本，用来做各种电气化测试，大概 的意思是在PC上运行一个脚本，设置一组信号/电源发生器，经过一段时间的测试后，就从 各个传感器里面读数据，生成报告，然后评估这个被测系统的电气特性是否正常。
他说，他支持了很多很多的DUT（被测试设备），信号源和传感器，现在这个脚本已经很大 了，但不知道怎么优化这个脚本的架构。
上面其实只是我的一个总结，实际上这位同时尝试了几次，都没有能够说明这个脚本到底 是什么样的，最后只能把代码拿出来给我看。
首先，我认为，如果描述不清楚，那就不可能有架构。架构就是你对这个实现的总结，你 没法总结，就意味这逻辑是发散的，没法用一个可以描述清楚的方法来抽象它。所以，架构 设计最基本的方法就是用人话来总结你到底做了个或者将要做个啥。
但如果实在抽象不出来怎么办呢？那我们就承认我们没有架构，没有架构就直接线性写程 序，你不是有很多测试吗？每个测试一个目录，分别写脚本，这总可以吧。
你写了两个，有重复代码吗？有，就另外拉一个目录出来，但凡重复的，都写成一个公共 函数，这样至少就没有重复代码吧？等你这些函数之间共享的数据多了，我们就知道怎么 建一个class，建一个公共接口（比如用json描述你的测试报告）了，那时就有架构了。
架构最怕是你没有发现规律的时候强行制造一个规律，比如你非要认为你的测试过程一定 是：init->setup->start->collect_sensor->report这样一个过程，等到用于某个设备的 时候，每个发现都和这个规律不一致，你就只好在每个过程中对那个具像写特殊逻辑。这 样的结果是这个抽象本身就成了具像。这个架构设施就从简化系统，变成复杂化系统了。 所以架构设计我们强调不敢为主而为客，强调不为天下先。我们不是为了做架构而做架构 ，我们是为了做目标系统而做架构了。这一点很多初学者都看不上，但这一点恰恰是成败 的关键。
有一位同事做了一个中断控制器的方案让我评审，他的目的是把CPU主动发出的中断发到同 构或者异构的其他处理单元上。所以他做了复杂的路由表，描述了从各种不同的中断源到 目标的转换过程。我对此听得云里雾里，我认为这是一个失败的构架设计。
它的失败在于，它尝试描述一个算法，却不能把这个算法放在一个独立的闭包中。也就是 说，他没有抽象他解决问题的所有条件，就开始写他的算法了。你可以看懂一个函数，但 不告诉你输入参数是什么吗？
同样的，你看一个中断的路由算法，可以在没有任何Topo的定义的情况下，看懂这个算法 吗？
实际上，他也不是没有写Topo，他的问题在于，他的Topo是建立在一个具像上的。是某种 实现的Topo上，如何实现这个算法。但你的中断控制器只用于这个具体的具像吗？如果你 说是，我就有这个约束，那没有问题，我们就用这个Topo来分析你的算法了。但你又不是 ，然后你给我讲这个精巧的算法，说这先发给谁，又发给谁，然后从谁那里查了个什么参 数，我都听不进去，这好比你解一个三元方程每个元x, y, z的值域，你给我讲如果x=0的 时候如何如何，我一点兴趣没有，因为定了x=0的时候求出来的y和z的值域有啥用呢？除非 你能用这个为基础可以求x不是零的范围，然后把两者合并起来，但显然这里又不是这种情 况。