这是一个创建于 1831 天前的主题，其中的信息可能已经有所发展或是发生改变。
top leader 发一个这个给我
公司现在是 jdk6 tomcat6 老系统陷入焦油坑 我是改革派
从头开始再写一遍并不意味着你会写出比以前更好的代码。因为你没有参与到上一个版本的创建，所以你其实根本就不算有经验。一旦你准备推倒重写，你可能会再犯一遍版本一犯过的错，甚至会产生更多的新问题。
面对糟糕的旧代码，Keep Calm & Carry On !
在大型商业项目中，推倒重来是非常危险的行为。当然，如果你是在做实验，想到新算法可以随时重写。
如果你跳槽、或刚接手一个新项目，面对看上去异常混乱的旧代码，请冷静下来，忍住推倒重写的冲动。
公司现在是 jdk6 tomcat6 老系统陷入焦油坑 我是改革派
从头开始再写一遍并不意味着你会写出比以前更好的代码。因为你没有参与到上一个版本的创建，所以你其实根本就不算有经验。一旦你准备推倒重写，你可能会再犯一遍版本一犯过的错，甚至会产生更多的新问题。
面对糟糕的旧代码，Keep Calm & Carry On !
在大型商业项目中，推倒重来是非常危险的行为。当然，如果你是在做实验，想到新算法可以随时重写。
如果你跳槽、或刚接手一个新项目，面对看上去异常混乱的旧代码，请冷静下来，忍住推倒重写的冲动。
 |
1
momocraft 2019-11-17 15:29:01 +08:00
重写和新技术甚至不是一个维度的问题
|
 |
2
aabbcc112233 2019-11-17 15:48:20 +08:00 via Android
老项目很大的话，就别想重构了，除非上面有指示或者不得不。只能尽量优化。
|
 |
3
crayygy 2019-11-17 15:59:23 +08:00 via iPhone
这其实并不是一个非黑即白的问题，并不是说用了新技术就不能继续用老技术，如果架构做得好，可以做到逐步替换，并且通过测试来保证业务一致性
|
 |
4
murmur 2019-11-17 16:08:02 +08:00
java 其实是个很特殊的例子，因为这语言构建了一个覆盖各种场景的帝国，无论是类库、框架、工具都太成熟，就算你不依赖语言的新特性，配合宇宙第二的 IDE，也能有不错的开发体验
但是很多语言没这个待遇 |
 |
5
pence2019 OP |
 |
6
securityCoding 2019-11-17 16:45:30 +08:00
先做前后端分离 , 然后起新的服务逐步重构重要接口,一口一口吃肉,不要一把梭压力会很大
|
 |
7
sagaxu 2019-11-17 16:47:29 +08:00
从 6 升级到 8 应该没那么困难，先升级到 8，然后才有继续重构的资格
|
 |
8
skyrem 2019-11-17 16:57:32 +08:00
你可以建议 TDD （测试驱动开发）
先照着老框架写一遍单元测试 再以通过单元测试为基准写新代码 |
 |
9
hantsy 2019-11-17 17:12:02 +08:00
比你这个更差的情况遇到过。
几年前，客户的一个老项目迁移，多个 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 2019-11-17 17:17:49 +08:00
系统化抽象的最简模型：
输入->[处理]->输出 在保持输出不变的基础上，简化输入和处理流程，从而达到节省成本的目的，那么则重构成功。 说起来容易做起来难，屎山一般都是一个黑盒，里边是盘根错节的互相牵制，牵一发而动全身，动全身而功败垂成。 这是生物学上复杂性系统 /复杂系统的概念。 你的既有知识会形成你认知的障碍，具体化会阻止你抽象化的思维。这是佛教概念（所知障）。 新技术会不会替代老技术？我不知道。但你的重构如果能转化为成本优势，那么说不定你能说服老板支持你。 |
 |
11
visonme 2019-11-17 17:24:55 +08:00
我们一般都是局部替代，而且是非常小心的，TO B 应用。
旧技术某种程度不会被新技术代替，但是更新 /变革肯定是存在的，毕竟业务在不断的增长，需求在不断的改变，很多旧技术在系统的问题越来越凸显，只是说推到重来是不可能的，这个代价不是一般公司可以承受的，一般都是局部先更新，做到完全替代是需要很长时间的。 |
|
12
hantsy 2019-11-17 17:38:39 +08:00
摆在我面前的话，我隐约的觉得这是实践 Microservice 一个好机会。
1. 一部分功能按 Bounded Context 划分，使用新的 Service 重写。涉及数据库的，也重新创建相应的数据库，迁移数据。 2. 旧代码通过 REST/HTTP, Message Broker 与新的 Service 交互，使之能完全替代旧的代码功能。 3. 删除那部分旧代码，删除那部分旧数据库内容。 4. 循环 1-3 步。可能你一个业务的 Serivce 迁移过程就要几个月。先挑个软柿子，比如不需要数据库的，邮件，通知，消息通信等等比较边缘的功能入手。 完全断代的代码或迁移或者架构的过程很痛苦，特别是正在使用的系统，要保持新旧一致性，对于用户而言数据不能遗失，用户体验要更好。 整个过程痛并快乐着。 |
 |
13
rainbowchou 2019-11-17 18:13:28 +08:00
技术百分百是业务驱动的，业务有相应的需求才会有新技术出现解决问题。
你业务没有变化或者业务体量预测不会爆发，凭啥要引进新技术，稳定使用压倒一切 一切看业务 |
 |
