[ Java ] 代码质量糟糕, 是常态吗?

是，尤其是快速迭代的

@featureoverload

从问题来说，代码质量糟糕在当下确实是常态。

我上一家公司代码质量很高，入职新公司加入的项目代码质量差距明显。

但是代码质量高的代价是，程序员周一提交一个 MR ，反复 code review 周五才有机会 Merge
（很多时候会往复两周）

当然，根据程序员自身水平，这个时间可长可短；通常在 三天到一周 左右。

被 code review 过的程序员，提交的 code 在三天以下被 Merge 的，
通常已经过了需要被频繁提 comment 的能力阶段了；
这时候的 code review 的时间，通常不是花在代码质量上。

继承的屎山不敢改。 。也没时间改。。

我把一个 shi 山项目重构了，当时也是为了后续自己维护方便
然后就 TM 的测出了两个逻辑 BUG ，就在那 BBBBBBBBB ，搞的我好像罪大恶极，没事找事
这种事情之后我是不会再干了，无脑往上堆吧

只要你跟着 java 更新，就不会屎

@msg7086 对，他的代码质量是非常好的，我说的是可维护性以及新人上手成本的问题，我之前进去看过，可能调用层级比较深了，突然一个 ruleDealFunc.apply(param) 还要回去找这个 Function 哪传进来的，虽然逻辑上看的很顺，但是要修改，需要追实现细节的时候会比较痛苦

@bthulu 自己写的当然能维护，但是整个工程不可能一直是一个人维护啊，总有要别人顶班的时候

@potatowish 问题这是个业务模块啊，本质上也是个模版方法或者策略模式就能解决的问题

@ragnaroks 可以在发布流水线上设卡点，静态扫描不过关不给发

我实习的时候，负责开发智能电视平台上兼容多个品牌遥控器按键映射的组件，多个键值对应同一个功能的话，可以简单清晰地罗列 case ，然后下面统一操作再 break 。代码写完后交给一个人 review ，他说每个 case 必须有 break ，否则肯定无法编译通过，而且他 10 年工作过程中都是这么认为的……

我比较认同的是，水平烂的人，用啥高大上语言写出来的代码都一样烂。

我想，Java 技术栈在这个问题上比较显眼的原因可能有以下几点：
1. Java 开发者实在太多了，Web 后端开发领域 Java 开发者数量很长时间都是第一，假设大多语言的水平分布都是差不多的，那么 Java 技术栈这种基数大的就比较吃亏，会让人产生经常遇见水平差的人的感觉。
2. Java 生态非常成熟，在语言基础上建立了各种框架、体系、思想的高楼，表层都是非常抽象的东西，（在 SSH 框架的时代）导致学习周期较长，虽然门槛低，但若想达到对生产所使用的技术完全在掌握的程度，可能要比很多技术栈多花很多的时间。导致可能没有那么多精力关注其他事情。当然现在随着一些新的框架和思想的出现，这个问题可能会逐渐改善。
3. 一门语言越灵活和抽象，开发门槛越低，但对开发者要求也就越高；写出能工作的代码很容易，写出来能工作的好代码很难，不如一些本身有很多限制和枷锁的语言。鱼与熊掌不可兼得。

最大的原因还是因为 java 太流行了，写的人太多，每种语言中都有菜鸟，而 java 门槛低，所以菜鸟占比就相对多，再加上幸存者偏差，所以你对 java 的感觉不好。js 同理。
比如（相对）小众的语言，go ，rust ，你是不是没有发现什么烂代码？实际上是因为，第一门槛高，第二用的人少，而其中菜鸟占比也少，大佬占比多，很多都是极客，所以你能看到的都是高质量代码。
实际上关键还是在于人。

和语言没关系，主要还是要看团队水平和有什么样的领导

