想问一个问题,如何优化一个老项目.

[helee9199]

公司是医院项目,源码里最老的代码可以追溯到 05 年左右,
然后几乎 80%的模块代码都在一个 jar 里
目前想做一些优化,把一些功能按模块抽取出来
例如 A B C D E F G 等 都在一个 jar 包内
想把 A 相关的 抽取出来单独成为一个 jar 后期想慢慢都分离出来.
但是 A 和 B C D 之间又有关联,可能 A 要用 B ,C 要用 A 之类的
那就成了循环引用.
这种情况下应该如何进行下去呢
常年 crud 这方面无从下手了.
而且新技术也用不上 目前 JDK6
请大佬们指教

[tabrye]

不要动它!不要动它!不要动它!


哪怕重做啊

[jjwjiang]

真的太年轻了，仿佛看到几年前的自己。

眼界宽一点，多想想代码以外的事，测试、运维、交付的时间是不是时间？
重构给客户带来的额外风险谁来解释？
重构完成，带来的所谓“修复 bug 的效率提升”，是否比得上重构的成本？
你的所谓“重构”，是否真的能够满足将来扩展的需求？

一个项目的因素，往往真的不止代码那点事，代码洁癖是年轻码农的通病，慢慢理解就好了。

[ktin]

@jjwjiang 这么真实的吗 哈哈

[kujio]

如果旧的可以用那就别动了,
重写一个新的,逐渐用新的替代旧的

[piping]

如果没坏就不要修。

实在想改，先写测试，单元测试。没有测试不要大改

[thetbw]

@jjwjiang 也是，想想可能干不了那么长时间就溜了

[statement]

你要先问问你自己 你入职这家公司几年了，是项目负责人或者领导吗？ 还是应届生或者刚进去实习

[ericgui]

其实我个人挺喜欢重构的，很有成就感的

[ericgui]

就类似你们喜欢看各种修复老旧物件的视频，油管上很多，b 站有个林果儿

为什么到了代码，就只想着推倒重来，而不是慢慢修复？

[kensoz]

@helee9199
你这说的仿佛和我这一样啊。
我这也是，我这是母版一个主分支，一个客户一个副分支，其他的按功能建分支，需要的哪个功能就合并哪个分支到需要的客户分支，不过这样带来的问题就是合并地狱。
关于重构，我现在的想法就是不重构也不改，屎山上拉屎，这样是最省事的，然后说屎山太臭，给自己争取时间。
有时间了就学习，然后自己私下用新技术重构，当然这里重构的好坏都无所谓，省去了被说的风险。
随着对屎山的把握以及重构，能感受到自己对项目架构的把握也在一点点的提升。

[jj256]

先看看前任的代码水平吧，如果本身水平一般坑会比较多，推荐重写，没有历史包袱。重写之前先用老项目接口写好单元测试用例，覆盖要全，然后新项目就可以为所欲为了。

[V2Axiu]

@ericgui 老物件有修复的价值- -

[ericgui]

@kensoz 开闭选择，你应该每一个 feature 都有一个开关，而不是现在这样搞无数个分支

[ericgui]

@kensoz 哦，错了，不是开闭选择，是“正交”，每个功能都可以关闭，不影响其他功能，不同的配置就是一套不同 feature 的组合

[kensoz]

@ericgui
原来还可以这么搞，谢谢，我准备学习一下

[comoyi]

先开个新仓库拆一个非关键模块出来替换掉原先的看看

[ericgui]

@kensoz 嗯，“正交”这个概念，确实非常强大

[456789]

重写，能复制的复制