问一下后端的同学为何你们传参都喜欢 int 1234

2020-05-15 11:29:37 +08:00
 en20

比如接口要传一个请求来源,后端让我传的参是 1 拼多多, 2 淘宝, 3 京东 。。。

为什么不能直接给一个字符串 '淘宝',反正都是要 switch case ,这样也很直观.接手别人的项目里一堆 1234 我都不知道传的是什么,也不写个 map,我很难受

18044 次点击
所在节点    程序员
138 条回复
zpf124
2020-05-15 13:03:43 +08:00
以 java 来说。

1 、(重点原因) 数据库设计的范式、老师讲课的内容,教我们的就是尽量降低时间复杂度和空间复杂度。
int 能存的数据不要用 bigint,vchar(10)够用就不要用 vchar(200)。

因此在设计数据库(我不知道现在还有几家公司是有专门的数据库设计人员参与开发的,反正我见到的都是程序开发自己设计表)的字段时我们的就是使用 int byte char 之类的长度较小的字段存储这类枚举值的,只会在注释里写一下每个枚举对应的解释。 也因此会习惯性的将接口也设计成直接传这个枚举值。
如果传字符串也不是不可以,后端自己 switch case 一下传过来的字符串,将他们转成对应的枚举值就行了,就是要是添加了新值的话,那后端程序每个传这个数据的接口都得更新一遍 switch case,麻烦。

2 、jdk7 才支持 switch ( string ), 但历史惯性让我们更习惯于使用 int 。
并且在懒得自己做压测、不知道 jdk 对 string 优化到什么程度的情况下,一般的 javaer 会自然的认为 switch case 一个 int 、char 和 enum 的性能是高于字符串的。
darknoll
2020-05-15 13:07:40 +08:00
如果用字符串的话,你可能又要问了,为什么要用“taobao"不用”淘宝"?
这些都小事
ZehaiZhang
2020-05-15 13:09:50 +08:00
经常更新扩展渠道的话,应该是这么做的,比如一些内部相应 code 都是约定用数字表达的,和 http 的 404,502 一样,和文字解耦,体积变小,方便归类
SjwNo1
2020-05-15 13:11:53 +08:00
传数字正常操作,不要在后端出现 magic num 就好~
lululau
2020-05-15 13:13:50 +08:00
没有别的原因,就是因为 low

枚举值存库用数值型,除了带有顺序属性的枚举类型可能有排序的需要之后,真的比存字符串 low

而且即便存库用数值型,前后端接口用字符串也是没问题的,就是有的人不知道怎么处理
icyalala
2020-05-15 13:17:34 +08:00
传字符串觉得好的,是不是恨不得在 Java 里也用中文类名啊?
JRay
2020-05-15 13:37:47 +08:00
这儿可能是淘宝 京东,假如之前的麦当劳变成了金拱门是不是得把代码里面的全局替换一次?
guogang9011
2020-05-15 13:38:06 +08:00
可以问后端把数据库地址要过来,数据库设计的时候 针对 1234 这样的应该都会有注释的,这样就都明白了,就算后端改了,你也一样能看到。
当然也可以让后端弄一份常量字典文档,但是后端可能比较不喜欢维护这个文档,或者忘记更新。
freakxx
2020-05-15 13:44:41 +08:00
我记得在 V 站看过一个回答,

讨论是是 json 的的格式问题,
在这里也是适用的。

大概就是前端做一个 mapping 或者之类,防止代码被腐蚀恶臭。
freakxx
2020-05-15 13:45:54 +08:00
@icyalala #46

这样的杠法,
是不是恨不得直接用 01 写代码啊?
freakxx
2020-05-15 13:49:08 +08:00
不过某种程度讲,这个问题讨论不出结果,
大部分这种属于规范和建议性的东西,很难全部人遵循。
ershierdu
2020-05-15 13:49:24 +08:00
赞同 41 层,特别是以 c/c++入门的同学,很容易第一反应考虑时空复杂度
zhuweiyou
2020-05-15 13:53:47 +08:00
因为后端是枚举类型
enum Type {
PDD,
TAOBAO
}

1234 是程序自动出来的啊
fiypig
2020-05-15 14:15:31 +08:00
我还是习惯用 1 2 表示
AngryMagikarp
2020-05-15 14:19:36 +08:00
诸如 HTTP 协议,也用状态码 200 来判断是否成功,而不是通过字符串 OK 。很大程度上是因为数字比字符串更容易处理。另一方面数字的扩展性更好,要增加新的状态码,直接+1 就好,而字符串每次都要新想一个,还要担心是否与之前重复。当枚举量大的时候用字符串来处理其实是非常可怕的。

另外数字也有一些处理上的便利,比如要判断客户端上传的数据是否有效,直接 input>1 && input <=3 就好。

现在一般不在乎那么一点性能,但字符串的匹配确实没有数字的匹配快。
crella
2020-05-15 14:21:42 +08:00
过早优化是万恶之源
qW7bo2FbzbC0
2020-05-15 14:21:45 +08:00
@risent 赞同,很多时候,就行数据库字段有时直接 bigint 或者 int 就可以,不必要追求 int(1), tinyint 。 讲到用数字来代表实际含义的话,还要背枚举表,拉低效率。
qW7bo2FbzbC0
2020-05-15 14:23:30 +08:00
字符串匹配比不上数字快,而且字符串存的长。但是我想一般只有对成本或者功耗有严苛要求的嵌入式开发者才会真正需要考虑这些
awfe
2020-05-15 14:23:55 +08:00
万一哪天“淘宝”变敏感词了呢[手动狗头]
AngryMagikarp
2020-05-15 14:29:09 +08:00
无论是数字还是字符串,前端和后端都应该用常量来存。比如
const Taobao=1 或者 const Taobao="taobao"。
那么你在用的时候是用 Taobao,根本不用在乎他是数字还是字符串。那些纠结这个问题的人是不是在所有地方都写一遍“taobao”。

如果直观是判断设计好坏的唯一标准,那都应该去写易语言。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/671946

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX