同事代码写的太烂了怎么办？

[wh469012917]

1. 命名不规范

一个项目中控制器命名能出现好几种变形，一个对的都没有：

UserContol 、UserControl 、UserContoler 、UserControler

包括模型也是：

UserMode 、UserModle 、UserModol

变量命名更是离谱，单字母和语言关键字乱用：

a 、b 、c 、class 、string 、byte 

再然后就是缩写和语意不符合的：

1. context 缩写成 c
2. UserImage 缩写成 ui
3. template 写成了 temple

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

1. 表名叫做 user_rule, 模型名叫做 RuleUserModle
2. 表名叫做 order_mgr，模型名叫做 OrderManageMode
3. 表名叫做 order_manage，模型名叫做 OrderMgr

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

字段名称和值不统一的：

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

2. 业务代码

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

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

3. 数据库设计

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

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

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

[wh469012917]

@gancl 那请问，怎么记录一条收货地址，是哪个用户的？至少地址表上要有一个 user_id 字段吧？

[wh469012917]

@JamesR 这个是小项目，也不急，周期三个月，总共就 10 来张数据表的增删改查，没有什么特殊的逻辑，前期他一人开发的

[wh469012917]

@hallDrawnel 这个同事资历比较老，呆了有四五年了，leader 就算知道也不好意思说他。而且领导自己并不写代码，主要还是把控进度和稳定性，所以不好推动

[wh469012917]

@bintianbaihua 对的，首先做好自己的事，然后在力所能及的范围内做点小的重构，求稳为主

[gancl]

@wh469012917 我以为你使用 mysql 的外键关联?

[kingwang]

@wh469012917 每周把写的代码 review 下。不是那种 sonar，checkstyle 之类的。而是每个人把自己做的业务讲一遍。红红脸，出出汗，后面就长记性了。

[wangxin13g]

format 代码
活用 idea 的重构功能改掉所有命名


如果你写的不是 java 的话当我没说，赶紧跑路。

[tiktokxxxx2020]

@wh469012917 正确的做法是选择不吃，按你的说法，既然别人都喂屎给你吃了，你还在这想怎么吃能香一点？

[wh469012917]

@gancl 不会，只会保存字段，具体的关联代码中处理；不过这人把关联字段用逗号拼接成字符串，特么的啥都做不了了

[wh469012917]

@tiktokxxxx2020 我不想吃，但是我要领这份工资，所以身不由已。领导说这个项目你接受，难道你能说代码太烂了我接手不了

[wh469012917]

@wangxin13g 命名都是小问题，一会就改好了，关键是数据库设计和逻辑实现烂

[wh469012917]

@fengpan567 无，代码评审推不动

[wh469012917]

@potatowish 外包都比这好

[neptuno]

@wh469012917 所以只改命名问题就好了，数据库本来就很乱的，习惯就好了，每个厂都有自己的规范，每个人都习惯自己的明明方式。包容一下吧，业务逻辑建议也不要改，有需求了再重构

[wh469012917]

@neptuno 道理其实都懂，毕竟大家都是打工人。最大的问题就是数据库设计不合理，这样我后续开发起来，进度会拖很久