各位老哥见过这样的后端 API 约定吗 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要在回答技术问题时复制粘贴 AI 生成的内容
doommm
V2EX    程序员

各位老哥见过这样的后端 API 约定吗

  • &bsp;
  •   doommm 2018-12-04 00:57:52 +08:00 11670 次点击
    这是一个创建于 2579 天前的主题,其中的信息可能已经有所发展或是发生改变。

    入职一个多月,还在试用期,这周被调到一个新的项目组,说是以后就负责这里的前端了。小组就 1 前端+1 后端+1 产品(负责人,也做后端),要做一个统计 项目。

    谈到 API 的时候产品告诉我,他们的 API 会返回下面这种格式,我也需要用这种格式返给后端

    { 'A00001': '...', 'A00002': '...', 'B00001': '...', 'C00001': '...', // ... } 

    ABC 表示数据层级什么的(这个没听明白,好像在数据库里的表字段也是这样命名的),编号随着字段增加会一直递增,会给我一张 Excel 表让我去查对应的编码的解释。

    问这么做的原因,说是出于什么加密的打算,说反正前端都是要查表填字段的,变量取什么名字又没差。我:?????

    当时我就表示无法接受,气氛一度很尴尬,最后也不了了之了。感觉后面再谈这个事情会闹得不愉快。

    这让前端怎么搞?我这一年多经验见识少,有没有老哥能跟我讲讲其中的奥义?

    其实还有不少坑,比如原型是一份到处截图下来的像剪贴画的 Excel 表格,月底还要上线第一版,感觉是个巨坑。当时面试的时候并不知道要我来做这个,我都没打算做一个人的项目。

    公司 100 人左右,不算太小,感觉算技术型公司,但是要看项目组。做 Web 的前端岗位就我跟面试我的小哥(水平不错)两人,这一个多月是在一起做项目的,配合的很不错,前端这块并不是公司的重点。

    现在考虑的是,如果是个坑就得跑,但是因为我是 7 月底离职后在家待了 2 个多月,10 月份才开始找工作并入职的,这样简历上是不是没法看了? 1 年多的前端很多 HR 都直接筛掉了,根本没有面试机会。

    坐标厦门,15 毕业,省内 211,工科专业非计算机,毕业后做 2 年 C#开发后转前端做到现在,这是我第一次跳槽,待遇就不要提了,都是泪。

    第 1 条附言    2018-12-04 09:21:49 +08:00
    移动互联网企业,并非 zf 或者涉密单位。
    并没有任何拒绝沟通的意思,发帖的目的也是为了理解这样的做法。
    以我有限的经验看,如果一个前端项目里面如果充满这些字段名,后续维护迭代成本我是不敢想的,查表就要查半天,没有效率可言。
    101 条回复    2019-01-05 00:28:58 +08:00
    1  2  
    crs0910
        1
    crs0910  
       2018-12-04 01:07:36 +08:00 via iPhone
    直接显示这些编码,有人问你就说。这是为了加密。
    AllOfMe
        2
    AllOfMe  
       2018-12-04 01:12:34 +08:00   3
    其实我觉得只要数据格式明确就没有什么问题吧,这个可能和程序员的代码洁癖有关,我有时候也忍受不了一些数据格式的别扭,但是身为一个程序员,应该专业的不带感情的去对待
    0ZXYDDu796nVCFxq
        3
    0ZXYDDu796nVCFxq  
       2018-12-04 01:22:52 +08:00 via Android
    RSA 了解一下
    有些重要数据可以用 RSA 加密然后传回去
    df4VW
        4
    df4VW  
       2018-12-04 01:29:42 +08:00
    刚入职一个月还在试用就这么刚吗
    Mitt
        5
    Mitt  
       2018-12-04 01:33:05 +08:00 via iPhone   8
    这种属于加密给自己看的,纯粹没事找事型
    zhangyu911013
        6
    zhangyu911013  
       2018-12-04 01:33:13 +08:00 via Android
    感觉就是个工作量是前端还是后端做,有的后端传的比较原始,需要前端自己解析处理,有的后端都给你拍好了直接可以用。努力沟通下吧,争取确定一个双方都比较方便的格式。。这些都是小事
    scnace
        7
    scnace  
       2018-12-04 01:45:43 +08:00 via Android   1
    “密码学不要自己造轮子” (还有这算哪门子的加密?
    Lonely
        8
    Lonely  
       2018-12-04 01:48:08 +08:00 via iPhone
    想走就走,估计你也不想沟通
    sagaxu
        9
    sagaxu  
       2018-12-04 02:00:52 +08:00 via Android   2
    国企很多这种字段混淆项目,我见过一张表几百个字段,都是这种名字
    doommm
        10
    doommm  
    OP
       2018-12-04 06:40:02 +08:00 via Android
    没有任何拒绝沟通的意思,发帖的目的也是为了理解这样的做法。
    以我有限的经验看,如果一个前端项目里面如果充满这些字段名,后续维护迭代成本我是不敢想的,查表就要查半天,没有开发效率可言。
    kx5d62Jn1J9MjoXP
        11
    kx5d62Jn1J9MjoXP  
       2018-12-04 07:09:11 +08:00 via Android
    见过垃圾的后端,你碰到的这种已经属于奇葩行列,这种不入流的开发经验积累起来对你也没什么好处
    Trim21
        12
    Trim21  
       2018-12-04 07:19:11 +08:00 via Android
    嗯,这 excel 要是泄露了很就得重新改一遍数据库结构才安全?
    yamedie
        13
    yamedie  
       2018-12-04 07:25:21 +08:00 via Android
    魔法数字?
    yuikns
        14
    yuikns  
       2018-12-04 07:30:16 +08:00
    等等。你们这个是怎么 mapping 呢?难道是 hard code ?

    要我倒是无所谓,我大概把它当作 i18n 来做,直接拿个包 https://github.com/i18next/react-i18next 就搞定

    当然平时我是不写前端的,除非偶尔写个 demo
    xuanbg
        15
    xuanbg  
       2018-12-04 07:46:12 +08:00
    赶紧找下家。。。
    AntiGameZ
        16
    AntiGameZ  
       2018-12-04 07:57:24 +08:00   1
    之前我有这么做过,不过会另外维护一个 mapping,真实有意义的名字和 A/B/C 这些无意义名字的对照。最终发到前端的 JSON 是根据映射文件生成的。
    doommm
        17
    doommm  
    OP
       2018-12-04 08:02:25 +08:00 via Android
    @AntiGameZ 他们根本没打算做 mapping,给我的感觉是要么不懂现在的前端开发,要么就是想省事,加密只是说辞
    NaiveSimpleYoung
        18
    NaiveSimpleYoung  
       2018-12-04 08:28:58 +08:00 via Android   1
    前端如果维护一个 mapping,“加密”不就失效了如果不维护…对接口不跟吃苍蝇一样吗
    wolfie
        19
    wolfie  
       2018-12-04 08:29:36 +08:00
    不像是加密,应该是工作量问题。
    yemoluo
        20
    yemoluo  
       2018-12-04 08:30:40 +08:00
    又见厦门,你好
    az422
        21
    az422  
       2018-12-04 08:37:55 +08:00 via Android
    只是字段编码了,值不变?
    比如 A00001:10086,这一眼就看出 A00001 是手机号了,没事找事啊
    nullcc
        22
    nullcc  
       2018-12-04 08:41:59 +08:00
    后端可以给领导吹牛逼鸭,说我们采用加密技术,当然领导不会去了解细节的(手动狗头。哈哈看了 LZ 厦门观音山的,搞不好就在隔壁
    Leigg
        23
    Leigg  
       2018-12-04 08:45:35 +08:00 via iPhone   1
    不加密数据,反而加密字段?
    buf1024
        24
    buf1024  
       2018-12-04 08:48:44 +08:00   1
    这样定义数据层级很正常:
    比如: A 表示数码产品大类,00001 表示手机,00002 表示小家电等等,B 代表服装大类等等
    Bryan0Z
        25
    Bryan0Z  
       2018-12-04 08:52:08 +08:00 via Android
    我没懂,这咋了
    lengxiao
        26
    lengxiao  
       2018-12-04 08:53:17 +08:00
    同厦门 +1
        27
    doommm  
    OP
       2018-12-04 08:54:03 +08:00 via Android
    @buf1024 所有字段的 key 都是这种形式,这还是层级问题么
    k9982874
        28
    k9982874  
       2018-12-04 09:00:18 +08:00
    现在的前端真难伺候
    VeryZero
        29
    VeryZero  
       2018-12-04 09:06:09 +08:00   2
    之前做 ZF 外包项目遇到过类似的,甲方给的数据字段都是这样的,数据库里存的也是这样的。一度以为他们脑子秀逗了。过了好长时间一次偶然的机会发现,貌似 ZF 里有一个标准,规定了字段对应的编号。。
    zaqzaq0125
        30
    zaqzaq0125  
       2018-12-04 09:07:53 +08:00   1
    我司对接事业单位的数据库都是这种字段名。(字母+数字)
    drydiy
        31
    drydiy  
       2018-12-04 09:09:27 +08:00
    @k9982874 语义化了解一下?
    allen9527
        32
    allen9527  
       2018-12-04 09:12:13 +08:00   1
    有些项目甲方会有这些规范,反正挺坑的,字段都是编码或者缩写,根本不知道是啥意思。
    你前端自己维护一个 mapping 啊,估计没人看。
    按这个字段以后维护起来会吐血。
    VoidChen
        33
    VoidChen  
       2018-12-04 09:13:11 +08:00   4
    不知道你们什么行业,我做公安行业和交通行业确实需要这么处理,前后台都弄个字典转义。年轻人见识少还是心存敬畏的好
    Guozi1989
        34
    Guozi1989  
       2018-12-04 09:13:49 +08:00
    我还见过 {"备注 1":"买了否冷"} 的。
    si
        35
    si  
       2018-12-04 09:13:50 +08:00
    我昨天刚搞个了 A0~A100 全部字符串的的表,没办法,爱怎么样就怎么样吧,我也懒得改变别人的想法。
    rocksolid
        36
    rocksolid  
       2018-12-04 09:14:37 +08:00
    这是在为难 python
    annielong
        37
    annielong  
       2018-12-04 09:20:13 +08:00   1
    少见多怪吧,很多都有这种要求的,F001,F002 等等,隐藏数据库字段,
    lsongiu
        38
    lsongiu  
       2018-12-04 09:21:30 +08:00
    这是什么格式,单引号什么鬼,自己写解析方式吗,又不是 json
    Norie
        39
    Norie  
       2018-12-04 09:21:54 +08:00 via Android
    难道不是甲方说了算?
    jrient
        40
    jrient  
       2018-12-04 09:23:07 +08:00
    自己做个自动解码的功能,有障碍才有进步。
    doommm
        41
    doommm  
    OP
       2018-12-04 09:23:15 +08:00 via Android
    @VoidChen 移动互联网企业,自己的项目
    ifoto
        42
    ifoto  
       2018-12-04 09:23:30 +08:00
    为同在鹭岛的你的感慨一下。厦门这种坑逼还是很多的
    doommm
        43
    doommm  
    OP
       2018-12-04 09:25:09 +08:00 via Android
    @lsongiu 是 json,我写的是 js 的格式,举个例子而已
    strive
        44
    strive  
       2018-12-04 09:26:38 +08:00
    遇到过设计成字段 1 字段 2 字段 3 字段 4,当时就一脸懵逼
    doommm
        45
    doommm  
    OP
       2018-12-04 09:27:25 +08:00 via Android
    @Norie 做的是公司自己的项目,算是旧平台重做吧
    ilaipi
        46
    ilaipi  
       2018-12-04 09:28:57 +08:00
    我是后端出身的,一样看不惯这样的后端。前端代码现在如果上线要保密啥的至少要 ugly 一下吧。。。靠这样的编码变量名,真是画(xian)蛇(de)添(dan)足(teng)。不知道后端是用的什么语言,现在大部分语言应该都可以前端数据直接 mapping 到 model 了吧,这样编码一下,这个 mapping 不得加一层了?真是 F***
    shyangs
        47
    shyangs  
       2018-12-04 09:41:19 +08:00
    ZF 标准
    Sapp
        48
    Sapp  
       2018-12-04 09:54:45 +08:00
    如果是为了保密什么的,你们后端是个傻逼无疑,这保密个锤子?
    如果仅仅是格式不符合前端调用,那简直太正常了,后端一贯的德行,自己撸着舒服就行,甚至有后端从库里取出来什么就给你什么(一串字符串转都不愿意转...),碰上一个好的后端简直太艰难,我现在都是自己转
    xiaozizayang
        49
    xiaozizayang  
       2018-12-04 10:02:40 +08:00
    各个公司由于历史原因各种规定 估计你组长也不知道为什么是这个样子哈哈 btw 我也在厦门 哈哈
    guoyuchuan
        50
    guoyuchuan  
       2018-12-04 10:06:48 +08:00
    表示看不懂
    notreami
        51
    notreami  
       2018-12-04 10:19:51 +08:00   1
    拿着白面的钱系列,数据 key 真的重要嘛??系统架构设计、中间件、持续交付、监控容灾抗压等等才是关键吧。
    这种格式,说白了,就是之前种种原因( zf 要求、大佬一游等)设计成这样了。
    然后让你改,你能怎么改呢?全盘推到重做?针对自己这块做 key 映射,然后引入一些新 key 让大家学习?
    在不放弃的原则下,那肯定是忽略这块,然后看看业务流程、技术栈、维护的服务系统设计、整体系统架构等等有木有坑,这些坑感觉太大,就可以名正言顺的下一家了。
    stzz
        52
    stzz  
       2018-12-04 10:25:52 +08:00
    你如果看不惯就跑吧,要不你来重构数据结构?
    codespots
        53
    codespots  
       2018-12-04 10:29:50 +08:00
    @annielong 这算少见多怪?隐藏数据库字段,要 AS 干什么吃的
    reself
        54
    reself  
       2018-12-04 10:31:16 +08:00 via Android
    @doommm 加密个铲铲,估计他自己都不懂这么做的缘由,只是照搬别人的规范而已。
    这么做完全是为了维护性,代价是需要建额外的字段映射表。如果表很少,这么做确实有点多余。但是如果表很多,字段上万,这么做非常有必要。
    duan602728596
        55
    duan602728596  
       2018-12-04 10:35:08 +08:00 via iPhone
    有毛线用,扒过一堆接口的人表示,字段这东西猜都能猜出来
    learnshare
        56
    learnshare  
       2018-12-04 10:35:27 +08:00
    这种加密方式的好处是自己人看起来麻烦
    doommm
        57
    doommm  
    OP
       2018-12-04 10:42:21 +08:00 via Android
    @reself 上万个的字段都选择这么直接返回给前端的话,前端真的会狗带…
    snw
        58
    snw  
       2018-12-04 10:44:26 +08:00
    ZF 标准只看到过取值有固定编码,没见过字段名用固定编码的。印象中 ZF 项目字段名不都是拼音首字母缩写吗?
    http://www.gov.cn/gongbao/content/2017/content_5165785.htm
    visonme
        59
    visonme  
       2018-12-04 10:45:14 +08:00
    见没见过还真不重要
    API 约定,不说不同的公司,有自己的一套甚至于几套规范,就是同家公司不同组都存在很大的差异。
    重要的是,这些约定是明确,有效,可执行的~
    snw
        60
    snw  
       2018-12-04 10:46:15 +08:00
    你把那张 excel 表做个映射表,然后自己管自己用语义化的变量名,和后端通讯时 map 一下就行
    chmlai
        61
    chmlai  
       2018-12-04 10:48:45 +08:00
    就算是 ZF 的标准也是个弱智标准
    zhaogaz
        62
    zhaogaz  
       2018-12-04 10:51:49 +08:00
    哦,我好想是理解了,

    我之前外包公司的开发规范里面有个类似的事情.不过我们当时是后段代码,bussiness object 简称 bo,一般命名是 xxxBo,

    规范中要求 xxx 是 字母简称+数字也就是 AAA001 类似这种,

    但是后来我们也没有照着做,我们就是按照类名命名来写.

    建议你问问理由,然后尝试按照他们思路理解下.这个事相比其他的都小毛病,无所谓.

    (反正我觉得就是麻烦自己而已...)
    lrh3321
        63
    lrh3321  
       2018-12-04 10:53:01 +08:00 via Android
    好傻
    reself
        64
    reself  
       2018-12-04 10:55:55 +08:00
    @doommm 所以才要查表啊,这得有多懒惰连查表法都不知道
    reself
        65
    reself  
       2018-12-04 11:01:30 +08:00
    @doommm 你的问题是学的太少抱怨太多。上万个字段的场景,而且有频繁的字段增减、字段值编码的变化,这时候单词命名是根本不够用的,你思考一下就知道这时候就得用数据库表来驱动,将字段名、字段值都放表里,人是读不懂编码的,所以还得写个映射方法去映射。
    doommm
        66
    doommm  
    OP
       2018-12-04 11:02:58 +08:00 via Android
    @reself 查表法我知道的。我理一下,目前他给我的 excel 表里面只有编码对应的中文解释,意味着我自己要先对每一个变量在前端命名,然后用查表法去转。感觉是个工作量问题?
    reself
        67
    reself  
       2018-12-04 11:05:52 +08:00
    又如,如果你们弄了个通用系统,要在各个项目里用到,但不同项目对相同数据的描述却不一样,编码也不同,本质上确是同一个东西,难道你要为每个子系统重新设计一套命名,然后去批量改代码里的命名?用表驱动的话就根本不需要做这种工作,直接更新表就行了。
    reself
        68
    reself  
       2018-12-04 11:13:40 +08:00
    @doommm 所以还是看字段量,如果字段少,这部分工作量的比重就会比较大。如果字段量很多,相对于维护这些字段,维护查表的成本要小很多。比如维护单个字段的成本系数是 10,字段查表的成本系数是 5,那成本就是 10k 与 5k+C ( k 是字段数量的某种指标,C 是维护查表方法的成本,不随字段数量增长)。那么 k 小于 2 时直接维护字段划算。k 大于 2 时建立映射表划算。
    抱歉之前可能比较暴躁,主要是对你的描述里透露出的“因为抵触,认定它一定是不合理的,不愿去了解和学习”不满
    cs371332219
        69
    cs371332219  
       2018-12-04 11:14:16 +08:00
    这种属于不懂装懂,自欺欺人,赶紧招下家吧。权衡下自己呆在这能积累多少有用的东西。
    reself
        70
    reself  
       2018-12-04 11:15:25 +08:00
    @reself sorry,k 的分界应该是 C/5
    reself
        71
    reself  
       2018-12-04 11:17:09 +08:00
    当然,如果后端只给数据,不负责字段表,那就是坑,赶紧跑路吧~
    woshipanghu
        72
    woshipanghu  
       2018-12-04 11:18:28 +08:00   1
    统计的内容设计很多专业的词汇,用对应的英文长而且你也看不懂,还不如短一点的变量
    才一年的工作经验 还是不要这么跳的好
    dd0754
        73
    dd0754  
       2018-12-04 11:23:12 +08:00 via iPhone
    接过一个这样的外包,搞的我想屎
    ddup
        74
    ddup  
       2018-12-04 11:25:23 +08:00 via Android
    字段混淆,这很正常。
    碰到这种需求,要是觉得麻烦,可以自己先弄一个 mapping,代码里面写可读性强的字段名,改一下编译器自动把这段替换回去就行了,这样既方便维护,又保证了编译后的代码变量名被混淆。
    mapping 只在编译的时候需要。
    ddup
        75
    ddup  
       2018-12-04 11:26:34 +08:00 via Android
    纠正一下,改一下编译过程,不是改编译器。现在前端不都有构建器吗?
    atcdef
        76
    atcdef  
       2018-12-04 11:28:00 +08:00
    这种我倒是见过,一般来说,给钱的人说了算,毕竟这个给出了明确的说明文档,无可非议哈
    Linxing
        77
    Linxing  
       2018-12-04 11:31:33 +08:00
    哈哈哈哈哈 看得我醉醉的
    hellobanny
        78
    hellobanny  
       2018-12-04 11:34:44 +08:00
    如果一行代码都没写过,这个还可以商量下。如果后端都实现了,那就这样定了,反正只要文档明确,都一样。写前段数据处理只是一小部分工作,大部分都不是花在这个上面,写个小模块翻译下就好了。为这么点小事就跑路,那估计哪儿都呆不久。
    petelin
        79
    petelin  
       2018-12-04 11:36:26 +08:00
    会给我一张 Excel 表让我去查对应的编码的解释。这就很坑了, 起码是一个可编程的格式, 否则就是态度问题(json 什么的)....
    前端怎么查表也要 hardcode 带代码里. 楼上居然还有人支持,说什么为了加密....弱智吧
    shuperjolly
        80
    shuperjolly  
       2018-12-04 11:43:56 +08:00 via iPhone
    楼上好多人都只能说太年轻啊
    xi2008wang
        81
    xi2008wang  
       2018-12-04 11:49:39 +08:00
    @petelin 不需要 hardcode 吧,写一个替换函数,js build 阶段时替换一下
    其实这也不是什么加密,就是混淆,加大破解难度
    buf1024
        82
    buf1024  
       2018-12-04 11:53:17 +08:00
    @doommm 表示数据层级可能只是一方面,另外,如果所有的 key 都是这样,那么是不是后台对这种 key 有特殊的考虑?比如考虑到以后的扩展,比如分库,数据迁移等,A 开头的,数据迁移的 A 机器,B 开头的数据迁移到 B 数据,这样对以后的数据扩展和分库都比较方便。
    xuhaoyangx
        83
    xuhaoyangx  
       2018-12-04 11:54:30 +08:00
    说个我知道的...各种宝们和证券交易系统 用的中间件,访问接口也是这样的,数字一串,里面的字段到是比较正常的
    doommm
        84
    doommm  
    OP
       2018-12-04 11:55:49 +08:00 via Android
    @buf1024 昨天问原因的时候他只含糊的说很多原因,我会再去做沟通
    reself
        85
    reself  
       2018-12-04 11:58:04 +08:00 via Android
    @doommm 可以沟通下一下,只给 Excel 确实坑,这个应该做成后端返回的。至于是首页一次全量返回还是分页按需返回则需要协定。
    buf1024
        86
    buf1024  
       2018-12-04 11:58:15 +08:00
    @doommm 这样定义 key 是很正常的,后台的会考虑很多性能和扩展性问题。只是不知道你们是不是这样考虑。
    wdv2ly
        87
    wdv2ly  
       2018-12-04 12:02:38 +08:00
    “如果一个前端项目里面如果充满这些字段名,后续维护迭代成本我是不敢想的”,
    多大点事,自己加个跟服务器对接的转换层隔离下不就行了吗
    Chingim
        88
    Chingim  
       2018-12-04 12:07:52 +08:00   1
    无非就是 mapping 谁来做的问题罢了.
    这种场景我都是说服后端, 让他们做, 理由:
    1. 接口字段应该语义化, 一来方便开发, 需要传什么值一目了然. 二来方便测试, 测试人员抓包的时候如果能一眼看出数据含义, 效率会很高. 不仅仅字段名称语义化, 连字段值也要尽量语言化, 能传 ISO 格式的时间, 就不要传时间戳

    2. 如果有多个端(ios/android/其他 web)在消费这个接口, 那么每个端都得做自己做一遍映射, 代码冗余
    doommm
        89
    doommm  
    OP
       2018-12-04 12:20:59 +08:00 via Android   1
    @reself 就昨天沟通的结果,字段往多了说还不足 100 个,详细文档还没有给到我。您说的后端给的字段表目前不存在,产品的意思是让我直接往代码里填这些编码。
    自己来做 mapping 的工作算是一个方案,我会想想如果要做的话,怎么做的好一些。
    有一个新问题是,前后端协商接口的时候,为了不给今后工作挖坑,前端这边需要守住的底线在哪里?
    l00t
        90
    l00t  
       2018-12-04 12:23:20 +08:00
    这是业务需求,你这样理解就行了。傻不傻另当别论,有些看起来很蠢的东西是因为天时地利人和各种原因导致的妥协,有些则是真的蠢。你到这公司才一个多月,还没到可以判断对方业务需求是否合理的时候。

    坑不坑什么的,不是这种地方能看出来的。这点鸡毛蒜皮的小事就下定论的话,这世界上怕是也没几个公司不坑了。
    xuecan
        91
    xuecan  
       2018-12-04 12:37:21 +08:00
    同厦门呢 难得 哪家公司啊
    leexy
        92
    leexy  
       2018-12-04 12:53:52 +08:00
    你明天不要来上班了
    keepfun
        9
    keepfun  
       2018-12-04 13:46:40 +08:00
    我觉得如果是出于安全考虑,这个无可厚非.比如一些字段名字,定义的见其名就知其意,并不好.
    JCZ2MkKb5S8ZX9pq
        94
    JCZ2MkKb5S8ZX9pq  
       2018-12-04 13:48:06 +08:00
    既然有 excel 了,自己 mapping 一下就好了呗。
    先适应公司,再看看有没有改善的可能。
    AntiGameZ
        95
    AntiGameZ  
       2018-12-04 15:28:14 +08:00
    @NaiveSimpleYoung mapping 在后端做。mapping 管理有单独的 UI。有意义的文字是给人看的,无意义的字符在 API 层面上用。反正写代码的时候也不会看到这些东西。前端那边在开发阶段使用一样的 mapping,发布的时候 build script 会把这些 mapping 的值做替换。
    chenyu8674
        96
    chenyu8674  
       2018-12-04 16:25:34 +08:00
    sourcecode:var phOnenumber=jsonObj.getValue("A00231");

    加密,卒
    fxxkgw
        97
    fxxkgw  
       2018-12-04 17:08:36 +08:00
    以前写 C 的吧
    TingHaiJamiE
        98
    TingHaiJamiE  
       2018-12-04 17:49:55 +08:00
    偶然见过一次我们某厂家的代码,里面也是这样写的,理由和楼主说的一样,为了保密
    sammo
        99
    sammo  
       2018-12-04 22:01:46 +08:00
    编程 是不是典型的 “一个东西有很多种实现的办法”
    在某种限制条件之下,才会过滤得出一种办法
    而人们又无法对 “某种限制条件” 达成共识
    感觉就是 这根本就没法整
    感觉就是 很容易造成权威崇拜,最后发现 权威也不权威
    生命如此懵懂
    ( 珍爱生命、远离编程 )
    519718366
        100
    519718366  
       2019-01-04 11:10:14 +08:00   1
    我一个做过社保项目的同学当时也跟我吐槽过,就是你这种设字段设计,貌似是 zf 的尿性?♂
    1  2  
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     5130 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 45ms UTC 07:16 PVG 15:16 LAX 23:16 JFK 02:16
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86