优秀的后端应该有哪些开发习惯？( 三 ) _后端

这样就相当于

在 coupon-api 抛出异常
在 coupon-api 拦截异常，修改 Response.code
在调用方判断 response.code 如果是 FAIELD 再把异常抛出去......

你直接在服务提供方抛异常不就行了么。。。而且这样一包装 HTTP 请求永远都是 200，没法做重试和监控。当然这个问题涉及到接口响应体该如何设计，目前网上大多是三种流派

接口响应状态一律 200
接口响应状态遵从HTTP真实状态
佛系开发，领导怎么说就怎么做

不接受反驳，我推荐使用 HTTP 标准状态。特定场景包括参数校验失败等一律使用 400 给前端弹 toast 。下篇文章会阐述一律 200 的坏处。
写有意义的方法注释这种注释你写出来是怕后面接手的人瞎么......
/*** 请求电话验证** @param credentialNum* @param callback* @param param* @return PhoneVerifyResult*/复制代码要么就别写，要么就在后面加上描述......写这样的注释被 IDEA 报一堆警告看着蛋疼
和前端交互的 DTO 对象命名什么 VO、BO、DTO、PO 我倒真是觉得没有那么大必要分那么详细，至少我们在和前端交互的时候类名要起的合适，不要直接用映射数据库的类返回给前端，这会返回很多不必要的信息，如果有敏感信息还要特殊处理。
推荐的做法是接受前端请求的类定义为 XxxRequest，响应的定义为 XxxResponse 。以订单为例：接受保存更新订单信息的实体类可以定义为 OrderRequest，订单查询响应定义为 OrderResponse，订单的查询条件请求定义为 OrderQueryRequest 。
尽量别让 IDEA 报警我是很反感看到 IDEA 代码窗口一串警告的，非常难受。因为有警告就代表代码还可以优化，或者说存在问题。前几天捕捉了一个团队内部的小bug，其实本来和我没有关系，但是同事都在一头雾水的看外面的业务判断为什么走的分支不对，我一眼就扫到了问题。

文章插图

因为 java 中整数字面量都是 int 类型，到集合中就变成了 Integer，然后 stepId 点上去一看是 long 类型，在集合中就是 Long，那这个 contains 妥妥的返回 false，都不是一个类型。
你看如果注重到警告，鼠标移过去看一眼提示就清楚了，少了一个生产 bug 。
尽可能使用新技术组件我觉得这是一个程序员应该具备的素养......反正我是喜欢用新的技术组件，因为新的技术组件出现必定是解决旧技术组件的不足，而且作为一个技术人员我们应该要与时俱进~~ 当然前提是要做好准备工作，不能无脑升级。举个最简单的例子，Java 17 都出来了，新项目现在还有人用 Date 来处理日期时间...... 都什么年代了你还在用 Date
结语本篇文章简单介绍我日常开发的习惯，当然仅是作者自己的见解。暂时只想到这几点，以后发现其他的会更新。
如果这篇文章对你有帮助，记得点赞加关注！你的支持就是我继续创作的动力！