每周总得有点思考。
朋友圈看到个挺有意思的标题
“假如彩票中了一百万，能还清技术债吗？”
我仔细想了下，可能还真的还不了（手动狗头）。
一般来说，我们应该怎么偿还技术债呢？
当然，现实情况，线上故障往往是技术债偿还的第一驱动力。。。
1、还不完的技术债
技术债这个东西，只要业务还在运行，我相信 “永远还不完”。
一方面，业务迭代为先，很少有时间和资源投入偿还历史技术债。
另一方面，业务迭代过程中，总是会因为各种妥协，引入新的技术债。
所以从这两方面来看，技术债都是永远还不完的。
2、如何管理技术债
管理技术债最有效的方式：
让技术债可见。
如何做呢？
原则一：创建一个专门的技术债清单，清晰地列出每一项技术债。
团队成员在发现新的技术债时，可以随时将其添加到技术债清单中。
技术债清单的形式可以因团队而异，例如使用技术债白板贴在墙上或使用便利贴或卡片记录在白墙上。
原则二：将技术债纳入缺陷管理系统，与其他功能BUG一同记录。
这样，开发团队在解决功能BUG时，能够时刻关注技术债的存在。
原则三：为技术债创建产品待办项，确保其参与每个迭代的需求排期。
每个技术债的待办事项，应该具备明确的优先级与风险说明，在每次敏捷迭代计划上，需要跟其他需求、BUG一起评估优先级，决定是否放入当前迭代。
通过以上原则，我们可以有效地让技术债可见，并确保开发团队时刻关注和考虑技术债的解决。
3、如何偿还技术债
偿还技术债的时候，也有一些方式方法可以参考，来最大效率、最低成本偿还技术债。
原则一：不再迭代的产品，一般不考虑技术债。
行将就木的产品、一次性原型、不再迭代的产品，任何额外的开发工作都是浪费，更不用去考虑偿还技术债。
原则二：难啃的技术债，尽量“分期付款”
在某些产品中，技术债的难度非常高，历史包袱非常重。
团队要一次性付清所有的技术债难度很大，就可以采取“分期付款”的形式。
我们可以把技术债拆分为更小，更容易修复的一个个的小问题，像偿还房贷一样，每个月都去偿还一部分。
每次迭代开发需要承担多少目标技术债，由整个开发团队在迭代计划会议上协商解决。
原则三：尽量和产品迭代结合，顺势而为。
将技术债的削减工作与客户有价值的需求结合在一起，有利于产品负责人合理安排需求的优先级。
这样可以确保在开发过程中同时考虑技术债的解决，以及满足客户需求，提高产品的整体质量和用户满意度。
当然，我们也能通过这个原则来甄别技术债，避免浪费时间去清偿实际不必要的技术债。
希望真的能中一百万彩票，我就不用去还技术债了～～
往期热门笔记合集推荐：
- HBase原理与实战笔记合集
- MySQL实战笔记合集
- Canal/Otter源码与实战笔记合集
- Java实战技巧笔记合集
原创：阿丸笔记（微信公众号：aone_note），欢迎 分享，转载请保留出处。
