什么是技术债务
“技术债务”这一概念是沃德·坎宁安在1992年提出的，指的是开发团队在设计或架构选型时从短期效应的角度选择了一个易于实现的方案，但从长远来看，这种方案会带来更消极的影响，亦即开发团队所欠的债务。
技术债务是开发团队在质量目标和约束目标平衡之后的结果，目的都是为乐最大化的交付价值。技术债务除了长远的不利影响之外，近期交付的价值却是客观的，能够迅速推出新产品，适应快速变化的市场。
那么究竟谁该为技术债务负责，或者说改怎样消除技术债务？
既然是“技术债务”，那么是不是意味着仅仅是技术人员负责呢？当然不是，尽管技术人员重构代码是减少技术债务的重要手段，但是其他角色也应该充分发挥其作用，毕竟要消除技术债务需要重构的不仅仅是代码。
部门LEADER
敏捷的一个重要原则是“不断关注技术是否优秀，设计是否良好”，作为Leade应该意识到没有最好的架构，只有更合理的架构，从决策层面去考虑现有的资源配置是否合理，决策应该具有前瞻性。
Product Owner
产品负责人（PO）主要负责收集业务需求，并按照优先级放入迭代，交由开发人员按照迭代计划开发。PO应该意识到偿还技术债务的重要性，在向迭代中输出需求时应该给技术团队预留重构代码的时间。
架构师
架构师应该认识到重构架构的必要性，并投入精力来分析代码重构的影响并适当的重构架构。同时，系统的架构应该和整个公司的技术架构保持一致。
测试工程师
在将每个代码更改部署到生产之前，都必须进行测试。基于重构的代码或设计，测试工程师需要重构测试用例，某些测试用例可能是多余的，不再需要；某些测试用例可能必须更新。在实施这些更改时，测试工程师应回归测试，保证正常交付。
基础设施团队
不仅仅是重构代码，有时候整个服务架构需要重构，这时有可能也需要相应的基础设施重构，这时候就需要开发，测试，架构和基础设施团队紧密合作。在比较成熟的Devops团队中，这种合作很常见。
综上，适当的技术债务可以加快整个团队价值的交付，正如战略性的债务规划可以优化公司是资产配置。技术债务的重要性应该是自上而下整个团队的共识，它不仅限于代码，而是涵盖整开发周期的所有阶段。定时的偿还技术债务可以保障系统的稳定运行，提振团队士气。
总而言之，我们很容易用非黑即白、非好即坏的眼光看待世界，但构筑软件要远比这要复杂的多。如果单一的认定技术债务是团队失误，那产品将永远无法适应快速变化的市场。如果盲目认定技术债务总是好的，最终技术债务的积累终将会导致整个系统的崩溃。如果能始终保持清晰的头脑掌握均衡之道，那么技术债务可以为团队带来巨大红利。
