需求变化之版本兼容

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/lovesummerforever/article/details/52275300

        我们常常会遇到这样的问题,一个需求在最初设计的时候是这样,并且发版了该版本,随着时间的发展,需求有了新的变化,或者在之前的需求基础上添加一些业务逻辑。对于互联网来说,需求变动是在平常不过的一件时间了。在需求的变动中,客户端版本和服务器端版本都在不断升级,而我们的用户使用app的时候可能会使用app的很多个版本,所以我们的接口设计就要考虑到客户端的版本兼容问题。

        那如何让接口能应对需求的变化,做到客户端兼容呢?

首先

        作为一名开发人员在设计接口的时候都会遵循接口设计规范,设计模式基本原则,例如,开闭原则,对扩展开放,对修改关闭。当然在设计接口前,产品经理总会说上一句,这个要写活,所以一般为了应对变化,我们在变化的部分上都添加上可配置项,比如绑定手机号是否强制绑定要添加switch,在给用户发放某个奖品的时候,添加switch,为了能够随时关闭某个功能添加switch,总之为了防止以后的变化我们都要想法设法写活。


其次

        要做到灵活的控制,最好那些变化的部分要放到服务器端,比如某个提示语为了防止提示语的变化,而又兼容客户端的版本,所以把一切日后可能变化的提示语都放在服务器端。


再次

        如果某个未在控制范围内的需求,为了能够灵活切换,我们一般会在之前的接口基础上设计V2接口,如果V2上有问题,就随时可切换到V1接口上。为了兼容,我们可以添加新的字段,之前请求的时候没有这个字段我们就设置一个默认值,或者在配置的时候添加某个字段。一定要避免把变化的部分放在客户端,虽然客户端app版本可以升级,但是为保证一部分不会主动升级的用户使用正常,和功能正常,我们的V2接口都是要做兼容的。


总之

        变是不变的,未雨绸缪总好过临渴掘井,但是,如果对于一些虚无缥缈的需求而增加大量的工作量,那就是过度设计了,总之平衡就好。

        就像人的心情一样,大悲大喜都不好。因为平平常常的,总比大悲要好的多。



展开阅读全文

没有更多推荐了,返回首页