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

重写和新技术甚至不是一个维度的问题

老项目很大的话，就别想重构了，除非上面有指示或者不得不。只能尽量优化。

这其实并不是一个非黑即白的问题，并不是说用了新技术就不能继续用老技术，如果架构做得好，可以做到逐步替换，并且通过测试来保证业务一致性

java 其实是个很特殊的例子，因为这语言构建了一个覆盖各种场景的帝国，无论是类库、框架、工具都太成熟，就算你不依赖语言的新特性，配合宇宙第二的 IDE，也能有不错的开发体验
但是很多语言没这个待遇

@murmir
@crayygy
@aabbcc112233
@momocraft

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

没有用任何框架

先做前后端分离 , 然后起新的服务逐步重构重要接口,一口一口吃肉,不要一把梭压力会很大

从 6 升级到 8 应该没那么困难，先升级到 8，然后才有继续重构的资格

你可以建议 TDD （测试驱动开发）
先照着老框架写一遍单元测试
再以通过单元测试为基准写新代码

比你这个更差的情况遇到过。

几年前，客户的一个老项目迁移，多个 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 以后的语法 等），比如一个阶段替换一部分功能，需要你有全局把握的能力，在很长一段时间项目能够做到新旧代码共存。

系统化抽象的最简模型：
输入->[处理]->输出
在保持输出不变的基础上，简化输入和处理流程，从而达到节省成本的目的，那么则重构成功。
说起来容易做起来难，屎山一般都是一个黑盒，里边是盘根错节的互相牵制，牵一发而动全身，动全身而功败垂成。
这是生物学上复杂性系统 /复杂系统的概念。
你的既有知识会形成你认知的障碍，具体化会阻止你抽象化的思维。这是佛教概念（所知障）。
新技术会不会替代老技术？我不知道。但你的重构如果能转化为成本优势，那么说不定你能说服老板支持你。

我们一般都是局部替代，而且是非常小心的，TO B 应用。

旧技术某种程度不会被新技术代替，但是更新 /变革肯定是存在的，毕竟业务在不断的增长，需求在不断的改变，很多旧技术在系统的问题越来越凸显，只是说推到重来是不可能的，这个代价不是一般公司可以承受的，一般都是局部先更新，做到完全替代是需要很长时间的。

摆在我面前的话，我隐约的觉得这是实践 Microservice 一个好机会。

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

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

整个过程痛并快乐着。

技术百分百是业务驱动的，业务有相应的需求才会有新技术出现解决问题。
你业务没有变化或者业务体量预测不会爆发，凭啥要引进新技术，稳定使用压倒一切
一切看业务

只要能用，就不要大改，这是我的看法。

@murmur 宇宙第二和第一的 ide 是什么？

@szyp idea 系列是第二 vs （不是 code ）是第一

失去竞争力就完事了，你想一直写 6 的语法么？

一般都是重写吧。架构治理一下。一般才坑都是业务的坑。所以只要业务强的架构师重新规划几个服务，重写好，然后逐步替换上线就 OK 了。关键是你们公司有没有足够的营收能支撑你们重写架构。

看过的书上的话：假设你投入一定的时间去优化目前稳定的项目，如果不能为现有业务带来相应的收益增长，那么你实际上对项目进行了一次负优化

这种项目对简历加分毫无帮助 尽早脱身

老的项目能正常运行的话，就不要横生枝节去折腾它了，除非你闲得慌。

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

如果实在是没法拆，那就完全丢弃重写吧。

业务优先 稳定第一 慢慢改造 因地制宜 循序渐进

@c0878 你错了，这种项目做得好才是简历加分的好机会，就看有没有能力啃下这块骨头

开了个新接口，算是项目重构了，历时 4 周，自己完成了大概 80%快收尾了，每天各种忙，也没空摸鱼
优点是对业务掌握度 max，清楚了解了各种模块，对一套系统有了比较清晰的认识。
缺单很明显是工作量大，之后还有巨量测试，还要联调，耗时与收获不成正比
但感觉重构真心没必要，自己把自己新的想法写进自己的开源小 demo 就好

还在用着几十年前的开发语言，怎么不自己开发一种语言，想想你们都觉得 low

个人认为现有系统能满足需求的话，完全没必要使用最新的技术。有时间，有精力，有资金的话可以考虑使用新技术研发新系统来替代

既然旧技术和新技术是为了达到同一个目的，那它们就不应该是对立的，而是统一的。即能达成目的就是最好的技术。

要不要新技术看老系统的需求了，如果老系统已经不需要进行什么新需求开发，仅仅是要修 bug 那就不要使用新技术，成本大收益低。反之如果一个仍然需要不断迭代不断开发新需求的的老系统，那用新技术是有一定必要的。重构其实可以配置好路由慢慢重构

@mxT52CRuqR6o5 只要方法得当，风险都是可控的

@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 太难了 重构现在几乎不可能。

@pence2019 #30 Test Driven Development
中文是测试驱动开发，网上有很多资料，可以自己搜索下

首先改不改不是一个必然的问题，是成本和后果的互相博弈
你这种情况，考虑一下灰度测试啊
先开个分支你自己改，也不需要全改，只需要改一部分。期间坑必须是你自己来踩
然后公司内部使用和外部小范围使用，运行一段时间了看情况
如果有效果 leader 会看到的，不用你说

@pence2019 cvs,oracle-> git, MySQL 本身就是一个需要跨越的鸿沟，对团队来讲 Git 完全改变协作方式。数据库，如果使用了大量的 Oracle 特性（特有的 Function，Proceducer ），也是个大问题，你可能必须要写专门的程序去导数据，比如用 Spring batch,或者 JavaEE Batch 去实现大量 ETL 操作。

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

等所有功能迁移完毕（用户可能感觉不到什么变化，但是程序代码脱胎换骨，已经完全迁移到新的架构，语言，框架上等），接下来再考虑 UX 的升级，比如前后端分离，使用 SPA 重新构建页面，重新考虑用户体验。

从 LZ 起标题的能力看来，这项目还是别动了

新技术一定会替换掉老技术，这个不必质疑。

只不过到底是逐步替换还是说一刀切的问题