这是一个创建于 1111 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司是医院项目,源码里最老的代码可以追溯到 05 年左右,
然后几乎 80%的模块代码都在一个 jar 里
目前想做一些优化,把一些功能按模块抽取出来
例如 A B C D E F G 等 都在一个 jar 包内
想把 A 相关的 抽取出来单独成为一个 jar 后期想慢慢都分离出来.
但是 A 和 B C D 之间又有关联,可能 A 要用 B ,C 要用 A 之类的
那就成了循环引用.
这种情况下应该如何进行下去呢
常年 crud 这方面无从下手了.
而且新技术也用不上 目前 JDK6
请大佬们指教
然后几乎 80%的模块代码都在一个 jar 里
目前想做一些优化,把一些功能按模块抽取出来
例如 A B C D E F G 等 都在一个 jar 包内
想把 A 相关的 抽取出来单独成为一个 jar 后期想慢慢都分离出来.
但是 A 和 B C D 之间又有关联,可能 A 要用 B ,C 要用 A 之类的
那就成了循环引用.
这种情况下应该如何进行下去呢
常年 crud 这方面无从下手了.
而且新技术也用不上 目前 JDK6
请大佬们指教
第 1 条附言 · 2021-12-08 11:49:06 +08:00
补充一点, 不是单单维护一个项目,而是这个项目会有多家要使用 然后根据不同的客户 再做一些修改
目前就是新开一个客户 然后才有了这个优化需求
相当于把它分模块以后,后期把他当作母版来用.
目前就是新开一个客户 然后才有了这个优化需求
相当于把它分模块以后,后期把他当作母版来用.
 |
1
Vkery 2021-12-08 11:19:07 +08:00
难度 甚至超过推倒重写
|
 |
2
pengtdyd 2021-12-08 11:22:23 +08:00
优化不如重写
|
 |
3
3dwelcome 2021-12-08 11:24:13 +08:00
也许人家写代码的时候，就没打算把模块分开，你又何必强行拆离。
最好的方法就是重写，用新的模块直接去覆盖。 |
 |
5
LxExExl 2021-12-08 11:40:07 +08:00 via iPhone
没新的业务需求和性能需求 为啥要优化呢
|
 |
6
murmur 2021-12-08 11:43:58 +08:00
不要优化
|
 |
7
ChrisFreeMan 2021-12-08 11:51:51 +08:00 via iPhone
只是好奇，我想问下为什么很多人喜欢把几千几千行的代码塞在一起？
|
 |
8
gadfly3173 2021-12-08 11:57:43 +08:00
jdk6 也上不了 spring cloud ，就放在一个 jar 里其实也没有很大影响，想拆分的话就内部分一下 package 好了
|
 |
9
kensoz 2021-12-08 11:57:47 +08:00  1
和我这地方很像
我这地方也是一个 jar ，有基础功能。针对不同的客户还会有一些针对性升级 内部逻辑就不说了，循环引用，无效代码，各种无解代码。接手的人多，各种年代风格的代码都有 开始我也准备修改，现在放弃，继续屎山上拉屎 如果优化不是工作，有需求就拉屎，有空闲时间可以自己试试重构 |
 |
10
xuanbg 2021-12-08 11:59:47 +08:00
先解决模块相互依赖的问题，然后拆就很简单了。
|
 |
11
helee9199 OP @kensoz 然后会碰到一个问题是, 如果有同样的 bug 那 12345 家客户 每家都要去改一遍
目前就是想把母版做好, 子板引用 修好 bug 大家都好 |
 |
12
zyy314680012 2021-12-08 12:11:09 +08:00 via Android
不要优化
|
 |
13
zoharSoul 2021-12-08 12:21:00 +08:00
最好的优化就是不要优化
|
 |
14
dqzcwxb 2021-12-08 12:25:14 +08:00
串行变并行就是最简单有效的优化
|
 |
15
potatowish 2021-12-08 12:55:09 +08:00 via iPhone
只是一个需求的话，建议继续在屎山上加一层，不要重构，费力不讨好的事不做
|
 |
