1. 命名不规范
   一个项目中控制器命名能出现好几种变形，一个对的都没有：
   UserContol 、UserControl 、UserContoler 、UserControler

包括模型也是：
UserMode 、UserModle 、UserModol

变量命名更是离谱，单字母和语言关键字乱用：
a 、b 、c 、class 、string 、byte
再然后就是缩写和语意不符合的：

context 缩写成 c
UserImage 缩写成 ui
template 写成了 temple

数据表和模型名称不一样的：

表名叫做 user_rule, 模型名叫做 RuleUserModle
表名叫做 order_mgr，模型名叫做 OrderManageMode
表名叫做 order_manage，模型名叫做 OrderMgr

因为命名不规范，他后面出现了很多删除 A 表的数据，却用了 B 表的模型来操作，导致错删～
字段名称和值不统一的：

创建时间字段 creat_time 、create_time 、created 、created_time 每个表都不一样
而且值有保存时间戳，有的保存时间字符串

2. 业务代码
   如果说命名混乱就算了，至少比较好改，但是业务实现也混乱：

没有任何封装概念，重复代码都是直接复制粘贴；没有任何分层的概念，控制器-模型一把梭过去，一个控制器方法 300 行起步
getUserById(string username) 命名叫做通过 ID 查询用户，传入的参数却是 username
getUserList() 命名叫做获取用户列表，返回值却是某一个特定条件的单个用户
所有的请求都不做参数验证，并且也不做逻辑验证。删除操作，都没判断用户是否有权限删除，直接给他删除了，删除了还不算，有些关联的数据不删除，这一下子就出现了一堆的脏数据
查询启用状态的用户列表，先把所有用户拉出来，然后在代码中遍历循环过滤禁用的用户

3. 数据库设计
   数据库设计更混乱不多说了，就说几点：

关联的外键命名没有任何规范，全凭心情；比如订单表上正常情况下要有一个用户 id 字段(一般命名为 user_id)，他这个字段命名叫做 user_order，要么就是叫做 user_function，反正就是自己看得懂
以上好歹设计了外键，有些干脆不设计外键；用户收货地址表上，正常情况要有一个 user_id, 用来标记这个地址是哪个用户的；他直接在用户表上创建了一个 addres 的字段，然后把地址表的 ID 用逗号分隔拼接成字符串，保存到用户表上，每次查询用户地址列表都是取出来分割，然后一条条去查；删除就更暴力了，直接删除地址，用户表的 addres 字段都不更新
orm 默认都支持维护数据的创建时间，以及数据的软删除; 但是他因为创建时间字段命名不规范，orm 默认维护的是 created_at 字段，他表设计是 creat_time，然后在模型中配置的字段又是 create_time，导致框架不会维护，于是就全部自己实现
数据软删除也是配置错误，然后自己代码中去维护，写的乱七八糟

公司同事写的代码，是我这么多年来见到的最烂的代码，但是因为人家来的年限资历比较长，也不好意思去提这个事情，有没有啥好的办法，自己重构吗？

各玩各的，项目管理不说话就装哑巴。

反馈给管事的人解决

你不是领导就不要多嘴

不用你接手，就当做没看到

关键是我接手了，不然谁管他写的是啥玩意

换同事

看的我都不会写模型名了

我也不想多嘴，关键是这个项目我接手了，恶心到人了

看了几天我自己都写错了

这么烂的代码，技术负责人如果没有发声的话，那就想一下公司给的钱，有没有足够到让你天天坐在屎边上的地步。如果没有，还呆着干吗？

既然交到自己手上了，那就有时间的时候一点点改过来么

曾经也因为类似的原因开了一个 repo 专门记录工作中遇到的经典操作...

github.com/parrotdance/worst_code_I_saw

另外"看了几天我自己都写错了"真是太艹了

快跑

领导不指示，千万别自己重构。不然最后这个屎山塌了你要负责。

和你这个一比，我突然觉得之前同事用拼音缩写命名方法变得不是那么屎了

我就想知道你同事怎么用关键字命名变量

把吐槽的话憋在心里或者写在注释里，除非王八退房

