新来的同事写的代码，两年半工作经验，一个 CURD 功能写了一星期，今天看了 git commit ，我不做评论，各位看官看吧

槽点太多，无从下手

你们公司还招人吗

不懂 java ，但我觉得注释不行

试用期就是给这种贵物准备的。

面试的人呢？拖出去枪毙十分钟。

这咋面试过的

前端表示看不懂，没学过 java ，有人解释一下吗

这不写的挺好的嘛，map 入参减少新建一个类的麻烦。
现在两年半经验约等于零经验。培训班出来都是两年经验起步

update = 获取，我英语是跟体育老师学的么

用 map 充分考虑到了 api 的扩展性，没毛病，建议全司推广🐶️

你们公司还招人吗

硬是把面对对象概念按在地上打

我怀疑除了方法里面的内容，其他的都是从别的地方拷贝过来的。。。

map 一把梭 要啥 get 啥

前端看到接口名会不会心里会不会**

1.map 做参数是不太好, 但是也有实际应用场景
2.return null 问题比较大, 这里应该抛异常然后全局处理异常, 或者用 ApiResult.error()
3.equal 写的不规范容易空指针异常
4.id 没有判空, 也容易空指针

http method -》 post
func name -》 update
service func name -》 get

好家伙，差点就集齐神龙了

他是不是你工资比你高?

这是高手，要写让人一看就懂的代码，无论是初学者还是架构师，而不是写炫技的代码。

估计是复制粘贴忘了改

这是传说中的参数封装吧

也许槽点在于，写了一星期

自信点，怀疑两个字去掉

这个没看出问题来。。。

我看懂了,但我还是大受震撼

不大懂。map 参数不判 null 么？

那倒不至于

第一行 if 可能抛两个 npe
哈哈哈

颇有异曲同工之妙

他们会说你是精神资本家

槽点是挺多的。。。

入参 map 一时爽，后期维护惨。 前面的 return null 前端怎么知道要干嘛。 后面的 return 都知道回个 success 。

那就让他们和这种贵物一块干活，给他擦屁股吧。

项目中有类似的代码（不是他提交的） ？

方法名不太合适、参数用 map 也不太合适、equals 按照上面那样写容易空指针、除特殊情况下方法最好不要返回 null 这些是我看出来的 不知道别的还有没有

第一次见到这种，代码已经全部打回重写了

回复错人了 不好意思

槽点很多，map 传参、返回值不规范、校验可以用注解……

工资估计高于楼主吧

参数用 map ，后续估计想死的心都有了。
CRUD 一个星期倒不是啥问题，有可能刚入职，很多不清楚，要熟悉一下。只是上面的 map 槽点就真是没法理解了。

PS：我厂，某养猪的，定义的接口就是一个 dict （ python 语言），作为一个 javaer ，真是受不了。虽然前期方便，但后续真的是坑爹啊。

既然用 map 接参，那就应该继续用 map 反参🐶

公司新来的四年工作经验大佬，变量定义 300+行，两个 for 循环，每个循环 1000+行，一个业务 2300+行代码😦

比起网友怎么看，楼主你的领导和同事怎么看，如果他们没啥看法，那么该离职的人应该是楼主自己哦......

我是管他们的人

不是我面的，漏网之鱼

又不是不能用

面试的人要负很大责任

哈哈哈,领导竟是我自己

团队没有制定开发规范吗？

这种基础 crud 代码不应该建好表后，直接用代码生成器生成吗？ 5 分钟搞定

我写了文档的，文档详细说明了开发规范，他全部避开了

我比较好奇这注释。。。

这种没法用 Swagger ，难受, 并且这注释还不如没注释

以前不理解为啥开发盯着屏幕能笑得这么欢乐，看这个代码真的处处充满欢乐

年底因代码提交量最多而升职

这个应该要统一封装返回数据的格式吧。出现 null ，也好统一处理呀

md ，看到 map 传参血压都上来了

这两年半经验是包装出来的吗？

有必要这样对我吗，自己几斤几两不知道吗？

python 同学表示这不正常吗？ Java 里正常应该用啥传参？ DTO ？

培训班出来的

而且是班里的差生

现在培训班教出来的都不会用 map 传参

我觉得不是培训班出来的..培训班出来的起码知道面向对象

这也行？

入参怎么还用 map ，而且为啥用 Object 当 Value ？？？？

真的不容易，能够在短短几行出现这么多问题:
1.获取数据推荐使用 GET 方法
2.方法名称有问题
3.参数传值使用 map
4.参数校验和返回有问题
5.注释有问题

尴尬 我居然觉得没啥问题

为啥不能用 map 啊，我们在做少代码，入参都是变的，那不用 map 用 object 么，而且 body 以 json 过来不就是个 map 么

图挂了

＃69
因为 map 的可维护性很差

因为别人要猜这个葫芦里装的是什么屎。。。

做了参数检测，自己组合到 map 没问题

python 也可以用 object 的，比如 pydantic 或者基本的 dataclass

很好奇，工资多少？
如果没过 10k ，那就当作没看到，能跑就行了。
如果过了 10k ，那就可以直接劝退了！

越是高手在写代码时越是谨慎，经过反复推敲后写出最精简、干练的代码。

哈哈

kotlin 用久了都忘了要处理空指针异常了🤣

＃72 笑死了

我以为.net 这边烂人多，没想到 java 那边的高手更厉害[狗头]
之前见过 dynamic 随处飘的，但至少命名还算是个正常人，楼主你这个同事的思维就贼离谱

你负责 review 代码？如果不是，领导没说话，咱就干好自己的活

动态语言写多了甚至第一眼没觉得违和 (

1.代码看上去是复制粘贴的，但是注释和方法名没改
2.参数用 map
3.equals 比较错误
4.接口返回结果混乱，前面返回 null ，后面返回 ApiResult
但凡有个一年经验的外包也不至于写成这样，建议直接辞退，不然以后会埋很多坑

python 写多了，扫一眼只觉得函数名和注释不规范(狗头

现在开除还来及

有就不错了

能跑起来就行了，管那么多啊

你给我说说维护性差在哪里？张口就来

我们这里也有一个这样，还好代码后续不是我维护的。还有用 String 接请求，然后手动 json 解析成 map 。

怼上去就完了

看开，能跑就行

＃87
1.swagger(或者类似的自动生成 api 文档工具)没法用，除非手写注解生成或者维护一份 api 接口文档，参数更新的时候也要维护
2.产生一堆魔法值同样是难以维护的
3.后续接手代码的人还要一个一个去查找参数

＃87
倒是想你给我说说维护性好在哪

＃91
第一条还要补充一下，按照截图中的注释说明以及大部分程序员的习惯（包括我），怕是做不到手工维护 API 文档

代码和他两个任意一个能跑就行：

代码可以跑，他没跑，你们可以把他按倒地上摩擦；
代码不能跑，他跑了，代码可以把你们按在地上摩擦；

不对啊，用 swagger 肯定是原来代码里面就这样的啊，也不是他引入的

维护性好不好是相对的，如果根本就没有维护的必要，要那么好的维护性干嘛

看着好像没什么问题

＃96
这是项目代码不是个人小玩具，如果你无意提高自己编码质量的话说再多也没用，总能找到反驳的理由

他试用期要是能过，劳资立马转行

最大的问题是 return null 吧，接口要返回明确的错误信息

其他的地方，Java 程序员当然看不下去，但是如果这人原来是写 python 或 php 之类的，就好像看上去并没有什么问题。不过也说明至少不是 Java 熟练工了，各种 VO ，DTO 之类的玩得少