V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
wh469012917
V2EX  ›  程序员

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

  •  
  •   wh469012917 · 2021-09-03 15:22:39 +08:00 · 9640 次点击
    这是一个创建于 1214 天前的主题,其中的信息可能已经有所发展或是发生改变。

    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. 数据软删除也是配置错误,然后自己代码中去维护,写的乱七八糟

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

    1  2  
    wh469012917
        101
    wh469012917  
    OP
       2021-09-04 11:59:34 +08:00 via iPhone
    @gancl 那请问,怎么记录一条收货地址,是哪个用户的?至少地址表上要有一个 user_id 字段吧?
    wh469012917
        102
    wh469012917  
    OP
       2021-09-04 12:01:09 +08:00 via iPhone
    @JamesR 这个是小项目,也不急,周期三个月,总共就 10 来张数据表的增删改查,没有什么特殊的逻辑,前期他一人开发的
    wh469012917
        103
    wh469012917  
    OP
       2021-09-04 12:04:52 +08:00 via iPhone
    @hallDrawnel 这个同事资历比较老,呆了有四五年了,leader 就算知道也不好意思说他。而且领导自己并不写代码,主要还是把控进度和稳定性,所以不好推动
    wh469012917
        104
    wh469012917  
    OP
       2021-09-04 12:06:27 +08:00 via iPhone
    @bintianbaihua 对的,首先做好自己的事,然后在力所能及的范围内做点小的重构,求稳为主
    gancl
        105
    gancl  
       2021-09-04 14:03:50 +08:00
    @wh469012917 我以为你使用 mysql 的外键关联?
    kingwang
        106
    kingwang  
       2021-09-04 14:56:48 +08:00
    @wh469012917 每周把写的代码 review 下。不是那种 sonar,checkstyle 之类的。而是每个人把自己做的业务讲一遍。红红脸,出出汗,后面就长记性了。
    wangxin13g
        107
    wangxin13g  
       2021-09-04 15:00:46 +08:00
    format 代码
    活用 idea 的重构功能改掉所有命名


    如果你写的不是 java 的话当我没说,赶紧跑路。
    tiktokxxxx2020
        108
    tiktokxxxx2020  
       2021-09-04 20:38:07 +08:00
    @wh469012917 正确的做法是选择不吃,按你的说法,既然别人都喂屎给你吃了,你还在这想怎么吃能香一点?
    wh469012917
        109
    wh469012917  
    OP
       2021-09-05 22:38:03 +08:00
    @gancl 不会,只会保存字段,具体的关联代码中处理;不过这人把关联字段用逗号拼接成字符串,特么的啥都做不了了
    wh469012917
        110
    wh469012917  
    OP
       2021-09-05 22:39:10 +08:00
    @tiktokxxxx2020 我不想吃,但是我要领这份工资,所以身不由已。领导说这个项目你接受,难道你能说代码太烂了我接手不了
    wh469012917
        111
    wh469012917  
    OP
       2021-09-05 22:39:40 +08:00
    @wangxin13g 命名都是小问题,一会就改好了,关键是数据库设计和逻辑实现烂
    wh469012917
        112
    wh469012917  
    OP
       2021-09-05 22:41:19 +08:00
    @fengpan567 无,代码评审推不动
    wh469012917
        113
    wh469012917  
    OP
       2021-09-05 22:41:43 +08:00
    @potatowish 外包都比这好
    neptuno
        114
    neptuno  
       2021-09-06 10:07:55 +08:00
    @wh469012917 所以只改命名问题就好了,数据库本来就很乱的,习惯就好了,每个厂都有自己的规范,每个人都习惯自己的明明方式。包容一下吧,业务逻辑建议也不要改,有需求了再重构
    wh469012917
        115
    wh469012917  
    OP
       2021-09-06 18:40:19 +08:00
    @neptuno 道理其实都懂,毕竟大家都是打工人。最大的问题就是数据库设计不合理,这样我后续开发起来,进度会拖很久
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   976 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 21:17 · PVG 05:17 · LAX 13:17 · JFK 16:17
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.