我就写过很多垃圾代码,我现在也还在不断的输出垃圾代码,虽然我从不以写垃圾代码为荣为耻,但我还是依然在写垃圾代码.不为了什么.只是为了混口饭吃...
顺便看了一下 lz 帖子记录...emmmmm

你是来搞钱的，不是来搞人的，不是你的下属最好不要乱说话，过来人经验。

习惯就好，我同事可以把一个功能写在几个模块里面，乱放。

领导注重功能完成和稳定性，其他的没怎么关心过

我现在也是，命名什么的自己慢慢调过来，但是不做大改，特别是数据库，免得背锅

对的，我也是只敢做基本的命名调整等等，数据库设计碰都不碰；那个同事倒是说要是觉得设计不合理可以改，不过我不敢动

拼音好歹是正常的命名啊，猜猜也能看得懂，我们这边直接用 class byte string 做变量名了

string := "foo" byte := "bar" 这样，go 语言允许用关键词做变量名，但是 ide 会给你提示

你可以学学我这个帖子里面的垃圾代码，看看能不能更上一层楼

那肯定的，我当然不可能傻到去说人家，也不会去找领导打小报告，反正在屎上堆屎就行了

感觉像是说我的同事，idea 都有单词提示的，他就是要写错的，代码各种复制粘贴，能不公用就不公用。
一个 Controller 接口能连续写 1000 行，代码文件随随便便就是 4000+行，导致我 idea 卡到爆，打一个空格 cpu 能飙 100%持续好几秒。
注释和实际执行是相反的
try catch 不捕获异常，控制台、日志、 出参全看不到具体错误
用 JSONObject 作为 json 入参接收，如果是表单提交 那好，形参列表十几二十个家常便饭，包括 service 调用也是十几个形参
调用其他第三方接口，手写 json 字符串 + 号拼接（很多参数）
配置写死在代码里，上线出问题，就改代码继续发
分页查询：计算总条数时，select * ... 然后 list.size() 获取总条数，再计算页数（计算这段代码复制了 n 次，也没抽出来）。
还有很多不想说了

差点被同化了

让大家 review 代码咯，不要干自己重构这种傻事

我觉得和自己也有关系，一般和同事的水平是上下五厘米 /狗头

团队人也不多，代码审核估计推行不开

笑死，看的血压上来了

怕不是看了如何写出无人能维护的代码那篇文章正在深刻实践

service 层代码行 2000+倒是很正常

这不是我遇到的事情吗
大半年过去了，同事已经拍拍屁股离职好几个月了，我依然时不时还得为了他遗留的代码擦屁股。。。

反正我接手第一件事：CodeFormat，连换行、空格都不规范看着太痛苦了
第二件事就是规范命名，先把乱七八糟没根据意义起名或者拼写混乱的都改了
然后接着才是慢慢梳理代码……抽出方法，合适的时候直接重构部分模块。都是有空的时候搞搞，确定这块后续还有需求的才改，不然加班都改不完

论 code review 的重要性 [滑稽]

本人非程序员。
以前 C＃代码我看着别人写 String,我就问他怎么不写成原型的 string 。他跟我说 String 比较快。
后来我知道技术领队都是让老手先检查一下那人的代码。我就释然了。实际上他会的东西比我多。
要是以前遇到你写的这样的情况，我早就跑了。

代价就是有些大的模块，我只是拆了部分重构之后，屎山有点坍塌的趋势，已经出现好几个原来没有的 bug，复现规律还没找到……摊手。可能回头差不多了直接推倒重构了。

解决不了问题，那就解决制造问题的人

笑死了

同事：这样公司就离不开我了

快跑

我一个前端写的 java 代码估计比他规范~~囧

