技术债：什么时候借，什么时候还

不是每条捷径都是债

满足当前需要的简单代码不是债，即便它不通用。债是有意识地选择一个以后要付出更多代价的方案——一处已知会分叉的重复、一个推迟的测试、一个撑不过增长的数据结构。

因为无知写出的烂代码不是债，而是未来的bug。这个区分很重要，因为处理方式不同。

什么时候值得借

当你还不知道这个功能会不会留下来的时候。为一个可能一个月后就删掉的东西建完美的基础设施没有意义。

当有真实的时间窗口时——一次发布、一个客户、一项法规。但那就要记下推迟了什么、在代码的哪里，以及什么信号会迫使你回来。

怎么在不停下一切的情况下还

「我们停一个月来整理」几乎从来不会被批准。真正有效的是：边走边还——每次碰到有问题的区域，就顺手改好一点。以及像给功能分配一样，给维护分配每个周期的固定比例。

优先在经常碰的地方还。两年没人打开过的丑代码不是你的问题。