做技术工作这么多年，面临一大困惑，并不是遇到了不能突破的技术，或者无法解决的难题。而是如何处理技术债务。
这些年，在业务强力驱动的大背景下，随着项目和迭代的深入，都会陷入越来越多的技术债务，即使我天天强调架构设计的必要性，代码质量的重要性，但是在我所在的团队里，不少同学面对债务的时候都选择了“先凑合上，以后再改”。
想必做业务开发的同学是能感同身受的，能正常排期已经很不错了，更别说不少项目还需要倒排，大家开始保守和折中，经常会听到“不敢动，一动过去的项目可能会受到影响” “感觉问题很复杂，要改的代码会有很多，这次改不完，要不下次吧” 。
听下来，似乎很有道理，但是如果仔细分析，还是有解决方案的。
在风险可预知、可控制的情况下做改动，比风险不可控的情况下突然某一天爆发当然要好的多。很多问题是不能拖的，我们总想保证眼前的事情不出问题就好，但是代价就是不断的贻误战机，等后续控制不住的时候，更来不及了。所以，我们需要对问题进行排优先级，优先级高的问题，无论如何都要立刻解决。
在时间有限的情况下，当然不可能什么问题都去一次性解决好，正确的选择是控制范围，抽出精力去高质量的完成一部分工作，而不是把所有工作都低质量的完成。低质量完成的这部分，后续很可能需要花2倍乃至3倍的时候来修复它。
以我过去十多年的经验，我可以负责任的说，“以后再改”或者“下次再说”，只会有两种结果：
1. 项目处于开发阶段，虽然大家都想把系统做得更好一些，但是团队成员都陷入大量的新功能开发中。
2. 项目处于稳定阶段，现在时间空出来了，但是在线上跑得似乎挺好，有时间做去重构或者加强，还不如把时间放在开发新项目中。更别说了，改坏了，口诛笔伐不会少的。
要想回过头来把一件事做好的难度，远远大于重新做一件事情。
以后再改=不改
下次再说=免谈
所以，今天的事情今天做。
描二维码或手动搜索微信公众号【架构栈】：ForestNotes
欢迎转载，带上以下二维码即可
点击“阅读原文”，所有【架构栈】近期的架构文章汇总
↓↓↓