V2EX › Ianchen 的所有回复 › 第 3 页 / 共 3 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3

❮

❯

2019 年 11 月 25 日

回复了 villivateur 创建的主题 › 程序员 › 为什么我们总叫自己是程序员或者码农，不叫“工程师”？

码农配不上工程师这种 title. 好好搬砖, 你只是个[C, V]搬运工, 别想有的没的. 不说了, 工头叫我干活了

2019 年 11 月 9 日

回复了 1oNflow 创建的主题 › Java › 想练一下 Java 多线程相关的知识点可以做什么项目？

线程? 并发? 还是 Java 的? Spring MVC 源码了解一下?

2019 年 11 月 1 日

回复了 tony1016 创建的主题 › 汽车 › 有多少程序员买了蔚来 ES6 或者 ES8 的？？

你买我支持, 我买我不买. 请

2019 年 10 月 24 日

回复了 AOIO7t 创建的主题 › 问与答 › 听说白条已经上征信了，花呗也会上吗

白条上征信已经是两年前的事情了. 哪家银行查到白条使用记录, 直接提高贷款利率? 哪个城市?

2019 年 10 月 22 日

回复了 h82258652 创建的主题 › 程序员 › 采取 RESTful 风格的 api 是否应该对结果包一层？

@ABenmao 也许吧, 哈哈. 如果我站在你的角度上, 我可能还会用这种思路去设计.
我比较倾向尽量少或者无人力去审查这些, 因为之前设计的错误码也是让专人去审查的. 我觉得这些时间与人力可以用在其他地方上. 还是让场景来决定设计吧.

2019 年 10 月 22 日

回复了 h82258652 创建的主题 › 程序员 › 采取 RESTful 风格的 api 是否应该对结果包一层？

@ABenmao #216 我给上家公司设计的错误码就是这种思路, 程序员知道错误码后能快速的定位到问题, 每个系统, 模块结合起来, 再加上特定的模块里的业务逻辑再定 3-4 位错误码, 最终设计出来的错误码直接飙到 7-8 位错误码. 结果后期要返回错误码的时候,需要找哪个错误码已经被用过了, 维护错误码又是一个重复的工作量. 我觉得这种设计不美观, 复杂, 繁琐, 不优雅. 后来我就根据逻辑处理来设计错误代码, 省去大量增长的错误代码查找工作. 与其让业务去做这些复杂重复的工作, 我为何不写个能跟踪问题所在的日志记录系统呢? 框架有存在意义就是帮程序员节省重复的劳动力, 专心做业务, 想往技术发展的程序员自然会去研究框架的实现技术.

2019 年 10 月 22 日

回复了 felixin 创建的主题 › 数据库 › 请问是否有相关资料学习一个典型的多用户系统的权限管理的是如何架构的？

自己写 RBAC2

2019 年 10 月 22 日

回复了 h82258652 创建的主题 › 程序员 › 采取 RESTful 风格的 api 是否应该对结果包一层？

@yamedie 你也说是因为 PM 后面脑洞大开时提出的, 与你当时写完后不给 code 并不冲突, 因为这是后面提出的改进. 并且 PM 提出这个需求, 你以评审是否有必要, 有则给开发新加个这种工作量需求, 没有那就驳回这个需求即可, 不是吗?

2019 年 10 月 22 日

回复了 h82258652 创建的主题 › 程序员 › 采取 RESTful 风格的 api 是否应该对结果包一层？

@yamedie 是的, 我不是前端. 我反驳的是 70xx 这种错误码无意义, 后面你的 9001 代码就有存在的必要, 因为前端需要根据这个固定代码来跳转到登录页面引导用户登录. 我的逻辑很简单, 前端需要根据返回的错误码来进行页面上的逻辑处理, 则规定一个具体代码, 如果没有逻辑处理, 定义那么多错误代码我是觉得没意义.

想一想, 验证码失效, 一个提示语告诉用户即可, 无需定义 7001 这种代码, 验证码校验失败也是一个提示语的事情, 7002 的代码无存在意义. 除非你们的产品经理有要求你们在有这种提示语时有特殊的界面交互动作, 那这 7002 的代码就有其存在的意义, 前端需要知道这个错误码, 才能做逻辑处理交互.

2019 年 10 月 22 日

回复了 dackh 创建的主题 › 程序员 › Spring 多数据源事务问题

分布式事务或改队列

2019 年 10 月 22 日

回复了 h82258652 创建的主题 › 程序员 › 采取 RESTful 风格的 api 是否应该对结果包一层？

@yamedie 我觉得短信 70xx 的代码无任何存在的意义, 用户不关心错误代码是什么, 前端拿到错误代码也不做任务处理, 何必花时间与精力去维护越来越多的错误代码呢? 服务端写返回的时候还要去查代码是不是已经存在了. 这种错误包括但不限于: xx 输入不合法, xx 未填写, 校验不通过, 提交失败等统一一个非 0 的 code 即可如 code: -1, 可适用于绝大部分的逻辑中断返回

2019 年 10 月 22 日

回复了 h82258652 创建的主题 › 程序员 › 采取 RESTful 风格的 api 是否应该对结果包一层？

把 Http 状态码再自己包装一层, 我个人觉得是没意义的事. 但是自定义 code 我是一直在用的, 并且就楼里所说, 我觉得什么情况下错误码够用? 你要自己去思考. 我在给公司设计错误代码规范的时候是规定, 如果前端需要服务端返回特定的 code 码来处理一些后续逻辑, 则给固定一个唯一的, 如果不需要, 仅仅是错误提示, 只要统一的错误码即可. 错误码在大部分情况下对前端及用户来说是无任何意义的(除非你想跟踪问题, 但是跟踪问题, 日志就可以了). 当然这种情况在写开放 api 接口的时候会参考 A,T 的错误码

2019 年 10 月 15 日

回复了 UserNameisNull 创建的主题 › 程序员 › 请教一个问题，多实例同时删除 key 怎么解决

赞同 5 楼的做法. 实际还是分布式问题, 如果想避免, 则考虑下刷新 access token 的工作给开一个队列消息, 然后无论是 zk, kafka, rabbitmq 等, 都会自己寻找一个可用有效的节点去刷新. 有时候可以用消息队列来规避掉分布式的问题

1 2 3

❮

❯