如何拯救被人遗忘的老代码？

[tool2d]

渣男总是喜新厌旧，只关注当前的新项目，那些过期老代码，基本上无人问津。

就算业务需要调用老代码，新人们也不会想要维护老代码库，只想着全部推翻重构。

既然代码的最终命运就是被人遗忘，那当初为什么要去写它呢？

[xinta]

代码最开始都是新的，写它也是为了解决那个时候的问题而已

[tool2d]

@xinta 人总是倾向于维护短小精悍，比较便携的代码库。那些日积月累的业务代码，像面条一样绕来绕去，就没人愿意去接手。

我在想着怎么改变这种情况。只有不断的积累才会变强，可是人类遇见复杂和大行数的代码，会有天然的抵触情绪。

[xinta]

@tool2d 是的，所以很多开发宁愿推到重来，也不想去维护老代码

[nu11ptr]

工时给够就不那么抵触了

[ration]

没那么抵触，只是很多没文档，花时间多

[buyan3303]

讲个小段子：一幢大楼结顶（程序完工上线），一个人买了一楼商铺，然后觉得里面的承重柱太碍事，想要拆了（项目重构）。

[inu]

对新人来说，维护老代码比重写一遍更费劲，自然谁也不想维护。
如果老代码写的直观、简洁、易调用、易维护，是否新人会倾向于现成的代码？
猜测是由写老代码人水平的高低决定的。

[tool2d]

@inu 这里面又有问题，想要老代码质量很高，就需要拉长开发周期。和国内项目尽快上线的理念又是相悖的。

就算是老手，工期太短一样会翻车。

[inu]

@tool2d 是这样的，巧妇难为无米之炊，没有工期，三天怎么也出不了一年的活。

[chairuosen]

所以这是个博弈论，最终市场的选择是个博弈后均衡的结果

[zagfai]

楼上很多回答忽略了绩效问题，重新写代码，提高了 xxx 20%，就有绩效了，老代码就不要了。

[tutou]

@zagfai 完全赞同，补充一点，你维护老代码出问题你就要背锅，不出问题那是理所应当的，做的再好功劳也是写老代码的人的

[coderluan]

“既然代码的最终命运就是被人遗忘，那当初为什么要去写它呢？”

这个话说的没啥逻辑。换种脏一些的说法，“饭早晚会变成翔，那么当初为什么要吃饭”，这显然是有问题的。饭菜的营养被吸收了，代码产生了商业价值，就已经完成了主要使命。而且这种脏的说法也能解释为什么”新人不愿意去维护老代码“， 或者说更准确的情况是大家不愿意维护别人的老代码，很简单，“因为那饭不是我吃的，因为那翔不是我拉的”。

[ThanksSirAlex]

不存在能解决所有问题，然后又好看的架构，所以才需要重构。每个业务发展到不同的阶段需要解决和侧重的问题都不一样，代码说到底还是一个工具，解决问题才是价值所在

[tool2d]

@coderluan 翔只要通过二次利用，也可以变成营养土。

现在是没人愿意去做代码翻新这件事情，就导致很多代码写完就扔，都成了一次性快餐了。

[crabdudu]

@tool2d 翔二次利用只需把他换个地方即可，代码想要二次利用得先尝尝这是什么味儿，代价太高

[lmshl]

我手里的系统我重写+重构过不下 6 次

NodeTS 时代 -[重构]-> 升级到多租户 -[重构]-> 拆分式多租户实现 -[重构]-> 聚合式多租户实现 -[重写迁移]-> Scala Future 时代 -[底层重构]-> Scala 编译期注入 -[底层重构]-> Scala ZIO 纯函数式时代 -> ...至今...

最大的问题在于，优化老代码这事吃力不讨好，即便是原作者亲手重构，依然有不小的概率会重构出新的 Bug 。
那么，出问题了这个锅谁来背？

其实最合适的重构时间点应该是需求变更的时候，做新功能或改旧功能的时候，把这个模块相关的技术债务一并解决一波，一块做回归测试。这时候出问题也是大家都能接受的，不会担很大责任。

[8zip]

凡是现存的，都是要毁灭的

[lmshl]

还有，我武器充沛。
业务已经是基于 TypeScript / Scala 高级类型描述的了，消除了大多数 Illegal State ，大部分情况下只要类型配平了，正确性不太需要担心。需要额外测试的主要是和外部系统对接的部分（包括数据库 /缓存等）

那么，你想拯救的老代码，它值得被拯救么？（是否也大量运用 Option / Either / Fiber / Immutable / 甚至 Dependent type... 消除 Illegal State ？

[7gugu]

维护老代码成本太高了，常常需要 2-3 倍的精力才能维护