16
forbreak 2021-12-08 13:52:28 +08:00 3
1. 你目前能投入多少时间去做这个事情。
2. 你为这事加班加点项目进度还有人催，你能顶住不？ 3. 最后拆分完了，有没有人帮你整合测试。 4. 项目进度更重要的时候，有没有人手顶上项目进度，让你专门做这个拆分。 5. 领导能不能理解你得重构和拆分这件事，领导愿意支持你多久，给你投入多少人力和时间？延期之后，是否还能大力支持。 6. 拆分完之后旧项目得处理，分批上线，还是旧项目不动，新项目用新的？ 7. 拆分不产生正收益，负收益会不会对你得绩效奖金之类得产生影响？ 等等等等。。。你可以继续细想 |
 |
17
chocotan 2021-12-08 13:57:36 +08:00
问题说给领导听, 领导做决定
|
 |
18
nonoyang 2021-12-08 14:00:20 +08:00
不要盲目优化，尤其是老项目。
|
 |
19
wolfie 2021-12-08 14:05:23 +08:00
代理模式覆盖。
|
 |
20
myl0204 2021-12-08 14:43:12 +08:00
如何优化一个老项目?
"永远不要尝试优化它“ |
 |
21
tabrye 2021-12-08 15:08:01 +08:00
不要动它!不要动它!不要动它!
哪怕重做啊 |
 |
22
jjwjiang 2021-12-08 15:31:01 +08:00
真的太年轻了，仿佛看到几年前的自己。
眼界宽一点，多想想代码以外的事，测试、运维、交付的时间是不是时间？ 重构给客户带来的额外风险谁来解释？ 重构完成，带来的所谓“修复 bug 的效率提升”，是否比得上重构的成本？ 你的所谓“重构”，是否真的能够满足将来扩展的需求？ 一个项目的因素，往往真的不止代码那点事，代码洁癖是年轻码农的通病，慢慢理解就好了。 |
 |
24
kujio 2021-12-08 15:45:12 +08:00
如果旧的可以用那就别动了,
重写一个新的,逐渐用新的替代旧的 |
 |
25
piping 2021-12-08 15:55:57 +08:00 via iPhone
如果没坏就不要修。
实在想改，先写测试，单元测试。没有测试不要大改 |
 |
27
statement 2021-12-08 16:15:33 +08:00
你要先问问你自己 你入职这家公司几年了，是项目负责人或者领导吗？ 还是应届生或者刚进去实习
|
 |
28
ericgui 2021-12-09 01:32:47 +08:00
其实我个人挺喜欢重构的，很有成就感的
|
|
29
ericgui 2021-12-09 01:34:08 +08:00
就类似你们喜欢看各种修复老旧物件的视频，油管上很多，b 站有个林果儿
为什么到了代码，就只想着推倒重来，而不是慢慢修复？ |
|
30
kensoz 2021-12-09 08:02:33 +08:00
@helee9199
你这说的仿佛和我这一样啊。 我这也是，我这是母版一个主分支，一个客户一个副分支，其他的按功能建分支，需要的哪个功能就合并哪个分支到需要的客户分支，不过这样带来的问题就是合并地狱。 关于重构，我现在的想法就是不重构也不改，屎山上拉屎，这样是最省事的，然后说屎山太臭，给自己争取时间。 有时间了就学习，然后自己私下用新技术重构，当然这里重构的好坏都无所谓，省去了被说的风险。 随着对屎山的把握以及重构，能感受到自己对项目架构的把握也在一点点的提升。 |
 |
31
jj256 2021-12-09 09:21:19 +08:00 via Android
先看看前任的代码水平吧，如果本身水平一般坑会比较多，推荐重写，没有历史包袱。重写之前先用老项目接口写好单元测试用例，覆盖要全，然后新项目就可以为所欲为了。
|
|
34
ericgui 2021-12-09 10:34:47 +08:00 via iPhone
@kensoz 哦，错了，不是开闭选择，是“正交”，每个功能都可以关闭，不影响其他功能，不同的配置就是一套不同 feature 的组合
|
 |
36
comoyi 2021-12-09 13:20:43 +08:00
先开个新仓库拆一个非关键模块出来替换掉原先的看看
|
 |
38
456789 2022-02-25 20:32:45 +08:00
重写，能复制的复制
|
Select Language