A 司应该是比较少的，说明团队整体水平很好，可能是领导不是做技术的
B 司就不说了，懂得都懂，能干活的就那几个人，甚至是外包进来的
C 司项目外包更简单了，能用就行，反正不管后期维护
D 司研发团队应该是不多不少的那种情况，人力刚好满足现在的业务，但又什么都想尝试，可又没有足够的人力来支持

没有代码审计的小团队国企政企应该比较多，研发就几个人也都是干活的，领导可能就不是做技术的，代码野蛮生长，也会出现大量代码的 copy

@soupu626 现在还有不会函数式编程的 java 新人么? 是个培训班都教这个, 不会的只可能是放弃学习的老油条了吧

我接手的一个项目更垃圾,接口返回信息直接 json.put("xx",111),然后连个注释都没有,全靠英文单词猜

要说代码质量，首先要搞清楚什么样的代码是高质量的代码。

咱们经常提的 SOLID 原则是衡量 OO 范式的代码质量的一种。

不过 SOLID 的局限性比较大。Thoughtworks 最近在技术雷达上推荐 CUPID 是另一个可参考的好代码的特质组合。

CUPID 是指：
- C: Composable ，可组合的代码
- U: Unix philosophy ，符合 Unix 哲学
- P: Predictable ，可预测的
- I: Idiomatic ，符合惯例的
- D: Domain based ，基于领域的

我前段时间结合 CUPID 原文及自己的理解，写了一篇文章分享，给大家参考下： https://brightliao.com/2022/05/24/5-properties-of-good-code-cupid/

有了什么是高质量代码的基本理解，再去看代码质量好不好，我们会发现新大陆。

与其说 Java 烂，不如说是业务系统代码烂。。
每个业务系统都会有各种奇奇怪怪的业务需求，各种修修补补 ，各种 if else ,演进个半年一年的，啥语言写都是烂。。

开源出来的东西最多能算业务系统第一个版本。。当然可以写的很漂亮。。你让把你们公司的特殊业务逻辑加里面再看看

本来周三要上线的，结果都延期三次了，今天产品都还在提了一堆修改，你说呢，这跟语言有关系吗，跟个人能力有关系，但也跟团队有关系，重大关系，压根不给你足够的时间去回头梳理，我只能是一边做新需求一边看看哪些需要重构的顺手重构一下，再跟测试说一下

我只说 java 的哈
请面向金钱编程！
只要满足客户需求，产生价值，所谓的代码质量，UT 覆盖率都是虚的，除了耗费你的时间别无用处。

补充一点。以前讲瀑布，现在推敏捷，养活了多少人，以前说 TDD ，现在又推 DDD ，又浪费了多少码农时间。重构！千万别去碰！要么继续堆，要么新项目重开！切记！

大部分公司都是业务第一、产品第二、技术第三。
想赚钱就得快速迭代，持续交付，跟语言毛关系没有，用其他语言照样一堆屎山，甚至比 Java 更屎（尤其动态语言），屎到维护不了，有的内存泄漏满天飞，还有存在 this != null 这种逆天操作。

业务本身就没逻辑可言，代码也就只能 if-else 。如果业务迭代得快的话，代码写出来的时候指不定就已经过时了。

@litguy 哈哈，毕竟写底层可不是开玩笑的，一出问题肯定被骂死😂。
@yulon 建议重构😂😂同样的时间，我宁愿重写也不愿接烂摊子😂

A 这类比较少，说明团队整体水平很好，可能是领导不是做技术的。
B 大概率是外包的，只能好一点的外包
C 是质量更差的外包。
D 是那种在夹缝中生存的团队，现有功能满足了，想加新的但人手不够。

先不说代码质量，有几个正经写 Unit Test 的？ 出来走一个让我看看
理由无非是老三样： 没时间、能跑就行、质量高了工资高吗？

---

都说项目质量差、加班加的多，我也没见几个人（还是有不少，起码认识不少有态度的），愿意倒推流程、质量、进度、需求的。

一个团队，一环差，环环差，木桶原理。