技术债（technical debt）是指软件在开发或修改时，为了眼下更快完成而采用的做法，导致以后的修改更慢、风险更高或成本更大。这个说法把走捷径比作借钱：你更早拿到成果，但此后每当有人需要绕开这个捷径工作，都要支付“利息”，直到根本问题被解决。
对委托开发网站、App 或内部系统的企业来说，技术债会影响响应客户的速度、每次修改的成本，以及系统能否安全地保持更新。
技术债从哪里来
大多数系统都背着一定的技术债。它通常来自日常决策，例如：
- 工期紧张：功能先用临时方案上线，原计划以后再整理，但“以后”一直没有到来。
- 没有自动化测试：每次修改都只能靠人工检查，开发人员自然不愿去动脆弱的部分。
- 框架和依赖项过时：代码库、框架和服务器软件在不断更新，每跳过一次，下一次升级的跨度就更大。
- 复制粘贴的代码：同一段逻辑在多处重复，改一条规则就要在几个地方分别修改和测试。
- 缺少文档：系统怎样运行，只有某一位员工或以前的供应商清楚。
- 不再维护的插件和主题：在网站上很常见。作者停止维护后，插件就不再有修复，包括安全修复。
非技术管理者能注意到的信号
不懂代码，也能从以下情况发现技术债：
- 小改动，比如给表单加一个字段或调整一条价格规则，花的时间远超预期；
- 修好一个问题，另一处功能却出了错；
- 新来的开发人员要很长时间才能安全地修改系统；
- 安全补丁和版本升级一再推迟，理由是“怕影响其他功能”。
有意的技术债与无意的技术债
技术债不一定是错误。有意的技术债是主动权衡的结果，比如先用较简单的设计推出 MVP 验证市场需求，并且清楚如果方向可行，这部分以后要重做。只要有记录、有计划，这可以是合理的商业决定。
无意的技术债是在没有人做出选择的情况下积累的：团队当时不了解更好的做法，设计确定后需求发生了变化，或者软件随着时间老化。因为没有人记录它在哪里，这类技术债通常更难管理。
如何管理技术债
目标不是彻底消除技术债，而是让它清晰可见、范围可控，并按计划偿还。具体做法包括：
- 建立清单：简单列出已知的捷径、过时组件和脆弱部分，并注明各自对业务的影响。
- 每次发布预留时间：在每个开发周期中拿出一部分时间做整理，而不是等到大项目时才处理。
- 补充自动化测试：对关键流程做回归测试，修改和重构代码时更有把握。
- 定期更新依赖项：小而频繁的更新，比隔了几年再一次性大幅升级更容易测试。
- 重构：在不改变功能的前提下改善现有代码的结构，最好与新功能开发同步、分小步进行。
- 编写文档：记录系统如何配置、部署，以及与哪些服务对接。
- 代码审查与自动化：由另一位开发人员审查改动，再配合自动运行测试的 CI/CD 流程，可以减少新的技术债混进来。
偿还、暂时保留，还是重建？
并不是每一项技术债都要处理。可以这样判断：
- 偿还：技术债位于经常修改的部分，或者妨碍安全更新。
- 暂时保留：受影响的部分稳定、很少改动，而且风险低。把它记入清单，之后再评估。
- 重建：核心平台已经不再受支持，大部分修改又慢又有风险，修补成本接近重新开发。重建本身也有风险，通常更稳妥的做法是分阶段替换，让旧系统继续运行，直到每个部分都确认可用。
如何与开发商沟通技术债
请开发商或运维服务商从业务角度解释技术债。可以问这些问题：
- 系统哪些部分最难改、风险最高？为什么？
- 哪些框架、插件或服务器组件已经过时或不再受支持？
- 你会先处理哪一项？处理后哪些工作会更快或更安全？
- 每次发布建议预留多少时间用于维护和整理？
- 目前测试、文档和代码审查是怎么做的？
如果签有长期支持协议，最好写明由谁负责更新依赖项和安装安全补丁。我们的软件支持 SLA 一文介绍了这类协议通常包含哪些内容，我们的托管支持及 SLA 服务也负责这类持续维护工作。
常见问题
技术债一定是坏事吗？
不一定。为了更早上线、验证想法而有意承担技术债，可能是正确的选择。问题在于技术债没有被记录，也一直没有偿还。
非技术管理者能衡量技术债吗？
无法精确衡量，但可以关注一些信号：小改动要花多长时间、发布后多久出现一次新问题，以及有多少组件已经超出受支持的版本。可以要求开发商定期汇报这些情况。
重建系统能消除技术债吗？
只能维持一段时间。新系统起步时技术债较少，但如果没有测试、文档、更新和审查，技术债还会重新积累。
技术债会影响安全吗？
有可能。过时的依赖项和不再维护的插件可能收不到安全修复，脆弱的代码也会让团队更晚才能打上补丁。