- 主题:enum or int?
那显卡对应的int范围是多少、风扇对应的int范围是多少，记录在哪里啊？不频繁变化的用enum，频繁变化的用数据库字典表。兼容这个说法就是前面某个朋友说的盖马桶理论，看不见不等于不臭。
【 在 bihai 的大作中提到: 】
: 首先有不同类型的硬件，比如显卡和风扇不能用同样的enum吧，其次，显卡类有不同的显卡，不同供货商，不同的型号，就有不同的可选频率，怎么enum?比如用[f0, f1, f2]， 新产品用了[f0', f1', f2', f3', f4']，怎么用enum控制？
: 用字符串也比enum强，因为可以兼容未来的新产品和型号。用enum,咋做？用union？显卡每次增加一个型号，就得改代码一次？
:
--
FROM 144.178.30.*
都是很小范围的整数来代表，因为是通过函数来控制设备。
Fan::Set(x);
GPU::Set(x);
具体对应的频率是显卡模块内部实现的，我只需要知道它允许哪些。比如第一个显卡[0:f0, 1:f1, 2:f2, 3:f3], 第二个显卡[0:f0', 1:f1', 2:f2', 3:f3', 4:f4', 5:f5']。那么在我的json里面，我就可以写
{ "Name": "GPU0",
"Setting":, 1,
}
这样，日后改用第二种显卡，我只需要改变配置文件，写个2即可。我的模块的代码就是要么读入字符串，要么读入整数。不同的产品用不同的显卡，用不同的配置文件。
【 在 superORC 的大作中提到: 】
: 那显卡对应的int范围是多少、风扇对应的int范围是多少，记录在哪里啊？不频繁变化的用enum，频繁变化的用数据库字典表。兼容这个说法就是前面某个朋友说的盖马桶理论，看不见不等于不臭。
: :
--
FROM 72.197.247.*
可复杂了。不是就一个enum，是一批。首先显卡，每个显卡一个enum类型；其次，还有别的部件，比如风扇，又是一批。20个设备，能搞出几百个类型。然后，显卡是一个类吧，但是我的模块是一个配置文件，读入一个字符串，变成哪个类的enum呢？费老劲了。
【 在 milksea 的大作中提到: 】
: enum与字符串转换有工具库做，不用自己来吧。strum什么的。
--
FROM 72.197.247.*
技术上，用配置文件来存对应关系是可以的，但是这个带来的另一个问题就是，你自己肯定很清楚怎么存放怎么用，但是因为不是写在代码里面的，接手你工作的人就得去了解怎么使用配置文件，而枚举更显得强制性一些。
做事上，最主要是你表达清楚你的想法，如果主管依旧不认可，那就接受这种设计。然后你要做的就是在这个条件下怎么处理好新硬件添加时候的代码更新，还有更新流程，是每硬件更新还是积累到周期更新，新硬件加入的审批流程，测试和发布流程。
最后，不要拘泥，具体问题上代码有最优解，但工程上是没有最优解的，都是各种妥协的结果，开心工作最重要。
【 在 bihai 的大作中提到: 】
: 都是很小范围的整数来代表，因为是通过函数来控制设备。
: Fan::Set(x);
: GPU::Set(x);
: ...................
--
FROM 58.246.155.*
还可以用schema，codegen，重一点
【 在 superORC 的大作中提到: 】
: 技术上，用配置文件来存对应关系是可以的，但是这个带来的另一个问题就是，你自己肯定很清楚怎么存放怎么用，但是因为不是写在代码里面的，接手你工作的人就得去了解怎么使用配置文件，而枚举更显得强制性一些。
:
: 做事上，最主要是你表达清楚你的想法，如果主管依旧不认可，那就接受这种设计。然后你要做的就是在这个条件下怎么处理好新硬件添加时候的代码更新，还有更新流程，是每硬件更新还是积累到周期更新，新硬件加入的审批流程，测试和发布流程。
: ...................
--
FROM 124.64.19.*
保证了未来的工作机会
哈哈
- 来自 水木社区APP v3.5.7
【 在 bihai 的大作中提到: 】
: 首先有不同类型的硬件，比如显卡和风扇不能用同样的enum吧，其次，显卡类有不同的显卡，不同供货商，不同的型号，就有不同的可选频率，怎么enum?比如用[f0, f1, f2]， 新产品用了[f0', f1', f2', f3', f4']，怎么用enum控制？
:
: 用字符串也比enum强，因为可以兼容未来的新产品和型号。用enum,咋做？用union？显卡每次增加一个型号，就得改代码一次？
--
FROM 120.244.217.*
可以先分析一下，新增加设备的时候，是不是需要改代码？
如果设备型号信息需要强校验，可能enum更合适
如果程序需要动态更新支持的设备型号，那么感觉字符串更合适
还是结合业务背景分析比较好
--
FROM 114.249.187.*
我觉得他最大的问题不是技术上的，而是觉得主管是傻x。接受自己不理解的约束条件，也是一个架构师非常重要的能力。
【 在 milksea 的大作中提到: 】
: 还可以用schema，codegen，重一点
--
FROM 58.246.155.*
忽然想到有个那啥定律，软件里的配置复杂化了之后一定会演变为
一个丐版LISP风格的草台DSL……^o^
感觉你和你们领导的沟通其实不在一个频道上。他关注的还是在当前
的编程语言里如何更加工程化地表示数据模型。而你更希望是把业务
逻辑里变化比较大的部分从系统核心里解耦出去，这样那一部分的数据
模型不直接用核心系统的编程语言特性来表示。我原则上支持你，但是
在领导的那个“频道”上你是没办法说服领导的。得把他引到你的频道，
给他讲故事，让他接受这种解耦，说不定到时候他比你更激进^o^
【 在 bihai 的大作中提到: 】
: 都是很小范围的整数来代表，因为是通过函数来控制设备。
: Fan::Set(x);
: GPU::Set(x);
: ...................
--
FROM 183.157.163.*
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.
【 在 adoal 的大作中提到: 】
: 忽然想到有个那啥定律，软件里的配置复杂化了之后一定会演变为
: 一个丐版LISP风格的草台DSL……^o^
: 感觉你和你们领导的沟通其实不在一个频道上。他关注的还是在当前
: ...................
--
FROM 60.24.248.*