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，导致框架不会维护，于是就全部自己实现
- 数据软删除也是配置错误，然后自己代码中去维护，写的乱七八糟
公司同事写的代码，是我这么多年来见到的最烂的代码，但是因为人家来的年限资历比较长，也不好意思去提这个事情，有没有啥好的办法，自己重构吗？