14
liuzhiyong 2019-11-17 20:48:20 +08:00
只要能用，就不要大改，这是我的看法。
|
 |
17
mazyi 2019-11-17 21:33:06 +08:00
失去竞争力就完事了，你想一直写 6 的语法么？
|
 |
18
crackhopper 2019-11-17 22:12:49 +08:00
一般都是重写吧。架构治理一下。一般才坑都是业务的坑。所以只要业务强的架构师重新规划几个服务，重写好，然后逐步替换上线就 OK 了。关键是你们公司有没有足够的营收能支撑你们重写架构。
|
 |
19
newtype0092 2019-11-17 22:13:22 +08:00
看过的书上的话：假设你投入一定的时间去优化目前稳定的项目，如果不能为现有业务带来相应的收益增长，那么你实际上对项目进行了一次负优化
|
 |
20
c0878 2019-11-17 22:16:06 +08:00
这种项目对简历加分毫无帮助 尽早脱身
|
 |
21
xuanbg 2019-11-17 22:28:02 +08:00
老的项目能正常运行的话，就不要横生枝节去折腾它了，除非你闲得慌。
当老项目需要增加新功能，支持新需求，并且是相对比较大的改动的时候，才是拆解它的良机。把新功能相关的部分从老的项目中分离出来，并且丢弃它。然后新建一个新的项目来完整地实现新功能以及相关的旧功能。 如果实在是没法拆，那就完全丢弃重写吧。 |
 |
22
wujunze 2019-11-17 22:29:35 +08:00
业务优先 稳定第一 慢慢改造 因地制宜 循序渐进
|
 |
24
AGEGG 2019-11-17 23:01:11 +08:00
开了个新接口，算是项目重构了，历时 4 周，自己完成了大概 80%快收尾了，每天各种忙，也没空摸鱼
优点是对业务掌握度 max，清楚了解了各种模块，对一套系统有了比较清晰的认识。 缺单很明显是工作量大，之后还有巨量测试，还要联调，耗时与收获不成正比 但感觉重构真心没必要，自己把自己新的想法写进自己的开源小 demo 就好 |
 |
25
dnsaq 2019-11-18 08:38:59 +08:00 via iPhone
还在用着几十年前的开发语言，怎么不自己开发一种语言，想想你们都觉得 low
|
 |
26
morphyhu 2019-11-18 10:25:04 +08:00
个人认为现有系统能满足需求的话，完全没必要使用最新的技术。有时间，有精力，有资金的话可以考虑使用新技术研发新系统来替代
|
 |
27
helionzzz 2019-11-18 10:52:39 +08:00  1
既然旧技术和新技术是为了达到同一个目的，那它们就不应该是对立的，而是统一的。即能达成目的就是最好的技术。
|
 |
28
mxT52CRuqR6o5 2019-11-18 11:25:40 +08:00 via Android
要不要新技术看老系统的需求了，如果老系统已经不需要进行什么新需求开发，仅仅是要修 bug 那就不要使用新技术，成本大收益低。反之如果是一个仍然需要不断迭代不断开发新需求的的老系统，那用新技术是有一定必要的。重构其实可以配置好路由慢慢重构
|
|
29
mxT52CRuqR6o5 2019-11-18 11:27:03 +08:00 via Android
@mxT52CRuqR6o5 只要方法得当，风险都是可控的
|
|
30
pence2019 OP @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 2019-11-18 13:09:27 +08:00
@pence2019 #30 Test Driven Development
中文是测试驱动开发，网上有很多资料，可以自己搜索下 |
 |
32
janus77 2019-11-18 13:34:58 +08:00
首先改不改不是一个必然的问题，是成本和后果的互相博弈
你这种情况，考虑一下灰度测试啊 先开个分支你自己改，也不需要全改，只需要改一部分。期间坑必须是你自己来踩 然后公司内部使用和外部小范围使用，运行一段时间了看情况 如果有效果 leader 会看到的，不用你说 |
|
33
hantsy 2019-11-18 14:14:21 +08:00
@pence2019 cvs,oracle-> git, MySQL 本身就是一个需要跨越的鸿沟，对团队来讲 Git 完全改变协作方式。数据库，如果使用了大量的 Oracle 特性（特有的 Function，Proceducer ），也是个大问题，你可能必须要写专门的程序去导数据，比如用 Spring batch,或者 JavaEE Batch 去实现大量 ETL 操作。
对于目前存在的程序，有大量用户和数据，稳妥的方法，只能一部分一部分功能逐步的迁移，比起完全重写工作量会很大，可能翻倍，最大的痛处需要兼顾旧程序，保持数据一致性，不能破坏程序的功能。在代码迁移过程也是对业务重新认识的一个过程，可以有机会让你的重新衡量过去的技术与业务结合是否合理，同时，可以慢慢清理一些技术债务问题，永远保持新的代码新鲜，没有 Code Smell。 等所有功能迁移完毕（用户可能感觉不到什么变化，但是程序代码脱胎换骨，已经完全迁移到新的架构，语言，框架上等），接下来再考虑 UX 的升级，比如前后端分离，使用 SPA 重新构建页面，重新考虑用户体验。 |
 |
34
chenyu8674 2019-11-18 18:25:20 +08:00
从 LZ 起标题的能力看来，这项目还是别动了
|
 |
35
nnnToTnnn 2019-11-21 10:48:19 +08:00
新技术一定会替换掉老技术，这个不必质疑。
只不过到底是逐步替换还是说一刀切的问题 |
Select Language