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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 752 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

代码

遗忘

渣男

喜新厌旧

21 条回复 • 2022-11-08 20:07:31 +08:00

xinta

2022-11-08 13:08:31 +08:00

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

tool2d

2022-11-08 13:12:03 +08:00

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

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

xinta

2022-11-08 13:38:02 +08:00

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

nu11ptr

2022-11-08 13:39:04 +08:00

工时给够就不那么抵触了

ration

2022-11-08 13:40:49 +08:00 via Android

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

buyan3303

2022-11-08 13:43:00 +08:00

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

inu

2022-11-08 13:52:45 +08:00

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

tool2d

2022-11-08 14:14:39 +08:00

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

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

inu

2022-11-08 14:39:43 +08:00

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

chairuosen

2022-11-08 15:25:28 +08:00

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

zagfai

2022-11-08 16:28:22 +08:00

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

tutou

2022-11-08 17:08:21 +08:00

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

coderluan

2022-11-08 17:12:31 +08:00

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

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

ThanksSirAlex

2022-11-08 17:25:50 +08:00

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

tool2d

2022-11-08 17:30:38 +08:00

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

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

crabdudu

2022-11-08 18:05:10 +08:00 via iPhone

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

lmshl

2022-11-08 18:12:46 +08:00

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

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

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

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

8zip

2022-11-08 18:16:29 +08:00 via Android

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

lmshl

2022-11-08 18:18:18 +08:00

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

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

7gugu

2022-11-08 19:31:10 +08:00

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

mizuBai

2022-11-08 20:07:31 +08:00 via iPhone

我进课题组第一个月，把组里的 Fortran 代码用 Python + f2py 重构了一堆，写了文档，把工作流程自动化实现了一部分。