程序员遇到祖传代码：技术债是推翻还是维护？

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

你在写技术资产还是技术债务？

技术债务是由 Ward Cunningham 在 1992 年的报告中创造的比喻，被定义为当我们有意或无意地做了错误的或不理想的技术决策所累积的债务。简单来说就是为了快速解决问题而采取的不规范方案，比如开发工程师将某个判断条件写死、测试工程师未进行深入自动化测试、架构师运用了一个即将过时的框架。

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

在知乎上，同样聚集了很多工程师对这一问题发表看法，比如：

写代码不写文档和测试用例，写出来的代码就不是资产，而是技术债务。

开发人员的工作比较多面，一方面开发新的需求，另一方面又要维护他人遗留代码。

作为运维，技术债务让我每天需要进行频繁的 BUG 修复上线

…

传统观点认为，工程技术团队应该为代码库（也就是技术债务的所处环境）建立一种直观的感受，了解其对公司的影响，而后在组织内建立信任。如果首席架构师强调重构核心代码，那么，开发者通常就得按照指示行动。诚然，如果公