谈谈技术债务

文章首发于公众号 松花皮蛋的黑板报
做者就任于京东,在稳定性保障、敏捷开发、高级JAVA、微服务架构有深刻的理解

最近在我身上发生了这么一件事。我主要负责内容创做的，提供了一个写入的逻辑接口，可是在校验链中对图片来源空间包括域名进行了校验，你能够理解空间是一种业务名位置，空间涉及到精细化成本管理。接口使用者在测试时发现写入失败，由于图片不合法。那碰到这种状况，若是是你，你是另外提供一个图片转链服务呢？仍是写入时判断是不是他在调用而后对其图片特殊对待呢？仍是强调规范而后让使用者自行解决呢？

接口使用方以为不该该由他们来承担这种改造，不该该过分关注服务提供方的内部细节，毕竟上传的图片都是京东的图片。可是呢，若是由我来处理，校验链改动又是件很棘手的事，或者对其来源单独放开图片校验，这又是一个极其个性化的需求。我以前说过，接口不该该为个别服务。并且，调用方不遵照我约束的规范，响应异常很正常。婆说婆有理，公说公有理。最后组织干系人讨论一番，结论是短时间上先对其来源内容不进行任何机审，长期上对校验链进行改造。

你看，在协做中很容易由于项目紧迫对质量妥协，从而引入技术债务。不是还有长期方案吗？别得意太早，需求是永无止境的，你可能根原本不及对其改造，或者把这事给忘记了。日积月累，最后难以维护。

那对技术债务如何进行管理呢？

咱们先来对技术债务下个定义。我经过引入一个烂设计解决了一个在很短期内不可能完成的事。就比如借款买房。不过咱们知道一个软件系统内部质量差的话，不论是一不当心形成的仍是因为能力问题形成的，它都会使得咱们在软件修改或添加新功能时，须要的工时远远超过预估值。也就是说技术债务和经济债务同样，都是须要偿还的，刚提到的额外付出的工时就是偿还的利息。

在下定义时其实已经指明了该怎么处理，就是咱们能够专门花一些额外的工时重构相应的烂代码。就比如对待财务债同样，少许屡次地偿还。借助偿还财务利息及本金的思惟，咱们能够很方便地识别出须要干掉哪些烂设计。若是有一个很烂的系统，咱们不须要为其添砖加瓦，这个烂设计就不是问题，也就是说，只有须要修改老旧系统的代码时，才有技术债利息的事。烂设计但稳定没问题的代码不须要调整，与其相反，那些高频修改的代码区域须要格外敏感地重构，由于这些的利息率是至关陡峭的。代码越是修改，引入烂设计的风险越大。

总之，由于技术债务的存在，若是后续须要添加紧急需求的话，仍是老老实实把技术债务管理起来吧！经过重构和代码评审增强代码质量，让待解决的缺陷愈来愈少！让产品经理和项目经理排期专门处理技术债务！

文章来源：www.liangsonghua.me

做者介绍：京东资深工程师-梁松华，在稳定性保障、敏捷开发、JAVA高级、微服务架构方面有深刻的理解