技术债务在研发领域类似于“金融债务”的概念，大部分情况下是说因为人为妥协，系统的设计和实现没有遵循最佳实践，所以虽然在短期做到了快速交付，但也制约了系统未来的可扩展性，并且埋下了稳定性的风险隐患。就好比你信用卡分期消费，虽然可以立刻满足自己的购买意愿（得到眼前的好处），但同时也会背上一定的负担，在未来必须得偿还。
Martin Fowler 曾发表过他对技术债务的定义，即“技术债务象限”。他根据债务产生时的原因，将技术债务从两个维度分成四个象限：即有意（Deliberate）的还是无心（Inadvertent）的，谨慎（Prudent）的还是草率（Reckless）的。
往往最难的不是解决问题，是根本不知道这里有问题，而下面两种情况在实际工作中最为普遍：
因为能力不足根本没有意识到债务的产生与积累；
因为交付压力进而在技术方案与实现上妥协形成已知的技术债务。
什么是能力不足呢？ 比如开发者编写了低质量或者有潜在风险的代码；对系统的实现和运行不了解，重复代码被大量构造，缺少抽象与沉淀；缺少完善的开发机制和流程把控，比如测试、文档等方面做得不到位……
而交付压力（技术妥协） 则被很多 Leader 认为是产生技术债务最关键的原因，因为项目很复杂或排期压力，不得不在系统的架构设计与代码实现上作出妥协，选择最容易的方式而非最好的方式。甚至会跳过方案的详细设计，直接开始 Coding，不深究代码风格、标准、最佳实践，更进一步则会压缩测试方面的时间与投入，只为了尽早上线。
而当技术债务产生后，因为系统和项目的惯性，债务会积累并使系统散发出一些“坏味道”，这些坏味道有很多个方面，我列了三种最常见的情形，如果你负责的系统中出现类似的情况，那你需要警惕了。 1每次迭代成本增加 2 每次新的迭代bug量居高不下 3 几乎没人能讲清楚系统现在的逻辑
此文章为9月Day026学习笔记，内容来源于极客时间《重学前端》，强烈推荐该课程
