1
接口类型 命名修改的代价
source link: https://www.v2ex.com/t/872616
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
只是一个名字, 不影响使用.
但当使用接口的人看到这样不一致的命名方式, 心中难免泛起 WTF.
当项目比较庞大, 开发维护的时候较长时, 这种问题难免发生.
比如 https://open.dingtalk.com/document/org/push-events 中要求的结构是:
{
"msg_signature":"111108bb8e6dbce3c9671d6fdb69d1506xxxx",
"timeStamp":"1783610513",
"nonce":"123456",
"encrypt":"1ojQf0NSvw2WPvW7LijxS8UvISr8pdDP+rXpPbcLGOmIxxxx"
}
msg_signature 和 timeStamp 同时存在. 其实还有一种写法 timestamp. 文档中针对相同的数据也还有一种命名 signature.
不是专门为了吐槽钉钉, 而是这种问题在许多地方都出现. 比如我们的项目中就部分混用了 created_at 和 createdAt.
如果有足够的类型提醒, 其实不至于出错. 但这种混乱, 如果能改一致会更好.
但是代价, 似乎不小. 哪怕只是在内部项目中, 一个普通程序员用一天时间, 这样的成本, 团队都可能不会去付出.
大家怎么看这种代价?
请不要把自己比作板砖工, 向上两级思考问题.
第 1 条附言 · 9 小时 22 分钟前
这里面还是可以区分的:
1. 内部项目.
2. 外部项目.
外部项目可能有更多的协同问题. 但通过版本迭代和接口调用监控即可缓解.
正如我在正文中说的, 哪怕只是内部项目的代价. 开发上的投入. 这部分代价, 我们的看法也是不一致的.
不过这里我有个前提, 这是一件对的事情, 是让代码更好的. 只不过是权衡, 代价过高则不做. 我这里假设了这件事情是零代价时一定要做的. 如果你认为零代价时也没必要做, 那么我们可能无法进一步讨论.
1. 内部项目.
2. 外部项目.
外部项目可能有更多的协同问题. 但通过版本迭代和接口调用监控即可缓解.
正如我在正文中说的, 哪怕只是内部项目的代价. 开发上的投入. 这部分代价, 我们的看法也是不一致的.
不过这里我有个前提, 这是一件对的事情, 是让代码更好的. 只不过是权衡, 代价过高则不做. 我这里假设了这件事情是零代价时一定要做的. 如果你认为零代价时也没必要做, 那么我们可能无法进一步讨论.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK