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

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

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

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

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

@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 起标题的能力看来，这项目还是别动了

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

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