编者按：在看到这篇文章的时候还挺有共鸣的，因为在开发时我们常说要避免产生“技术债”，所以往往现实的种种压力总会让这个美好的愿望落空。所以文中的一句“问题不在于消除债务，而在于管理债务”很有道理。如果你是一位正在迷茫期的开发者，这篇文章我非常推荐你看看原文。
“技术债务”，这个词听起来有点陌生，但如果你在软件开发这一行做过几年，肯定对它不陌生。Eric Allman 在这篇文章里，把这个概念讲得更透彻了，并且分享了一些策略与方法。
1992 年，Ward Cunningham 在 OOPSLA 会议上首次提出了 “技术债务” 这个概念。他将其比作 “借债”，尤其是那些由于各种原因未遵循最佳实践的代码。技术债务不仅限于新编写的代码，还包括文档不全、错误信息不明确、使用低效算法等问题，这些都是工程师在面对截止日期、工具成本和技术能力等压力下做出的权衡。
技术债务和金融债务有相似之处，都需要偿还，并且会产生 “利息”，即由于技术债务导致的额外成本。例如，2011 年加州大学伯克利分校的 CalMail 系统崩溃，原因在于未及时升级系统以应对容量问题。尽管这种技术债务是出于预算紧张的情况下有意为之，但最终带来了巨大的问题。
技术债务的影响是全方位的。客户、帮助台、运维、工程师、市场营销、管理层，每个人都会感受到它的存在。管理技术债务如同管理金融风险，需要谨慎规划和及时处理，否则可能导致系统崩溃或公司倒闭。
技术债务的管理对于系统的短期和长期成功都至关重要。 Construx Software 首席执行官兼首席软件工程师 Steve McConnell、软件设计师 Martin Fowler 提出了不同类型的技术债务分类方法，帮助人们理解和管理这些债务。
McConnell 将技术债务分为短期战术性和长期战略性，而 Fowler 则从鲁莽 / 审慎和有意 / 无意两个维度进行分类。这些分类有助于团队在项目初期和后期更好地识别和处理技术债务。
技术债务不仅仅是开发人员的责任。运维部门也会因为不升级硬盘阵列、未能记录系统文档等问题而产生技术债务。
文中有一句——
Technical debt is inevitable. The issue is not eliminating debt, but rather managing it. 技术债务是不可避免的。问题不在于消除债务，而在于管理债务。
管理层在决策过程中需要平衡各种因素，理解技术债务的长期成本，并制定还债计划。频繁发布周期虽然能快速获得用户反馈，但如果不及时解决技术债务，也会导致系统迅速积累问题，甚至拖垮整个项目。
有效的技术债务管理需要跨部门协作和全面的风险管理策略。客服人员、运维工程师和市场部门都需要了解技术债务的影响，并共同努力减轻其负面效应。优秀的管理层能够平衡风险与收益，制定合理的项目计划，确保系统的可维护性和长远发展。
最后，正如 Fred Brooks 在《人月神话》中所说：“计划扔掉一个版本——你终会这么做的。” 这句话提醒我们，即使是短期原型也需要慎重对待，因为它们很可能会最终成为交付给客户的产品。技术债务虽然不可避免，但通过有效管理，可以避免其对系统和组织的长期负面影响。