人人都恨不得家里有件祖上传下来的宝贝，程序员除外。
祖传代码，也被称为“屎山”，技术大牛都不敢轻易碰的东西。
初生牛犊的我，不信邪，有一天，我修改了其中一行不起眼的代码：
后来我才明白一个道理。
牛顿说过：我看得远，因为我站在巨人的肩膀上。
而对于我来说，是站在了这玩意儿上面：
祖传代码的爱恨情仇
在我的项目组里，有一个传奇的后端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分钟内就会崩溃；
一些感悟
几年下来，只有两点感悟颇深。
其实在大部分情况下，形成所谓的“祖传代码”，是情有可原的。赶项目、需求变更、技术更迭，个人技术水平增强，都会导致祖传代码的诞生。
越大的公司，“屎山”就越高，也越多。所以，公司代码太烂，不应该成为我离职的理由，这是不负责任的表现。当然，如果是上面那个故事的，除外……
祖传代码很让人讨厌，因为你不得不用一些古代流行的命名方法、设计模式去修改这些东西，但我想说的是，千万别轻易做出改变，如非必要，别碰。
最后用一张有趣的图片，结束本文。
閱讀更多 W3Cschool 的文章
