关于技术债务（Technical Debt）的问题，是应该推翻（重写）还是维护（偿还），主要取决于以下几个因素：

1. 债务规模和类型

• 轻量级的技术债务：如果是小的、简单的代码问题，比如一些不规范的命名或小范围的代码重复，通常可以通过代码重构逐步修复。
• 中等债务：如果代码设计不合理或模块之间耦合度太高，那么逐步偿还可能比较困难，这时就需要评估代码重写的必要性。
• 大型债务：如果是深层次的架构问题或系统老旧到影响性能和稳定性，可能推翻重写更有效。这种情况通常发生在架构落后、性能瓶颈难以优化的系统中。

2. 业务需求与时间压力

• 短期交付压力高：如果业务需求快速变化，推翻重写的风险和时间成本可能较高，此时逐步偿还技术债务可能更合理。
• 长期稳定的系统：如果系统处于相对稳定的维护阶段且有足够时间，重写可能是更具战略性的选择，可以从根本上提升代码质量。

3. 团队资源和技术能力

• 技术债务的偿还需要团队有充足的技术资源和代码维护能力，能够有计划地逐步改进。
• 推翻重写通常意味着需要更高的技术实力和时间资源，包括架构设计、测试和过渡方案，因此也需要评估团队是否具备这种能力。

4. 风险与收益分析

• 推翻重写的风险：可能会引入新的问题，包括业务逻辑变化、数据迁移、上线风险等。在复杂的系统中，推翻可能不现实。
• 偿还债务的风险：持续修复可能会拖延交付时间，或者在高债务情况下加大维护负担，使系统更加难以维护。

5. 技术债务的演进风险

• 技术债务具有累积性和蔓延性，如果不及时偿还，后期的维护成本会越来越高。因此，如果技术债务积累到一定程度，且维护难度超过了开发团队的掌控范围，推翻重写可能是必然选择。

综合考虑

在实际项目中，可以结合"推翻+偿还"的策略。可以先逐步偿还较轻的技术债务，确保系统能够继续稳定运行。同时，对于根本性的设计问题，可以将重构和重写规划为长期技术债务的清理目标，逐步减少技术债累积的风险。

所以，是否推翻还是维护，应该根据项目现状、团队能力、风险评估以及业务需求来综合判断。