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

[pence2019]

top leader 发一个这个给我
公司现在是 jdk6 tomcat6 老系统陷入焦油坑 我是改革派


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

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

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

如果你跳槽、或刚接手一个新项目，面对看上去异常混乱的旧代码，请冷静下来，忍住推倒重写的冲动。

[momocraft]

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

[aabbcc112233]

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

[crayygy]

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

[murmur]

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

[pence2019]

@murmir
@crayygy
@aabbcc112233
@momocraft

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

没有用任何框架

[securityCoding]

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

[sagaxu]

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

[skyrem]

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

[hantsy]

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

几年前，客户的一个老项目迁移，多个 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]

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

[visonme]

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

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

[hantsy]

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

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

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

整个过程痛并快乐着。

[rainbowchou]

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

[liuzhiyong]

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

[szyp]

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

[murmur]

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

[mazyi]

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

[crackhopper]

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

[newtype0092]

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

[c0878]

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