Home Sign Up Sign In
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
pence2019
V2EX  ›  程序员

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

  •   
  •   pence2019 · Nov 17, 2019 via iPhone · 5353 views
    This topic created in 2395 days ago, the information mentioned may be changed or developed.
    top leader 发一个这个给我
    公司现在是 jdk6 tomcat6 老系统陷入焦油坑 我是改革派


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

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

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

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

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

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

    几年前，客户的一个老项目迁移，多个 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 以后的语法 等），比如一个阶段替换一部分功能，需要你有全局把握的能力，在很长一段时间项目能够做到新旧代码共存。
    marsgt
        10
    marsgt  
       Nov 17, 2019
    系统化抽象的最简模型：
    输入->[处理]->输出
    在保持输出不变的基础上，简化输入和处理流程，从而达到节省成本的目的，那么则重构成功。
    说起来容易做起来难，屎山一般都是一个黑盒，里边是盘根错节的互相牵制，牵一发而动全身，动全身而功败垂成。
    这是生物学上复杂性系统 /复杂系统的概念。
    你的既有知识会形成你认知的障碍，具体化会阻止你抽象化的思维。这是佛教概念（所知障）。
    新技术会不会替代老技术？我不知道。但你的重构如果能转化为成本优势，那么说不定你能说服老板支持你。
    visonme
        11
    visonme  
       Nov 17, 2019
    我们一般都是局部替代，而且是非常小心的，TO B 应用。

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

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

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

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

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

    如果实在是没法拆，那就完全丢弃重写吧。
    wujunze
        22
    wujunze  
       Nov 17, 2019
    业务优先 稳定第一 慢慢改造 因地制宜 循序渐进
    crayygy
        23
    crayygy  
       Nov 17, 2019 via iPhone
    @c0878 你错了，这种项目做得好才是简历加分的好机会，就看有没有能力啃下这块骨头
    AGEGG
        24
    AGEGG  
       Nov 17, 2019
    开了个新接口，算是项目重构了，历时 4 周，自己完成了大概 80%快收尾了，每天各种忙，也没空摸鱼
    优点是对业务掌握度 max，清楚了解了各种模块，对一套系统有了比较清晰的认识。
    缺单很明显是工作量大，之后还有巨量测试，还要联调，耗时与收获不成正比
    但感觉重构真心没必要，自己把自己新的想法写进自己的开源小 demo 就好
    dnsaq
        25
    dnsaq  
       Nov 18, 2019 via iPhone
    还在用着几十年前的开发语言，怎么不自己开发一种语言，想想你们都觉得 low
    morphyhu
        26
    morphyhu  
       Nov 18, 2019
    个人认为现有系统能满足需求的话，完全没必要使用最新的技术。有时间，有精力，有资金的话可以考虑使用新技术研发新系统来替代
    helionzzz
        27
    helionzzz  
       Nov 18, 2019   ❤️ 1
    既然旧技术和新技术是为了达到同一个目的，那它们就不应该是对立的，而是统一的。即能达成目的就是最好的技术。
    mxT52CRuqR6o5
        28
    mxT52CRuqR6o5  
       Nov 18, 2019 via Android
    要不要新技术看老系统的需求了，如果老系统已经不需要进行什么新需求开发，仅仅是要修 bug 那就不要使用新技术，成本大收益低。反之如果是一个仍然需要不断迭代不断开发新需求的的老系统，那用新技术是有一定必要的。重构其实可以配置好路由慢慢重构
    mxT52CRuqR6o5
        29
    mxT52CRuqR6o5  
       Nov 18, 2019 via Android
    @mxT52CRuqR6o5 只要方法得当，风险都是可控的
    pence2019
        30
    pence2019  
    OP
       Nov 18, 2019
    @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 太难了 重构现在几乎不可能。
    skyrem
        31
    skyrem  
       Nov 18, 2019
    @pence2019 #30 Test Driven Development
    中文是测试驱动开发，网上有很多资料，可以自己搜索下
    rb6221
        32
    rb6221  
       Nov 18, 2019
    首先改不改不是一个必然的问题，是成本和后果的互相博弈
    你这种情况，考虑一下灰度测试啊
    先开个分支你自己改，也不需要全改，只需要改一部分。期间坑必须是你自己来踩
    然后公司内部使用和外部小范围使用，运行一段时间了看情况
    如果有效果 leader 会看到的，不用你说
    hantsy
        33
    hantsy  
       Nov 18, 2019
    @pence2019 cvs,oracle-> git, MySQL 本身就是一个需要跨越的鸿沟，对团队来讲 Git 完全改变协作方式。数据库，如果使用了大量的 Oracle 特性（特有的 Function，Proceducer ），也是个大问题，你可能必须要写专门的程序去导数据，比如用 Spring batch,或者 JavaEE Batch 去实现大量 ETL 操作。

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

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

    只不过到底是逐步替换还是说一刀切的问题
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   5444 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 124ms · UTC 08:01 · PVG 16:01 · LAX 01:01 · JFK 04:01
    ♥ Do have faith in what you're doing.