8ac73bcef1f39a5e696bad1ff59a1c8b.gif

整理 | 郑丽媛

出品 | CSDN(ID:CSDNnews)

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

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

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

1538861d4111afeb94c44dbaffe47a2e.jpeg

3fa414158aaf5fd3111bcdd2d3ee85b9.png

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

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

  • 这些代码每年能产生超过 2000 万美元的收入。

  • 运行在 PHP 上。

  • 已经在生产环境直接开发了 12 年,没有源代码控制(都是像 index-new_2021-test-john_v2.php 这种)。

  • 没有使用 composer 或任何依赖管理,都是 require_once。

  • 没使用任何框架。

  • 路由管理完全是在 NGInX 中重写的(NGInX 的配置大约是 10000 行)。

  • 这些年只在不断往上堆代码,没删除任何代码(我推测这是因为代码是直接在生产环境开发的,删东西太危险了)。

  • 数据库结构也是一片混乱,没有迁移等等。要添加一个列时,由于数据量大,他们一般会建一个新表,然后用 join。

  • JS 和 CSS 也是如此。jQuery 的不同版本互相打架,具体取决于你在哪个页面,有时甚至同一个页面也会有。

  • 当然没有 MVC 模式或其他模式什么的,没有模板库。这是 PHP 2003 的样式。

  • 在很多地方,我看到像是 Controller 一样的文件,向它自己的 rest API 发出 curl 请求(通过域名而非 localhost)进行 oauth 授权等…然后只是为了获取菜单项或产品列表。

  • 没有缓存(但有 memcached ,但只用于 Session…)。

  • 团队只有 3 个很年轻的人,一个后端,一个前端,一个 iOS/android ,他们对代码变革非常抵触。

  • 生产力很差,这可以理解——乱七八糟的东西实在是太多了,根本没办法做新东西。

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

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

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

3f189a678b9fead3f2e7b480416a4d02.png

逐一改动 or 摆烂跑路?

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

“完全重写不是必需的,甚至可能是最糟糕的方法。可以一次做一件事,最终你会重写所有代码,但永远不会陷入‘完全重写’的陷阱中。

不过在重写一行代码之前,记得要做大量的测试。如果有端到端测试,这些测试运行在客户群当前使用的每个功能中,那么您就有一个基线来安全地进行更改。只要测试通过,就可以删除代码。

不要想着去推动变革,尝试拥抱这个每年赚 2000 万美元的可怕代码库,和团队讨论讨论如何在能力范围内改进即可。”

作为这个开发团队的经理,你的任务是要得到高管支持来逐渐解决这个烂摊子。你没必要告诉高管或团队具体要如何修复,只要有时间和空间上的支持就好。

有一种办法是每周五集合团队一起来测试,但可能会经常被紧急任务挤掉;另一种办法是让每个更新的发布速度稍慢一些,这样就有时间优化每次更新所涉及到的其他代码。例如,业务要求添加功能 X,那么你就给相关的现有功能 Y 添加一个测试,可以对团队说优化 Y 是为了让添加 X 更为方便。”

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

“你应该考虑辞职。虽然你知道这代码很烂,但它确实能带来每年 2000 万美元的收入,所以你的团队不想变革,业务人员也不会关心代码质量。他们会认为:反正 2003 年样式的 PHP 代码就可以实现这个收入,那不挺好,干嘛要浪费财力和精力去重写?

最后,你很难说服你的开发团队和业务部门同意重写这个决定,甚至还会招来仇视,而你自己也会讨厌这样的工作氛围。”

“为了避免自己受伤,我劝你摆脱这种混乱的处境。我之前也一直处于类似的情况,花了快五年的时间试图解决,但最后还是心累地放弃了。”

501ca1cffb3a6c6eb07d7359124f6486.png

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

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

  • 《GTA 5》联机版中循环 19.8 亿次的 if 语句,被许多人称作游戏开发史上最大的“屎山”代码,存在了 7 年 R 星(游戏开发商 RockStar)的程序员无人敢动。最终,还是一位黑客大哥看不下去给出了解决方案,R 星这才官宣要修复 bug,并给这位黑客奖励了 1 万美元。

  • 一位亚马逊工程师也曾形容他们公司的代码为:“一座很大的屎山,一座你见过的最大的山,每次你想修正一个 bug,都得爬到屎山的正中央去。”

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

  • “公司代码已经 40 年了,最早写代码的人不知道是否活着,要命的是文档没留下,项目代码堆在一起能有 90 多 G。”

  • “我要升级的那批代码写于 2000 年前,最早的部分可能写于 1980 年代贝尔实验室。第一批维护升级做需求的人早就退休了,第二批也退休了,每一行代码动起来都胆战心惊。”

  • “曾经在 Visa 工作过,感觉什么 10 年 20 年的代码简直 naive,你见过 1965 年的代码吗?第一次看到简直惊呆了,这半个世纪的代码现在还在用还跑的好好的?”

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

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

参考链接:

  • https://news.ycombinator.com/item?id=32883596

  • https://www.zhihu.com/question/272065178

— 推荐阅读 —

 
 

3f8c6b573ba085bba7306d351d0a1759.jpeg

Logo

20年前,《新程序员》创刊时,我们的心愿是全面关注程序员成长,中国将拥有新一代世界级的程序员。20年后的今天,我们有了新的使命:助力中国IT技术人成长,成就一亿技术人!

更多推荐