.. Kenneth Lee 版权所有 2024
:Authors: Kenneth Lee :Version: 0.1 :Date: 2024-05-23 :Status: Draft
设计问题总结的问题
今天评审了一个工程师的设计文档，发现了一个典型的数据结构定义错误。我本来想要总 结一下的，但好像也没有什么可总结的，所以我想总结一下这个“没法总结”的问题。
他这个错误说起来简单也简单，说复杂也复杂。我让他写一个通过Python自动生成一个指 令定义的几个上下文的图片生成问题，简单说就是用户只需要在Json文件中说明一个指令 的分类，编码，别名和使用方法等属性，然后就可以在不同的上下文中生成：
大致就这么个意思吧。他在定义指令的Json文件定义的时候还是好好的，但到了后面开始 决定如何生成指令编码的分类树的时候，用的域就错了，他想用指令的编码Pattern作为 分类的index，但实际上选择不同的Pattern可能消耗相同的opcode空间，所以他用这种方 法来生成分类树，最后还是没法看到编码空间剩下多少地方可以用了。
他这个是典型的把设计做成了编码。因为他的设计文档中其实没有多少“人话”，大部分都 是“机器语言”：域的列表啦，Json文件的格式啦，等等。这样离开了人的上下文，直接陷 入了机器的上下文，那么这个设计离开了我们的设计目标就变得很容易了。
所以我给他的建议就是不要画那些表格，试试用人话来描述设计，比如：
“我们需要为允许用于在文档中通过$pattern_ref(addi, type=type_t, opcode=3)来引用 一个指令的格式，所以我们需要在$parttern_def的时候给定如下数据：……”
很多人觉得这个不够高大上，但设计本来就是把人脑中的逻辑转化为机器逻辑前，先插上 一些标记，好让我们开始沉浸到机器语言的思考模型中的时候，不会忘了我们的原始目 的。没有这些“人话”，就没有了设计的作用了。
我说这个问题不好“总结”是说：如果我把这个问题用人话说清楚了，这个实际已经做完了， 你显然觉得我的对的，他是错的。但问题在于，这整个问题就是我们很多人不会做这个 “总结”。能总结出来，这个问题就不用说了。
这真是一个“名可名，非常名”的典型案例。