能跑就行(

重构吧，这就跟定时炸弹一样，拖着拖着哪天就爆了。

重构，有 ide 在 symbol 命名替换应该容易

命名很重构，配合 IDE 搞起来很快，关键在于数据库结构和业务逻辑实现，不敢碰

他是不是把《如何书写不可维护代码》当圣经

实在想不通，他代码烂和你也没太大关系，反正以后吃亏的是他....

要么忍要么滚，之前我前公司的一个项目就是这样的，项目在我之前 4 个人接手过，每个人的方式都一样，三套代码风格，一下子驼峰，一下子下划线，一下子又一起来，然后我干不到 1 个月就走人了

类似问题我一般都回：能用就行。

但你这遇到的也太屎了……

看到 ui 缩写惊呆了

代码和人有一个能跑就行

提桶跑路

不改数据库，改变量名和类名吧，至少两边名字一样，数据库各种字段不一样也改不动

🙈 我的 StringBuilder 简写为 sb

坚持不挖屎坑给别人，也从不接别人的屎坑。

还不走？

拉个群，加上你上司和你同事，有问题群里直说。

好家伙，自带混淆。

这不是代码不行
这是英文问题

感觉你说的是我同事

血压升高

换个公司

因为我要接手这个项目，咋就没关系了，这就好比别人拉了一坨屎，然后让你吃下去，你说有没有关系呢

不忍也不滚，会根据情况慢慢重构，然后委婉的提一些建设性的调整意见，如果别人能接受最好，接受不了就不提了，各干各的

命名问题好改啊，配合 IDE 一下子就 ok 了，关键的是数据库，这个是个大难题

我一同事也是，xxxId 和 xxxid 混用，同样功能不能内容的列表字段主键用不同的，个人信息头像用 headIcon，他人的用 avatar，本来几个 model 就能搞定，结果写十来个各种继承，而且搞的我各种条件判断，最后太乱了，一模一样的页面我复制两三份。

项目开工前，我都用协作工具把字段和功能逻辑大致的确定了，结果就他框架方便，我这各种蛋疼。

而且你这个好歹是命名问题，不难改，数据库和业务逻辑垃圾，改都改不了这个才可怕

复制粘贴这事
看公司代码中有一串数字 85399，不是很理解为什么，然后猜测了下，估计是查询一天的范围的数据
想查 今天 0 点～今天+86400-1 来着，写错成 85399

然后一堆人复制这段代码，全局搜了三四处不同人写的

头像是本人吗。
如果是本人，你说的都对。

这很难说，文人相轻， 码农也相轻；
代码烂一半责任在负责人，一半在程序员；

这个必须要离职啊

想一想，为什么会成为同事

六字真言，要么忍要么滚

估计还是没分析器的时候，现在装了分析器后会提示此处该用 Int32 还是 int 等等

就三个字：不要管。你只能控制你自己，别人你也管不了，干脆就不要看😂😂😂
大家都是在大💩山上拉小💩堆，哈哈哈，just works 就行了😂😂😂

开会鉴赏一下

没有代码评审吗

心疼你 50ns

千万别离职，这岗位祸害人

这种操作很明显是外包的做法，别问我怎么知道的，各种骚操作让人又好气又好笑

这也太随意了吧，他自己看着不难受吗

如果需求需要改动到旧代码，就跟 leader 说明情况，适度重构一小片代码出来，脱离原有的路径，隔离出一个范围自己开发。
如果是新的功能，做非侵入式修改，然后把逻辑嵌入到旧代码里。

然后写个文档充分说明这个情况，把风险尽量告知相关人，不然出了事情还得背锅。推动 code review，当然有的 leader 自己就很菜，他根本没办法区分什么是好代码什么是坏代码，只是风起飞了把这只猪给吹上去了。

改着改着自己变成那个风格哈哈哈哈

使用工具，不符合基本规则不让 push 。有条件上 code review 。实话说很影响效率，没见小公司执行这套方案的

是不是键盘太脏了，有些键有时候按下去不出字符？

感同身受😂😂

经历过 ，建议不要随便重构。也不要随便怼人， 做好自己的事情就好了。。

还行，不算烂，至少能看懂。
当年他写的时候，没人教他怎么写，老板，客户又催得急，只能这样了。

怎么还看不到 有一个能跑就行（ doge

....自己复制自己的代码这种操作都不管吗？？？？？

这样的代码 就有点烂的过分了

不设计外键是对的啊

你就一个 crud 的，就这还指点江山，有那时间看看开源项目吧，觉得自己牛看看 flink，spark，k8s，tidb 的代码。我相信你自己就变 shutup

心惊胆战的点进来，怕说的就是我。还好不是-.-

他格式化时间成字符串，不是用语言的时间库的，而是自己计算～

不积跬步，无以至千里

不积跬步，无以至千里，基础的代码质量都搞不好，还能搞得好什么呢