程序员被戏称为“码农”，天天与代码打交道的他们按理说应该对代码有着深厚的感情基础，但在每个科技公司都有这样一种代码：多数程序员们都怕遇到，有经验老码农有时候也束手无策，往往一步错、步步错，动了一小行，改大半月。相信很多程序员都被这种代码折磨过，就是大名鼎鼎的“祖传代码”
与其它的“祖传”不同，其他行业的祖传说明有传统有根基、品质好信誉好，可以说是前人栽树，后人乘凉。但代码如果挂上了‘祖传’二字就意味着无数修不完的bug了。一般来说祖传代码就是前辈留下的代码，很多新人在刚入职的时候都会先熟悉项目代码，在熟悉的时候肯定会碰到各种奇形怪状的代码，各种分支进不去，各种逻辑不通，编码风格的统一。每当我们抱着疑问的态度去问那些老码农的时候，老码农也会两手一摊：“不要问我，我来的时候就这样了。”
Reddit 上有关技术债务的话题再次引起程序员的广泛讨论，面对由错误的或不理想的技术决策所累积的债务，程序员到底是该继续维护还是推倒重写，这个决定应该依据哪些因素来最终决定？如何避免在技术债务上浪费过多时间？本文，InfoQ 针对这一话题采访了多位国内技术从业者，试图对这一问题进行深入剖析。
对任何一家公司而言，在不断发展的过程中会出现很多“技术遗产”，这其中的部分遗产没有文档，甚至连注释都语焉不详，一旦引入新的需求和框架就可能出现混乱、冲突等，这部分代码很难将其称之为“技术资产”，称作“技术债务”会更加准确。
在知乎上，同样聚集了很多工程师对这一问题发表看法，比如：写代码不写文档和测试用例，写出来的代码就不是资产，而是技术债务。
开发人员的工作比较多面，一方面开发新的需求，另一方面又要维护他人遗留代码。作为运维，技术债务让我每天需要进行频繁的 BUG 修复上线…
传统观点认为，工程技术团队应该为代码库（也就是技术债务的所处环境）建立一种直观的感受，了解其对公司的影响，而后在组织内建立信任。如果首席架构师强调重构核心代码，那么，开发者通常就得按照指示行动。诚然，如果公司可以对技术债务建立起一种共识与信任文化，这将有利于挽留优秀的工程师，并保持业务良好运作，但这往往需要多年努力。