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

改 legacy code 改到想吐

  •  
  •   nthhdy ·
    workingenius · 2022-01-20 11:47:35 +08:00 · 4613 次点击
    这是一个创建于 1067 天前的主题,其中的信息可能已经有所发展或是发生改变。

    各种纠缠,无从下手。 尝试改了几次,都遇到了想不清的逻辑,被推翻了。 现在想起这分布在各处的几千行逻辑,就想避开,想不进去。 甚至越来越埋怨、厌恶这写代码的历代作者。 最近一个的还是我 leader 。危险了。 同事不试着解扣,还在把里面代码复制出来删删改改当新功能。

    为什么我要纠结?因为目前给我的任务也是要在上面加新功能,另一个新功能。 还老得防着我们代码冲突。

    想听听你们的类似经历。 欢迎吐槽调侃,更欢迎有效见解、解决之道。

    第 1 条附言  ·  2022-01-20 13:23:13 +08:00
    leader 跟我讲,“要是我的话,三天就改完了”。
    真的怀疑,到底是我能力不行,还是历史原因。

    我觉得他提的修改思路有道理,但都太宏观,具体做起来还是会踩屎,最终还得穿墙打洞想办法擦干净。
    43 条回复    2022-01-24 15:09:01 +08:00
    kytrun
        1
    kytrun  
       2022-01-20 12:53:08 +08:00   ❤️ 3
    想让我从一摊 shit 熬成香喷喷的米饭,我做不到,要么重写,要么告辞
    KaynW
        2
    KaynW  
       2022-01-20 12:53:35 +08:00
    重写,替换
    IsaacYoung
        3
    IsaacYoung  
       2022-01-20 12:58:42 +08:00 via iPhone
    跑路
    golangLover
        4
    golangLover  
       2022-01-20 13:03:07 +08:00 via Android
    v2ex 的网友会告诉你继续堆屎山,不要想太多。因为好代码设计是没用的,快速迭代才是正确的。
    nthhdy
        5
    nthhdy  
    OP
       2022-01-20 13:16:40 +08:00
    @golangLover 快速迭代不起来。测试太依赖环境,没有自动化测试。
    wangtian2020
        6
    wangtian2020  
       2022-01-20 13:23:44 +08:00   ❤️ 1
    领导和老板去谈了业务就把项目签了,然后回来说项目要拿老代码改。
    谈项目不问开发人员呵呵,开发前中期我提了无数遍要重写,领导不同意。
    jquery 代码写的又臭又长,一千行能写完的逻辑,因为老技术架构、设计不合理、实习生团队(代码,产品)作品的原因,写了五六千行,而且理所当然的没有文档。只剩臭业务逻辑的项目,没什么意思。
    正好那段时间我从老板的 PUA 中醒了过来,提出离职,离职前的一个月给他们用 vue 糊了个大概就拜拜咯。我精湛的代码技巧不是为了在廉价的情况下给实习生代码补漏洞加逻辑而生的。
    ospider
        7
    ospider  
       2022-01-20 13:29:43 +08:00
    《修改代码的艺术》 https://book.douban.com/subject/2248759/
    nthhdy
        8
    nthhdy  
    OP
       2022-01-20 13:32:07 +08:00
    @ospider 多谢,读一下
    kindjeff
        9
    kindjeff  
       2022-01-20 13:50:41 +08:00
    我选择跑路。过几天就 last day 了
    lightjiao
        10
    lightjiao  
       2022-01-20 13:57:50 +08:00
    有相同的经历,不过硬是看完了,也做了小规模重构,有一些大的东西改不动,也没时间改

    不要怀疑自己的水平,好的代码至少结构是清晰的、说明或注释是完整的,代码到处复制粘贴,一个函数调好几遍,那就是代码写得烂
    lagoon
        11
    lagoon  
       2022-01-20 14:09:50 +08:00
    "越来越埋怨、厌恶这写代码的历代作者"

    哎,其实也想为实际的作者说说话。
    比如我现在,时间越来越紧,要求越来越模糊,大脑成了一片浆糊。
    我怎么办?我只能选择堆屎山了。
    kiroter
        12
    kiroter  
       2022-01-20 14:15:45 +08:00
    别听你 leader 的 B 话,他拉的屎他当知道咋擦了
    MoYi123
        13
    MoYi123  
       2022-01-20 14:17:16 +08:00
    @lagoon 我挺无法理解为什么有人认为复制粘贴代码或者写逻辑混乱的代码能让编码速度或者说交付时间变快的.
    nthhdy
        14
    nthhdy  
    OP
       2022-01-20 14:40:45 +08:00
    @lagoon 你说的对,当然理解,我自己当然也堆过烂代码。

    不过到自己手里之后还是心情很糟。
    nthhdy
        15
    nthhdy  
    OP
       2022-01-20 14:42:05 +08:00
    @lagoon @MoYi123

    感觉写出烂代码,有的时候其实是需求不清楚,想做什么、达到什么目的没想明白。倒不是一味追求眼前的快。
    golangLover
        16
    golangLover  
       2022-01-20 14:42:31 +08:00 via Android
    @nthhdy 快速迭代的意思是写得快,尽快跑起来。
    iColdCat
        17
    iColdCat  
       2022-01-20 14:44:14 +08:00
    “要是我的话,三天就改完了”

    跑路
    7gugu
        18
    7gugu  
       2022-01-20 14:47:04 +08:00
    继续写💩山代码,把问题丢给后人解决。我估计这种💩山除非系统炸裂,或者项目组解散,不然都没啥机会让你重写的了,毕竟又不是不能跑。
    mx8Y3o5w3M70LC4y
        19
    mx8Y3o5w3M70LC4y  
       2022-01-20 14:50:40 +08:00   ❤️ 1
    我最近也在改 legacy code ,我是做移动端的,写了一长段时间的 js 了,现在改的是安卓代码。

    我现在在公司每次打开 Android Studio 都觉得有一阵恶心眩晕感,像是 ptsd 了。

    每次看到一个一个的 activity 动辄 3 、4k 行,一个一个 xml 1 、2k 行代码,我都能想到红楼梦里林黛玉唱葬花吟的场景:天~尽——头~~何——处——有香丘~~~
    pengtdyd
        20
    pengtdyd  
       2022-01-20 15:14:21 +08:00
    要是我的话,三天就改完了 能说这句话的 leader 和垃圾没啥区别
    richangfan
        21
    richangfan  
       2022-01-20 15:18:19 +08:00   ❤️ 1
    简单,看不懂的代码给他删了
    xuxuzhaozhao
        22
    xuxuzhaozhao  
       2022-01-20 15:42:15 +08:00
    @lvdb #19 痛苦啊~~~~
    wu67
        23
    wu67  
       2022-01-20 15:46:49 +08:00
    自己写的代码, 当然知道怎么改. 好歹思路能相通, 大体规律自己心里有底.
    但是读别人写的代码就不一样了, 看着难受是真的难受, 改不动的是真改不动...
    wu67
        24
    wu67  
       2022-01-20 15:48:00 +08:00
    总结起来就是不写注释就是坑. 就算代码写得再好、命名再规范再语义化, 读别人的代码时, 都会面临减智 30%的 debuff 的...
    jdhao
        25
    jdhao  
       2022-01-20 15:49:30 +08:00 via Android
    @lvdb 😂 有画面感了。地铁老人手机
    keepeye
        26
    keepeye  
       2022-01-20 15:54:50 +08:00
    我没见过哪个项目因为重构而复活的,要么中途放弃了,要么项目本身已经不行了,重构也没屌用甚至会把最后一口气给折腾没了
    JDog
        27
    JDog  
       2022-01-20 16:00:55 +08:00
    "新人和老人的区别就是面对一坨屎山,新人会大吃一斤。老人会贤淑的避开最臭的那部分屎,然后灵巧的在保证屎山不垮的情况下把自己的屎再拉一层上去"
    qping
        28
    qping  
       2022-01-20 16:01:56 +08:00
    最应该做的是最小代价修改

    但我做不到,强迫症,只要我用过的代码肯定是一路重构过去,哪怕看到自己之前的代码,也会想:写的是什么玩意,明明可以更简单
    h82258652
        29
    h82258652  
       2022-01-20 16:04:33 +08:00
    改不动就跑呗,形成屎山的最大原因还不是这群领导不做代码审阅
    3dwelcome
        30
    3dwelcome  
       2022-01-20 16:30:50 +08:00
    我发现领导都有个共性,就是改改旧代码,工程就能以最低成本研发出来。

    但是副作用,就是代码太长,日后很不好维护。

    有时候自己写代码,会提醒自己要非常克制,尽量解耦。让简单代码变复杂,只需要无脑写就可以了。而让复杂代码变简单,那就是很困难的事情。

    引用一句话:聪明的程序员,如果改不动现在 BUG ,就创造出一个没有 BUG 的新世界。
    sampeng
        31
    sampeng  
       2022-01-20 16:31:56 +08:00   ❤️ 1
    大部分(包括我自己)所谓重构就是堆新的屎山,这没什么稀奇的。但是自己拉的屎自己闻着香。
    JamesR
        32
    JamesR  
       2022-01-20 16:44:34 +08:00   ❤️ 2
    @wangtian2020 #6 修改前人写得烂尾项目,里面是漏洞百出的代码,同时给他修各种千奇百怪的 Bug ,这种工作意义究竟在哪?
    别人问你工作是干什么,绝大多数人羞于说出口,因为实际上是给老板和他前员工生产的劣质产品做修修补补的,这种工作原本就不应该存在才对。
    nthhdy
        33
    nthhdy  
    OP
       2022-01-20 18:42:44 +08:00
    @sampeng 让自己和别人读着都舒服,都容易懂,这么难么
    nthhdy
        34
    nthhdy  
    OP
       2022-01-20 18:44:40 +08:00
    劝跑路的都是哥们儿~
    redford42
        35
    redford42  
       2022-01-20 21:32:32 +08:00
    我也在改
    操了。
    redford42
        36
    redford42  
       2022-01-20 23:06:37 +08:00
    六年前的代码
    估计是当时大环境问题
    第三方接口返回都不判断 code
    cogitoxin
        37
    cogitoxin  
       2022-01-20 23:31:13 +08:00
    目前也在搞屎山,感觉一般是重写比改快……
    msg7086
        38
    msg7086  
       2022-01-21 03:02:26 +08:00
    一般要保证屎山能用,至少要同一个组里至少几个人审过看过。
    这样至少是一堆人都能接受的屎,而不是一个人的屎。
    zxjunz
        39
    zxjunz  
       2022-01-21 08:57:49 +08:00
    新手才想着怎么去重构,老手只想着在不动屎山的前提下在上面再拉一泡屎
    nthhdy
        40
    nthhdy  
    OP
       2022-01-21 12:05:01 +08:00
    @7gugu @keepeye @JDog @zxjunz

    各位说的都是不做大改,尽量保证不影响之前的,在巧妙地加新代码。说说我的分析。
    这样做,肯定会导致越来越改不动,越是后人日子就越难过;不做大改,终将拖死大家。
    如果在拖死大家之前,项目就因为别的原因黄了,那不用做大改,都一样。
    如果是因为改不动,迭代太慢或者 bug 百出而导致项目黄,那就要考虑做大改了。
    如果是因为开始大改,然后把自己改死,项目黄了,那只能说大改做得太晚了。
    都劝我不大改,因为各方面都过硬,能坚持到最后的项目太少了。久经考验的项目没几个。
    7gugu
        41
    7gugu  
       2022-01-21 12:50:04 +08:00
    @nthhdy 就是这么个理,尽量能别动就别动,重写肯定是对的,但要付出几倍的时间去梳理。除非老板让你立项重写,不然为啥自己要自我感动,搞不好还要被喷。如果代码都是这么💩的话,就趁早跑路吧,这东西对于新人来说已经趋近无解了。
    lilihangzhou
        42
    lilihangzhou  
       2022-01-24 13:44:29 +08:00
    为这事跟领导闹得很不愉快,他的说法是重构这种事他不会支持,但是你还得做。一股子阿里味,我 TM 呵呵,打算年后跑路了,屎上雕花这种事,臣妾做不到
    nthhdy
        43
    nthhdy  
    OP
       2022-01-24 15:09:01 +08:00
    领导不支持,但是你还得做
    是什么逻辑
    见识了

    @lilihangzhou
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   995 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 18:47 · PVG 02:47 · LAX 10:47 · JFK 13:47
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.