- 主题:enum or int?
用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。
现在回到那个写文档的人，我发现他没有考虑动态情况。
【 在 superORC 的大作中提到: 】
: 技术上，用配置文件来存对应关系是可以的，但是这个带来的另一个问题就是，你自己肯定很清楚怎么存放怎么用，但是因为不是写在代码里面的，接手你工作的人就得去了解怎么使用配置文件，而枚举更显得强制性一些。
: 做事上，最主要是你表达清楚你的想法，如果主管依旧不认可，那就接受这种设计。然后你要做的就是在这个条件下怎么处理好新硬件添加时候的代码更新，还有更新流程，是每硬件更新还是积累到周期更新，新硬件加入的审批流程，测试和发布流程。
: 最后，不要拘泥，具体问题上代码有最优解，但工程上是没有最优解的，都是各种妥协的结果，开心工作最重要。
--
FROM 72.197.247.*
怎么方便怎么来，过两天项目可能就黄了
【 在 bihai 的大作中提到: 】
: 最近在搞一个项目，需要和不同的模块接口，这些模块是管理不同的硬件的，比如设备的性能等。那么就需要调节的频率电压什么的。我就想写一个程序，读入一个配置文件，是json格式，里面写上控制的数据即可。这样，可以控制不同的设备。我们另一个人开发的接口，是有一个程序，可以配置每一个模块，用固定的函数，参数是int。
: 结果和Lead会面，他上来就说，用enum（调用那个人的接口的时候转换成int）。我觉得有没有搞错。又发给我一个别人写的文档，说enum的好处。我看出来，那是给不变的设备用的，比如某个设备就开关两个状态，就写OFF, ON。但是，我这些设备有些是多个状态。有些设备，是互相可替换的（比如显卡），但是每个具有不同的状态数量。我的第一感觉就是，用enum不可行，因为需要在写程序的时候把json里面的字符串换成enum，然后我会有一些map，把上面来的指示的参数映射到enum，比如数据结构是
: {系统模式（上面来的指令参数）1，设备A，enum 状态A1}，{系统模式（上面来的指令参数）1，设备B，enum 状态B1}
: ...................
--
FROM 114.249.20.*
没错这个设计模式是对的
【 在 huaxinjuedui 的大作中提到: 】
: 以我有限的经验，可能更支持enum
: 理由是，这种对接第三方接口的程序，通常会前置一个adapter，用于处理不同接口/规范/协议等，再由adapter返回标准数据给后端模块
:
--
FROM 120.244.226.*
对老板来说，程序可读性永远排第一，否则等你离职了，再来个新人
整个int，新人要整半天才能弄明白每个数字代表什么含义
【 在 bihai 的大作中提到: 】
: 最近在搞一个项目，需要和不同的模块接口，这些模块是管理不同的硬件的，比如设备的性能等。那么就需要调节的频率电压什么的。我就想写一个程序，读入一个配置文件，是json格式，里面写上控制的数据即可。这样，可以控制不同的设备。我们另一个人开发的接口，是有一个程序，可以配置每一个模块，用固定的函数，参数是int。
: 结果和Lead会面，他上来就说，用enum（调用那个人的接口的时候转换成int）。我觉得有没有搞错。又发给我一个别人写的文档，说enum的好处。我看出来，那是给不变的设备用的，比如某个设备就开关两个状态，就写OFF, ON。但是，我这些设备有些是多个状态。有些设备，是互相可替换的（比如显卡），但是每个具有不同的状态数量。我的第一感觉就是，用enum不可行，因为需要在写程序的时候把json里面的字符串换成enum，然后我会有一些map，把上面来的指示的参数映射到enum，比如数据结构是
: {系统模式（上面来的指令参数）1，设备A，enum 状态A1}，{系统模式（上面来的指令参数）1，设备B，enum 状态B1}
: ...................
--
FROM 120.244.226.*
haha
haha
haha
感谢你的贡献
【 在 tgfbeta 的大作中提到: 】
: Greenspun's tenth rule of programming
: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
--
FROM 111.204.200.*
表达清楚自己的想法，接受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.*
只能说他在这个问题上一开始是犯傻了。看都没看我的设计文档，上来就直接说用enum。后来不是承认enum不可行了吗。
只要需要配置文件来存放配置信息，用enum就是多此一举，因为配置放在文件里，没有写在代码里，enum各种好处就没有了。同时因为不可预测的配置要求，enum是不显示的。他都没想过这些问题，就因为看了别人的一个文档就觉得要用enum，确实他犯傻了。当然，他很快纠正了，提出了更好的办法。哪怕用String也比enum强啊，反正配置文件里就是String。
【 在 superORC 的大作中提到: 】
: 我觉得他最大的问题不是技术上的，而是觉得主管是傻x。接受自己不理解的约束条件，也是一个架构师非常重要的能力。
--
FROM 72.197.247.*
那你的方案也并不好啊
按照OOP的思路，你可以自己定义一套接口，然后为硬件写适配器，然后把接口和实现分离，这样你的配置不需要改，原有的代码也不需要动，只要设计类似“驱动”的适配器了
【 在 bihai 的大作中提到: 】
:
: 都是很小范围的整数来代表，因为是通过函数来控制设备。
:
: Fan::Set(x);
: GPU::Set(x);
#发自zSMTH@CDU.MP
--
FROM 118.81.10.*
如果其他语言，显卡和风扇不能用一个enum类型，但是rust，rust的enum实在太给力了，完全可以同样
【 在 bihai 的大作中提到: 】
: 首先有不同类型的硬件，比如显卡和风扇不能用同样的enum吧，其次，显卡类有不同的显卡，不同供货商，不同的型号，就有
:......
论坛助手,iPhone
--
FROM 112.65.61.*
你说的这些工作量的问题都可以靠GPT或者util类来解决。譬如你的配置内容是GPU_1、FAN_1，这是小事。除非有存储/传输成本压力，或者读写性能压力，否则我觉得字符串好太多了
【 在 bihai 的大作中提到: 】
: 可复杂了。不是就一个enum，是一批。首先显卡，每个显卡一个enum类型；其次，还有别的部件，比如风扇，又是一批。
:......
论坛助手,iPhone
--
FROM 112.65.61.*