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