人人都恨不得家里有件祖上传下来的宝贝,程序员除外。

祖传代码,也被称为“屎山”,技术大牛都不敢轻易碰的东西。

初生牛犊的我,不信邪,有一天,我修改了其中一行不起眼的代码:

这种代码,为什么能活到现在?-知足常乐®

后来我才明白一个道理。

牛顿说过:我看得远,因为我站在巨人的肩膀上。

而对于我来说,是站在了这玩意儿上面:

这种代码,为什么能活到现在?-知足常乐®

祖传代码的爱恨情仇

在我的项目组里,有一个传奇的后端JS代码,6000多行,没有面向对象封装,纯靠函数。带了二十多个形参、几个标志位,分别有十几个数字状态。

注释?不存在的。

神奇的是,代码在执行的时候,基本上没太多的错。

每一位接手过这段代码的人,都会不约而同的发一条朋友圈,以示佩服。

直到有一天

一位“大牛”在离职前,重构了这段代码

留下了至今都没有修改完的bug

从那时起,我明白了一个道理:“重构祖传代码,就跟迁坟一样,稍有不慎,万劫不复!”

要重构?可以!等我不忙的时候再说

一般,我都忙

祖传代码,反正我是不敢动了,反倒是组里的一哥们儿,闹了个大笑话。

因为组里就我们几个人,很多事都当面说,这哥们儿也是习惯了。一天上班时,忽然大喊大叫:“这代码谁写的,这么明显的bug都能出,还不写注释,真的气死人!”

隔壁的项目经理都听到了,发话说:“那个谁,你查一下SVN记录,查出来全公司通报,扣他年终奖。”

“那哥们儿说在查了,等一下。”

几分钟过后……

“不...不可能,这怎么可能?”

这种代码,为什么能活到现在?-知足常乐®

所有人都被吸引了过来,原来这段代码是这哥们儿,一年前提交的。

为了避免尴尬,这件事就没人再提了。

每个人都讨厌祖传代码,却又无时不刻的生产着……

祖传代码里的故事

不知不觉,5年的时间过去了,这才明白,原来祖传代码里,都蕴藏着一个个“动人”的故事。

项目启动,经理跟我说,先出个原型,再快速迭代

后来赶项目,又跟我说,先把功能做出来,以后再重构

再后来,因为重构时间会很久,经理说,加100个运维吧,一定要把故障率控制在1%以下。

期间,穿插了无数次产品经理的需求变更……

阅读祖传代码,就好像在很短的时间内,要将藏在代码中的故事,重新演绎一遍一样,有哪个人能懂?又有哪个神仙,能改写故事的情节?

肿瘤代码

这样的祖传代码活到现在,是有道理的,技术更新频繁,市场变化太快,会导致产品演变,功能需求会随之改变。在当时可能很不错的代,随着时间的推移,就会变成传说中的祖传代码。

可惜的是,并不是所有的祖传代码,都是这么“良性”,改需求什么的,都是家常便饭,也可以理解,但有一些代码,简直就像项目里的恶性肿瘤一样。

之前看过一个故事,惊奇万分,说的是大型烂代码事故。大体上是这样的:

1996年,法国的一个政府机构,请某公司开发一款软件,但由于公司管理不善,没有制定对应的开发规范,导致形成了一个彻头彻尾的烂项目。

到底有多烂呢?

总共写出了600万行C++代码,要知道Linux3.13版的内核代码,除去内核驱动和架构,在kernel/里也就13万行而已。

总共有50000多个类;

受编译器版本限制,用的C++语法很陈旧,只能在一个早就没维护的操作系统上部署;

基于CORBA

采用的数据库软件,来自一家早就破产的公司;

运行一个用户界面,需要启动40-50个子线程;

在32台并行的机器上,需要48小时进行编译;

没有采用运行库动态链接技术,一个可执行程序,就有好几百兆;

启动这玩意大约需要15分钟;

启动成功后,一般30秒-30分钟内就会崩溃;

一些感悟

几年下来,只有两点感悟颇深。

其实在大部分情况下,形成所谓的“祖传代码”,是情有可原的。赶项目、需求变更、技术更迭,个人技术水平增强,都会导致祖传代码的诞生。

越大的公司,“屎山”就越高,也越多。所以,公司代码太烂,不应该成为我离职的理由,这是不负责任的表现。当然,如果是上面那个故事的,除外……

祖传代码很让人讨厌,因为你不得不用一些古代流行的命名方法、设计模式去修改这些东西,但我想说的是,千万别轻易做出改变,如非必要,别碰。

最后用一张有趣的图片,结束本文。

这种代码,为什么能活到现在?-知足常乐®