程序员都有祖传代码，是真的吗？

首先，基本上大部分都是有祖传代码的，几乎每个公司都会存在祖传代码。在代码界，有一个令程序员闻之心惊、谈之色变的存在——祖传代码（legacy code）。相信很多接触编程的人都对祖传代码有着难以言表的恐怖体验。如果不改这个祖传代码，就难以实现新的需求，支撑新的业务。但是一旦改了这个代码，改之后新出现的bug绝对能让人失去理智。

祖传代码，前人程序员留下的“宝藏”代码，这种代码多多少少都会存在些问题。运气好点的会碰到by xxxx多少年的注释，运气差的连注释都没有，各种奇葩的逻辑，甚至直接一大段看不懂的代码。这一般就是程序员们所说的祖传代码，祖传代码又称作“屎山”、“历史遗留代码”。碰到这种代码，程序员们最好不要去优化去动它，因为可能会引发后续一系列的问题。所以遇到这种代码，一般程序员会有两种应对方法。

1、如果这个代码已经被应用

主要是以少动为主，因为程序优化极其困难，如果必须需要改动，最好是弄清楚这段程序的边界，将这段程序封装起来，并且提前做好更改方案。

2、如果这个代码还在开发中

首先了解通读代码，如果祖传代码逻辑很难理解，务必重新写并且重新调试，趁着项目没上线先把这个程序改好吃透，省的为以后维护这段程序埋下隐患。

亚马逊程序员工程师曾经形容他们的代码:“一座很大的屎山，你见过的最大的山，每次你想修正一个bug，你的工作就是爬到屎山的正中心去”。由此可见程序员们大多数对于“祖传代码”都是有抵触心理的，以至于一看见就觉得头疼。每当大家都说“前人栽树，后人乘凉”，但是在程序员们的眼里这句话是不成立的，甚至是厌恶这段话的。因为技术大牛都搞不定“祖传代码”，更别说新手小白了。

前段时间，有这样的一个话题，非常的火热，那就是关于程序员的，新入职程序员吐槽老员工写的代码就像是“一坨屎”！这样的言论瞬间就引起了程序员们的讨论。

感觉公司各种各样的祖传代码都是令新人虎躯一震的代码，因为有时候你根本不知道它是干嘛的，甚至觉得它毫无用处，关键是 还绝对不能动，碰一段改半年，别问我怎么知道的。

自此以后，遇到一些看着很奇怪的代码压根儿碰都不敢碰。

有时候心血来潮改点东西代码从头错到尾动都不要动，我试过了。

有时候当你只删了一行代码时，你都不知道为啥会发生各种各样的情况。

有程序员认为，别看现在像是一坨屎，等你改了之后就发现，这坨屎还挺香！新入职的员工，总是觉得自居最厉害！

有程序员认为，等你摸索一下就会发现，把这坨屎冲了，这整个厕所都得塌！不要眼高手低，存在即合理！

有程序员认为，一般情况下，这样的屎都是祖传的，这都累积了不是一天两天了！千万不要动，接着改就是了！

有网友爆料称，之前有某程序员动了公司的祖传屎山，半年之后还没改完，羞愧难当，怒交辞职报告！从此青史留名，年轻人，还是要踏实点好！

有程序员老前辈表示，现在的年轻人，都是眼高手低，看着别人都不如自己，觉得自己是最厉害的！还是先沉下心给老员工打打下手再说吧！

截取某网友的一段评论:你以为看到祖传代码已经很悲催，但是有的代码八代单传更悲催，你以为八代单传很悲催，但是发现有的代码断了香火，你以为断了香火的代码最悲催，但是你发现了无字天书。

   程序员被戏称为“码农”，天天与代码打交道的他们按理说应该对代码有着深厚的感情基础，但在每个科技公司都有这样一种代码：多数程序员们都怕遇到，有经验老码农有时候也束手无策，往往一步错、步步错，动了一小行，改大半月。相信很多程序员都被这种代码折磨过，就是大名鼎鼎的“祖传代码”

与其它的“祖传”不同，其他行业的祖传说明有传统有根基、品质好信誉好，可以说是前人栽树，后人乘凉。但代码如果挂上了‘祖传’二字就意味着无数修不完的bug了。一般来说祖传代码就是前辈留下的代码，很多新人在刚入职的时候都会先熟悉项目代码，在熟悉的时候肯定会碰到各种奇形怪状的代码，各种分支进不去，各种逻辑不通，编码风格的统一。每当我们抱着疑问的态度去问那些老码农的时候，老码农也会两手一摊：“不要问我，我来的时候就这样了。”

Reddit 上有关技术债务的话题再次引起程序员的广泛讨论，面对由错误的或不理想的技术决策所累积的债务，程序员到底是该继续维护还是推倒重写，这个决定应该依据哪些因素来最终决定？如何避免在技术债务上浪费过多时间？本文，InfoQ 针对这一话题采访了多位国内技术从业者，试图对这一问题进行深入剖析。

对任何一家公司而言，在不断发展的过程中会出现很多“技术遗产”，这其中的部分遗产没有文档，甚至连注释都语焉不详，一旦引入新的需求和框架就可能出现混乱、冲突等，这部分代码很难将其称之为“技术资产”，称作“技术债务”会更加准确。

在知乎上，同样聚集了很多工程师对这一问题发表看法，比如：写代码不写文档和测试用例，写出来的代码就不是资产，而是技术债务。

开发人员的工作比较多面，一方面开发新的需求，另一方面又要维护他人遗留代码。作为运维，技术债务让我每天需要进行频繁的 BUG 修复上线…

传统观点认为，工程技术团队应该为代码库（也就是技术债务的所处环境）建立一种直观的感受，了解其对公司的影响，而后在组织内建立信任。如果首席架构师强调重构核心代码，那么，开发者通常就得按照指示行动。诚然，如果公司可以对技术债务建立起一种共识与信任文化，这将有利于挽留优秀的工程师，并保持业务良好运作，但这往往需要多年努力。