forward/backword compatible during develpe

向前兼容 forward compatible
一句话总结，前面版本的程序可以打开后面版本的程序。
向后兼容 backword compatible
一句话总结，后面版本的程序可以打开前面版本的程序。

产品开发过程中的前后兼容

在安卓动态壁纸的开发过程中，前后兼容原则上是都要兼顾的：

• 向前兼容：客户端版本V1可以使用用户在客户端V2上Diy出来的作品
• 向后兼容：客户端版本V2可以使用用户在客户端V1上Diy出来的作品
• 向前兼容：客户端版本V1可以使用服务端REST API V2
• 向后兼容：客户端版本V2可以使用服务端REST API V1

前两者diy的作品，实现前后兼容比较容易，因为作品引擎这块总体上不会有大的架构变化

后两者 服务端REST API这块因为业务的需求变化多端， 客户端想要在开发的过程中前后兼容还是有些麻烦

客户发一旦发版，想要改一个字的代码都无力回天；如果客户端这块做好了向前兼容， 服务端这块做向后兼容就容易多了; 做的不好，服务端就不得不用新的REST API url 来实现客户端新版本的功能

客户端这块做好向前兼容， 需要在写代码 的时候多考虑产品以后的可能性

比如：客户端的系统消息界面， 首次写代码的时候如果只有一个消息类型，对应一个展示类型， 就需要做类型判断展示

if(rest.type == 'type1') { ...}

当新版本的REST API 返回的数据列表中 rest.type ='type2', 'type3'...时，就不会影响老版本的客户端
如果没有这个if判断，也就是说没有这个type字段的判断， 那么新版的REST API 就只能换一个跟老版本api url不同的url来对接新版本客户端了，只能这样来避免给老版本客户端带来bug

另外服务端REST返回的数据经常是有字段增加的， 客户端这块当然是要容许此情况，做到向前兼容

代码中的前后兼容

比如，定义了一个函数

def func(v="vvv"):
    pass

后面的版本中，修改了这个函数

def func(v="vvv", type):
    pass

这就会导致向后兼容的bug，正确的做法是：

def func(v="vvv", type="old_type"):
    pass