为什么祖传代码被称为「屎山」？这个回答简直太形象了
共 2484字，需浏览 5分钟
·
2021-01-14 21:43
经常听说祖传代码会被人称之为「屎山」，不同人可能有不同的体会，最近看到一个回答，简直是把这个阐述得“活灵活现”，大家来感受下吧。
阅读本文大概需要 3 分钟。
作者：Avalon
原文链接：https://www.zhihu.com/question/272065178/answer/1583717199
来源：知乎
说一个亲身经历的一座「屎山」，曾入职一家成立 15 年的软件公司，我当时应聘的是中级程序员，但在入职几个月后，我的岗级和薪资调整到了高级程序员，这并不是因为我在这几个月中技术水平跨越式提升，而是因为这三个月中发生了以下事情：
前任组员一号和我完成交接之后跑路了！
前任组长和新招来的组长交接之后跑路了！
前任组员二号和新招来的初级程序员交接之后跑路了！
新任组长和我交接之后跑路了！
新人组员（女）在工位掩面痛哭之后，换组了！（捂着脸掉眼泪不发出声音的那种哭）
组内人手严重不足，我白天解决生产bug，晚上写新需求！
这是一座年轻的「屎山」，我是第三批接手者，历时几个月后我成了项目组中，资历最老的员工！实习生和初级程序员写出来的bug和低级错误我就忍了，都是从菜鸟过来的，勉强可以理解。
但是框架因为“高程”、“架构组”、“大手子”等人的填填补补，已经到了严重影响用户体验的程度！！！
For example！当时项目的工作流很奇葩，不论出现什么错误，都会统一提示“发生未知错误”。哪怕我照着“公司祖传框架使用手册”，在配置中填写「核算系统接口调用失败」、「当前时间不允许操作」等提示信息，客户用的时候还是统一提示“发生未知错误”！
起初因为运维人员每天都在帮客户解决这种问题，客户倒是没有多大的怨气。某一天，因为很复杂的原因，客户为了此事大发雷霆，我被要求解决这个问题。
在一顿忙碌之后，问题定位到了一个公司自己封装的 jar 包，反编译后发现里面的逻辑有问题。我就联系外地的架构组，让他们给我一个新的 jar 包，第二天我收到了回复：“这个框架很早就重构了，公司新框架不兼容老框架，使用老框架的项目都交给项目组自己维护了，你们项目组的框架应该是 xxx 在维护。”
xxx 是一个很陌生的名字，几番打听之后才知道，xxx 是我们组的第一任组长，离职两年多了！我只能在 svn 上继续摸索，愣是没有找到 jar 包的源码。几经波折之后才知道，svn 之前是几个外包厂商共用的，后来因为外包厂商多了，就给每个厂商重新配置了一个 svn，迁移的时候这个 jar 包的源码因为没有厂商认领，就被丢到了公用的 svn 上。
然而故事并没有结束，从公用 svn 找到的源码，和我通过反编译出来的代码，很多地方对不上！源码里的注释在我眼中都变成了「年轻人，千万不要动这坨屎！」
最后我只能在工作流外面，又封装了一套组件，专门用于代替工作流提示信息，并且留下了一行注释「如果你不幸看到了这行注释，不要怪我，我也不想的！」
以上只是「屎山」一角，「屎」是因为祖传代码里面有很多问题是真的臭，「山」是因为屎太多了。最讽刺的是，你可能为了治理「屎山」，也在里面拉了几次「屎」......
太形象了....
还有一个事，再说一个关于这座「屎山」的一角。
项目组负责的几个系统中，有一个负责放款的系统（前置业务系统，并不涉及记账和转款），放款是甲方爸爸非常核心的功能之一，上线之前肯定是重点测试的，所以我接手的时候已经平稳运行了数年。接手之后也没有出什么问题，整个放款业务也没有什么新需求，我也就没有深入研究，直到那一天......
背景是甲方爸爸接了个一个大单，但是因为量太大，其中几笔合同的合同号录差了，导致纸质合同和线上合同对不上，甲方爸爸就找到了我们组的一个组员去做数据处理。处理了一下午，线上合同的合同号还是没有变，组员来找我的时候已经满头大汗，我心中隐隐猜到，又要踩屎了。
我发现组员按照数据库文档修改了合同号，但是系统上还是显示旧合同号。因为已经踩了几次屎，我就直接去翻代码了。然后大量“中文拼音”命名的变量和无数意义不明的注释，看的我太阳穴一跳一跳的。
原来生成电子合同功能跟我们想象的不太一样，在完成放款操作时系统会生成一个以合同信息主键（36 位 UUID）命名的 PDF 存在本地，每一次点击下载合同其实就是根据主键 ID 下载这个文件，所以数据库里不论怎么修改对电子合同都没有影响，当时捋明白这个逻辑的时候我惊出了一身冷汗，但并不是因为这个设计多么的反人类......
前方高能！！！前方高能！！！前方高能！！！
前任运维人员交接的时候，说放款系统上线一年没啥问题，唯一要注意的就是因为与外部系统交互产生的交易文件很多，所以要定时清理，还当着我的面，删掉了一批日期比较早的文件。操作生产环境有指定的电脑，那台电脑上看 pdf 文件是没有后缀的，图标也是一张白纸，加上当时在场的人也都没有太在意，根本没有发现这些“交易文件”不太对劲。
看着大概就长下面这样，谁也没有好奇的去看看里面是什么。
所以新任运维人员会定期去删除老旧文件，也就是以前的电子合同！！！
我当时就给技术总监和项目经理打电话，三个大老爷们大半夜跑到单位附近的肯德基研究对策。好在数据都在数据库里，技术总监捅咕了几天，写出来个脚本把所有被删的文件重新生成了一遍。但是服务器空间不够又传不上去，就跟甲方爸爸说电子合同这块设计不够完善（前任技术总监背锅），我们想要优化一下，不要钱的那种。
“事故”尘埃落定之后，项目经理想要追责却发现这锅只能他自己背，除了他全都是后来的......
在那个公司干了一年多，工资涨了三次，但我还是离职了，毕竟「屎」是真的难吃......当我把项目交接出去的时候，我就想起我在项目里留下的注释（屎），露出了和（幸）蔼（灾）亲（乐）切（祸）的笑容。
