首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Coding
V2EX  ›  程序员

辩论吧 新技术 到底会不会代替老技术

  •  
  •   pence2019 · 28 天前 via iPhone · 2832 次点击
    top leader 发一个这个给我
    公司现在是 jdk6 tomcat6 老系统陷入焦油坑 我是改革派


    从头开始再写一遍并不意味着你会写出比以前更好的代码。因为你没有参与到上一个版本的创建,所以你其实根本就不算有经验。一旦你准备推倒重写,你可能会再犯一遍版本一犯过的错,甚至会产生更多的新问题。

    面对糟糕的旧代码,Keep Calm & Carry On !

    在大型商业项目中,推倒重来是非常危险的行为。当然,如果你是在做实验,想到新算法可以随时重写。

    如果你跳槽、或刚接手一个新项目,面对看上去异常混乱的旧代码,请冷静下来,忍住推倒重写的冲动。
    35 回复  |  直到 2019-11-21 10:48:19 +08:00
        1
    momocraft   28 天前
    重写和新技术甚至不是一个维度的问题
        2
    aabbcc112233   28 天前 via Android
    老项目很大的话,就别想重构了,除非上面有指示或者不得不。只能尽量优化。
        3
    crayygy   28 天前 via iPhone
    这其实并不是一个非黑即白的问题,并不是说用了新技术就不能继续用老技术,如果架构做得好,可以做到逐步替换,并且通过测试来保证业务一致性
        4
    murmur   28 天前
    java 其实是个很特殊的例子,因为这语言构建了一个覆盖各种场景的帝国,无论是类库、框架、工具都太成熟,就算你不依赖语言的新特性,配合宇宙第二的 IDE,也能有不错的开发体验
    但是很多语言没这个待遇
        5
    pence2019   28 天前 via iPhone
    @murmir
    @crayygy
    @aabbcc112233
    @momocraft

    代码 没有注释 开发没有文档 数据库没有文档
    oracle windows 服务器 cvs 版本控制器 jsp

    没有用任何框架
        6
    securityCoding   28 天前
    先做前后端分离 , 然后起新的服务逐步重构重要接口,一口一口吃肉,不要一把梭压力会很大
        7
    sagaxu   28 天前
    从 6 升级到 8 应该没那么困难,先升级到 8,然后才有继续重构的资格
        8
    skyrem   28 天前
    你可以建议 TDD (测试驱动开发)
    先照着老框架写一遍单元测试
    再以通过单元测试为基准写新代码
        9
    hantsy   28 天前
    比你这个更差的情况遇到过。

    几年前,客户的一个老项目迁移,多个 Dephi 程序,Borland Firebird 数据库迁移到 JavaEE 5 (当时最新的标准),JBoss Seam2/EJB 3,JSF/Richfaces,JPA/Hibhernate/MySQL/, 用户界面(从 Dephi 的桌面界面到 Web 界面),功能几乎一致,数据库(最费力的部分)由一个程序员写一个单独的程序迁移的。代码从头开始写的,分十个 Sprints 完成,历时大半年。后来又升级到 Java EE6,Seam3/CDI, 这个过程相对比较平滑些,数据库没有费力,加入了些一些新功能模块。

    公司自己有开发人员的,我想不明白这个项目神一样停留在 Java6 (应该大约在 10 几年了) 时代。

    这样下去,你这个项目如果这样一直下去,旧的技术栈用的人越来越少的时候,后面几乎很难找到人去维护的时候,还是要推倒重来。目前仅仅是各版本老一点,在理解需求的情况,可以尝试一步步分功能模块的,升级到最新的技术栈上(比如 java 11,最近的 LTS 版本, 全部 Java 8 以后的语法 等),比如一个阶段替换一部分功能,需要你有全局把握的能力,在很长一段时间项目能够做到新旧代码共存。
        10
    marsgt   28 天前
    系统化抽象的最简模型:
    输入->[处理]->输出
    在保持输出不变的基础上,简化输入和处理流程,从而达到节省成本的目的,那么则重构成功。
    说起来容易做起来难,屎山一般都是一个黑盒,里边是盘根错节的互相牵制,牵一发而动全身,动全身而功败垂成。
    这是生物学上复杂性系统 /复杂系统的概念。
    你的既有知识会形成你认知的障碍,具体化会阻止你抽象化的思维。这是佛教概念(所知障)。
    新技术会不会替代老技术?我不知道。但你的重构如果能转化为成本优势,那么说不定你能说服老板支持你。
        11
    visonme   28 天前
    我们一般都是局部替代,而且是非常小心的,TO B 应用。

    旧技术某种程度不会被新技术代替,但是更新 /变革肯定是存在的,毕竟业务在不断的增长,需求在不断的改变,很多旧技术在系统的问题越来越凸显,只是说推到重来是不可能的,这个代价不是一般公司可以承受的,一般都是局部先更新,做到完全替代是需要很长时间的。
        12
    hantsy   28 天前
    摆在我面前的话,我隐约的觉得这是实践 Microservice 一个好机会。

    1. 一部分功能按 Bounded Context 划分,使用新的 Service 重写。涉及数据库的,也重新创建相应的数据库,迁移数据。
    2. 旧代码通过 REST/HTTP, Message Broker 与新的 Service 交互,使之能完全替代旧的代码功能。
    3. 删除那部分旧代码,删除那部分旧数据库内容。
    4. 循环 1-3 步。可能你一个业务的 Serivce 迁移过程就要几个月。先挑个软柿子,比如不需要数据库的,邮件,通知,消息通信等等比较边缘的功能入手。

    完全断代的代码或迁移或者架构的过程很痛苦,特别是正在使用的系统,要保持新旧一致性,对于用户而言数据不能遗失,用户体验要更好。

    整个过程痛并快乐着。
        13
    rainbowchou   28 天前
    技术百分百是业务驱动的,业务有相应的需求才会有新技术出现解决问题。
    你业务没有变化或者业务体量预测不会爆发,凭啥要引进新技术,稳定使用压倒一切
    一切看业务
        14
    liuzhiyong   27 天前
    只要能用,就不要大改,这是我的看法。
        15
    szyp   27 天前 via iPhone
    @murmur 宇宙第二和第一的 ide 是什么?
        16
    murmur   27 天前
    @szyp idea 系列是第二 vs (不是 code )是第一
        17
    mazyi   27 天前
    失去竞争力就完事了,你想一直写 6 的语法么?
        18
    crackhopper   27 天前
    一般都是重写吧。架构治理一下。一般才坑都是业务的坑。所以只要业务强的架构师重新规划几个服务,重写好,然后逐步替换上线就 OK 了。关键是你们公司有没有足够的营收能支撑你们重写架构。
        19
    newtype0092   27 天前
    看过的书上的话:假设你投入一定的时间去优化目前稳定的项目,如果不能为现有业务带来相应的收益增长,那么你实际上对项目进行了一次负优化
        20
    c0878   27 天前
    这种项目对简历加分毫无帮助 尽早脱身
        21
    xuanbg   27 天前
    老的项目能正常运行的话,就不要横生枝节去折腾它了,除非你闲得慌。

    当老项目需要增加新功能,支持新需求,并且是相对比较大的改动的时候,才是拆解它的良机。把新功能相关的部分从老的项目中分离出来,并且丢弃它。然后新建一个新的项目来完整地实现新功能以及相关的旧功能。

    如果实在是没法拆,那就完全丢弃重写吧。
        22
    wujunze   27 天前
    业务优先 稳定第一 慢慢改造 因地制宜 循序渐进
        23
    crayygy   27 天前 via iPhone
    @c0878 你错了,这种项目做得好才是简历加分的好机会,就看有没有能力啃下这块骨头
        24
    AGEGG   27 天前
    开了个新接口,算是项目重构了,历时 4 周,自己完成了大概 80%快收尾了,每天各种忙,也没空摸鱼
    优点是对业务掌握度 max,清楚了解了各种模块,对一套系统有了比较清晰的认识。
    缺单很明显是工作量大,之后还有巨量测试,还要联调,耗时与收获不成正比
    但感觉重构真心没必要,自己把自己新的想法写进自己的开源小 demo 就好
        25
    dnsaq   27 天前 via iPhone
    还在用着几十年前的开发语言,怎么不自己开发一种语言,想想你们都觉得 low
        26
    morphyhu   27 天前
    个人认为现有系统能满足需求的话,完全没必要使用最新的技术。有时间,有精力,有资金的话可以考虑使用新技术研发新系统来替代
        27
    helionzzz   27 天前   ♥ 1
    既然旧技术和新技术是为了达到同一个目的,那它们就不应该是对立的,而是统一的。即能达成目的就是最好的技术。
        28
    mxT52CRuqR6o5   27 天前 via Android
    要不要新技术看老系统的需求了,如果老系统已经不需要进行什么新需求开发,仅仅是要修 bug 那就不要使用新技术,成本大收益低。反之如果是一个仍然需要不断迭代不断开发新需求的的老系统,那用新技术是有一定必要的。重构其实可以配置好路由慢慢重构
        29
    mxT52CRuqR6o5   27 天前 via Android
    @mxT52CRuqR6o5 只要方法得当,风险都是可控的
        30
    pence2019   27 天前
    @securityCoding 计划是前后端分离 但是现在管理能力和技术实力跟不上,top leader 怕翻船
    @sagaxu top leader 现在连升级到 jdk8 的计划都没有,
    @skyrem TDD 就是先写单元测试,然后开发的意思吗?
    @hantsy 我本身推荐新功能模块用 jdk8 单独的业务中台去做,也被否决了,我认为公司现在就是陷于焦油坑 代码模块互相影响 依赖
    @marsgt input process output you are right but top leader 但是老板担心的还是风险
    @visonme 是呀 我现在就是在了解老的技术框架,有韩国 SK C&C & QAD 的代码,其他都裸体存在的代码,
    @rainbowchou Oracle Windows CVS 要不要迁移到 Linux Mysql GIT 那?
    @liuzhiyong 同意的看法 现在就是 jdk6 tomcat6 cvs oracle windows
    @szyp myeclipse 第一生产力估计是 idea 了
    @mazyi 公司现在就是在慢慢失去竞争力,关键是 cto 还意识不到 或者 cto 学习 spring boot linux 的成本就高了
    @crackhopper 没有决心 信心 怎么重写。一起都是为了完成某个具体的功能而来,产出产出产出
    @c0878 又有几个能力挽狂澜的人
    @xuanbg 现在我的 idea 就是不要横生枝节去折腾它
    @wujunze 感觉无边无际的大海也帮助不了我呀,循序渐进的项目有几个成功的。
    @mxT52CRuqR6o5 maven activiti git linux mysql 要不要用
    @helionzzz 理想很丰满 现实很骨感
    @morphyhu 没有时间 没有精力 没有资金
    @dnsaq cto 感觉 spring 也不牛 也没有多高深的,还不如用原生的,但是自己也写不出来框架
    @AGEGG 太难了 重构现在几乎不可能。
        31
    skyrem   27 天前
    @pence2019 #30 Test Driven Development
    中文是测试驱动开发,网上有很多资料,可以自己搜索下
        32
    janus77   27 天前
    首先改不改不是一个必然的问题,是成本和后果的互相博弈
    你这种情况,考虑一下灰度测试啊
    先开个分支你自己改,也不需要全改,只需要改一部分。期间坑必须是你自己来踩
    然后公司内部使用和外部小范围使用,运行一段时间了看情况
    如果有效果 leader 会看到的,不用你说
        33
    hantsy   27 天前
    @pence2019 cvs,oracle-> git, MySQL 本身就是一个需要跨越的鸿沟,对团队来讲 Git 完全改变协作方式。数据库,如果使用了大量的 Oracle 特性(特有的 Function,Proceducer ),也是个大问题,你可能必须要写专门的程序去导数据,比如用 Spring batch,或者 JavaEE Batch 去实现大量 ETL 操作。

    对于目前存在的程序,有大量用户和数据,稳妥的方法,只能一部分一部分功能逐步的迁移,比起完全重写工作量会很大,可能翻倍,最大的痛处需要兼顾旧程序,保持数据一致性,不能破坏程序的功能。在代码迁移过程也是对业务重新认识的一个过程,可以有机会让你的重新衡量过去的技术与业务结合是否合理,同时,可以慢慢清理一些技术债务问题,永远保持新的代码新鲜,没有 Code Smell。

    等所有功能迁移完毕(用户可能感觉不到什么变化,但是程序代码脱胎换骨,已经完全迁移到新的架构,语言,框架上等),接下来再考虑 UX 的升级,比如前后端分离,使用 SPA 重新构建页面,重新考虑用户体验。
        34
    chenyu8674   26 天前
    从 LZ 起标题的能力看来,这项目还是别动了
        35
    nnnToTnnn   24 天前
    新技术一定会替换掉老技术,这个不必质疑。

    只不过到底是逐步替换还是说一刀切的问题
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2312 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 26ms · UTC 10:20 · PVG 18:20 · LAX 02:20 · JFK 05:20
    ♥ Do have faith in what you're doing.