文章首发于公众号 松花皮蛋的黑板报
最近在我身上发生了这么一件事。我主要负责内容创作的，提供了一个写入的逻辑接口，但是在校验链中对图片来源空间包括域名进行了校验，你可以理解空间是一种业务名位置，空间涉及到精细化成本管理。接口使用者在测试时发现写入失败，因为图片不合法。那碰到这种情况，如果是你，你是另外提供一个图片转链服务呢？还是写入时判断是否是他在调用然后对其图片特殊对待呢？还是强调规范然后让使用者自行解决呢？
接口使用方觉得不应该由他们来承担这种改造，不应该过度关注服务提供方的内部细节，毕竟上传的图片都是京东的图片。但是呢，如果由我来处理，校验链改动又是件很棘手的事，或者对其来源单独放开图片校验，这又是一个极其个性化的需求。我之前说过，接口不应该为个别服务。而且，调用方不遵守我约束的规范，响应异常很正常。婆说婆有理，公说公有理。最后组织干系人讨论一番，结论是短期上先对其来源内容不进行任何机审，长期上对校验链进行改造。
你看，在协作中很容易因为项目紧迫对质量妥协，从而引入技术债务。不是还有长期方案吗？别得意太早，需求是永无止境的，你可能根本来不及对其改造，或者把这事给忘记了。日积月累，最后难以维护。
那对技术债务如何进行管理呢？
我们先来对技术债务下个定义。我通过引入一个烂设计解决了一个在很短时间内不可能完成的事。就好比借款买房。不过我们知道一个软件系统内部质量差的话，不管是一不小心造成的还是由于能力问题造成的，它都会使得我们在软件修改或添加新功能时，需要的工时远远超过预估值。也就是说技术债务和经济债务一样，都是需要偿还的，刚提到的额外付出的工时就是偿还的利息。
在下定义时其实已经指明了该怎么处理，就是我们可以专门花一些额外的工时重构相应的烂代码。就好比对待财务债一样，少量多次地偿还。借助偿还财务利息及本金的思维，我们可以很方便地识别出需要干掉哪些烂设计。如果有一个很烂的系统，我们不需要为其添砖加瓦，这个烂设计就不是问题，也就是说，只有需要修改老旧系统的代码时，才有技术债利息的事。烂设计但稳定没问题的代码不需要调整，与其相反，那些高频修改的代码区域需要格外敏感地重构，因为这些的利息率是相当陡峭的。代码越是修改，引入烂设计的风险越大。
总之，因为技术债务的存在，如果后续需要添加紧急需求的话，还是老老实实把技术债务管理起来吧！通过重构和代码评审加强代码质量，让待解决的缺陷越来越少！让产品经理和项目经理排期专门处理技术债务！
文章来源：www.liangsonghua.me
作者介绍：京东资深工程师-梁松华，在稳定性保障、敏捷开发、JAVA高级、微服务架构方面有深入的理解