
点击蓝字 关注并设为星标
更多精彩内容每日送达
给刚开始的线上实习生做代码评审,发现有一个同学在返回给前端的Response DO 对象里面,又额外套了一层VO 对象。
我就问他:“为什么要多加一层?没有任何逻辑的增加,就好像是脱裤子放屁。”

他说看很多课程讲,VO 是给前端看的,可以更好地保证项目的规范。
听完我就晕了。我说:“是不是课程里说了一堆的 O—— 什么 DO、DTO、VO、PO?”
实际上,大部分所谓的规范,都是培训机构为了证明自己的东西好,强加的理论。
大部分项目都不用 VO,因为本身返回给前端的内容就已经是封装好的。你多加一层,不管是后端还是前端,都是没有任何作用的;不加这一层,也不会影响后端的维护或者迭代。
这就好像,有的实习生上来写代码,就开始写错误码枚举。我说:“这不扯淡吗?”C 端业务一般都要迭代多年,一个 API 可能就有 3-5 条错误提示,而且这些错误大部分都只是跟当前的接口逻辑有关。
那项目运行三年,可能会有上千个 API,也就是五千个错误码。以后还能正常写代码吗?每次写代码都要去这五千个错误码里找一下,有没有相同的?
实际上,这些错误提示就是给前端反馈问题用的,没有其他的用处。所以,写错误码根本没有意义,更没有把它抛出为异常的意义。
但反过来说,也不是绝对没有用 VO 的场景。有,比如说外包一类的项目,有可能因为交付的代码规范里有这个强制要求。
但是,这种情况并不是常规操作。包括错误码,一般 B 端的外包项目才会用到,不要把少量的使用场景当作正常标准。
像有些同学的简历描述里,写着 “C 端业务使用异常和错误码”,甚至写 “使用 VO”,这个本身就是错误的。

项目推荐
项目