12 年的祖传“屎山”代码,年收入竟超 1.4 亿元?程序员劝“接盘侠”:赶紧退退退!

2022-09-22 22:30:34

12 年的祖传“屎山”代码,年收入竟超 1.4 亿元?程序员劝“接盘侠”:赶紧退退退!

整理 | 郑丽媛

出品 | CSDN(ID:CSDNnews)

讲道理,许多做过代码届“接盘侠”的程序员们,某种程度上可能十分理解电影中执着于毁灭世界的反派:“与其在现有基础上修改,还不如直接把这堆祖传代码毁灭再重建!”

祖传代码,从字面意思来看,就是一代代老程序员们留下来的“宝藏”代码——这些长年累月的代码中存有很多隐患,后来的“接盘侠”们要么无从下手,要么一改就崩,几乎可以说是程序员们的“终极噩梦”,因此也被称作“屎山代码”。

这不,最近又有一个“倒霉蛋”火上了 HN 热榜:“我继承了我见过的最差的代码和技术团队,该怎么办?”

拥有 12 年历史、没有版本控制的“祖传代码”

从这位“接盘侠” @whattodochange 阐述的现状来看,他这次继承的代码历史长达 12 年,是没有版本控制的 PHP 代码,居然每年还能产生超过 2000 万美元(约人民币 1.4 亿元)的收入:

以上就是 @whattodochange 目前所接盘的代码和团队现状,他头疼道:“我必须要找到一个策略来修复这个开发团队。”

面对这个“烂摊子”,@whattodochange 想到的解决办法是完全重写,但由于公司管理层和总部对这些阻碍因素并没有真正了解,业务部门对这个项目有非常积极的规划路线,且疫情之下公司的预算很紧张,导致 @whattodochange 根本无法推进。

因此,@whattodochange 发帖求助:“我知道完全重写是必要的,但要如何平衡?”

逐一改动 or 摆烂跑路?

对于 @whattodochange 的遭遇,不少有经验的程序员深有同感,也提出了一些应对“祖传代码”的具体建议。

“完全重写不是必需的,甚至可能是最糟糕的方法。可以一次做一件事,最终你会重写所有代码,但永远不会陷入‘完全重写’的陷阱中。 不过在重写一行代码之前,记得要做大量的测试。如果有端到端测试,这些测试运行在客户群当前使用的每个功能中,那么您就有一个基线来安全地进行更改。只要测试通过,就可以删除代码。 不要想着去推动变革,尝试拥抱这个每年赚 2000 万美元的可怕代码库,和团队讨论讨论如何在能力范围内改进即可。”
作为这个开发团队的经理,你的任务是要得到高管支持来逐渐解决这个烂摊子。你没必要告诉高管或团队具体要如何修复,只要有时间和空间上的支持就好。 有一种办法是每周五集合团队一起来测试,但可能会经常被紧急任务挤掉;另一种办法是让每个更新的发布速度稍慢一些,这样就有时间优化每次更新所涉及到的其他代码。例如,业务要求添加功能 X,那么你就给相关的现有功能 Y 添加一个测试,可以对团队说优化 Y 是为了让添加 X 更为方便。”

不过,也有部分程序员在了解 @whattodochange 的现状后,认为“摆烂跑路”是最优解:

“你应该考虑辞职。虽然你知道这代码很烂,但它确实能带来每年 2000 万美元的收入,所以你的团队不想变革,业务人员也不会关心代码质量。他们会认为:反正 2003 年样式的 PHP 代码就可以实现这个收入,那不挺好,干嘛要浪费财力和精力去重写? 最后,你很难说服你的开发团队和业务部门同意重写这个决定,甚至还会招来仇视,而你自己也会讨厌这样的工作氛围。”
“为了避免自己受伤,我劝你摆脱这种混乱的处境。我之前也一直处于类似的情况,花了快五年的时间试图解决,但最后还是心累地放弃了。”

血泪教训:“人跟代码有一个能跑就行了”

其实在现实中,几乎所有软件开发公司都有各种老大难的“祖传代码”,像 @whattodochange 遇到这种 12 年历史的都还算年轻的了——一般越大规模越厉害的公司,“屎山”代码的情况越严重。

类似地,国内也有许多程序员分享过他们遇到的各种“骨灰级”祖传代码:

可能对于很多刚工作的萌新程序员来说,看见这些各处都埋着“地雷”的代码第一反应就是“推倒重来”,但大多都得到了血泪教训:“有的时候,代码能运行就不要尝试去改,哪怕是遇到屎山一样的代码”,可能还会对新人建议道:“人跟代码有一个能跑就行了。”

那么,你是否在工作中遇见过令人发指的“祖传代码”,最长拥有多少年历史?你是选择逐一改动还是放任不管?

上一篇

热门阅读