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

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

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

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

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

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

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

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

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

…

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

重构 or 维护，这是一个问题？

即便技术债务让很多开发人员不爽，但是要想明白完全推翻还是继续维护，依旧是一个巨大的难题，这既需要考虑现有业务的稳定性、也要平衡后续的开发和维护成本。通常，如果业务可以正常有序的运行，管理者很难主动提出重构整个代码。但是，如果不对技术债务进行妥善管理及合理规划，组织或者开发人员很可能会陷入崩溃。

重构，就是在不改变外部行为的前提下，有条不紊地改善代码。为了保障软件的外部行为，唯一的办