技术上，用配置文件来存对应关系是可以的，但是这个带来的另一个问题就是，你自己肯定很清楚怎么存放怎么用，但是因为不是写在代码里面的，接手你工作的人就得去了解怎么使用配置文件，而枚举更显得强制性一些。

做事上，最主要是你表达清楚你的想法，如果主管依旧不认可，那就接受这种设计。然后你要做的就是在这个条件下怎么处理好新硬件添加时候的代码更新，还有更新流程，是每硬件更新还是积累到周期更新，新硬件加入的审批流程，测试和发布流程。

最后，不要拘泥，具体问题上代码有最优解，但工程上是没有最优解的，都是各种妥协的结果，开心工作最重要。

【 在 bihai 的大作中提到: 】
: 都是很小范围的整数来代表，因为是通过函数来控制设备。
: Fan::Set(x);
: GPU::Set(x);
: ...................
--
FROM 58.246.155.*

表达清楚自己的想法，接受lead权衡后决定的方案。

【 在 bihai 的大作中提到: 】
: 用Rust读配置文件非常容易，读入到一个struct里面非常直接，就对应到我的数据结构里。这个enum是不可能的，因为enum来自不同的类。配置文件只能读入数值和字符串。
: 现在Lead提出一个折中方案：虽然最后的调用是uint8，但是配置文件不放uint8，而是放入一个能够帮助找到这个uint8的参数，比如是一个字符串，或者数值（字符串也可以转换到数值）。对于显卡，存的就是频率。
: 对于别人的显卡控制模块，他们可能是0:500M, 1:625M, 2:750M等，那么在配置文件不存0,1,2,而是存750M。这样怎么知道是2呢？可以让别人提供另个统一的接口，得到2。然后我的数据结构在读入配置文件之后，构造vector里面存的是2。这里就没有enum什么事了。他说了，enum是静态模块用的，就是固定的几个状态。而我要对接的有大量的动态模块，不仅我不知道有哪些状态，开发这些模块的也不知道，没法用enum。连名字都没法起，叫FREQ_1, FREQ_2吗？已经失去了可读性了。也不能防止打错字了。而且和风扇的enum不一样，因为风扇是LEVEL_1, LEVEL_2。
: ...................
--
FROM 114.84.16.*