这里的接口指的是团队开发中，模块间的函数接口，或者跨进程的协议接口。
俗话说有人的地方就有江湖，在软件开发当中，有人的地方就有接口，有接口就要考虑兼容性问题。平心而论，一般新软件，前面的版本，考虑太多接口兼容性问题不现实，因为前面的版本改动特别大，两个版本之间面目全非的情况比比皆是。但是到了一定阶段，接口就急需要稳定，因为不兼容的接口带来的成本太高了。
最简单的接口兼容性方案就是永远只新增接口，然后老老实实的等着旧接口自然消亡，当然这个过程非常痛苦，但是习惯了也没有什么。这里还是有几条建议，可以缓解这个痛苦的。
既然选择了新增接口来支持兼容性，就不要再去尝试其他方案，也就是将这条路走到黑，避免多种接口兼容性策略同时生效，反而让使用者糊涂。
项目团队中形成共识，每当新接口和老接口有替换关系时，就尽量在主分支主动升级到新接口，然后让新接口自然在未来某个版本中自然生效。
新接口和老接口在命名上应该有一个自然的替换关系，比如说老接口叫 GetBigBook，新接口叫做GetBigBook2,虽然很俗气，一旦团队内都采用类似风格，也可以接受。将来排查那些GetBigBook没有替换完毕的时候也很方便。
如果新增了参数，尽量将新增的部分放在尾部或者头部，别头部放一个，尾部放一个，减少使用者更换接口时的不适感。好的新接口设计，甚至可以实现批量替换。这里不详细描述了。跨进程的接口协议，可以在使用侧先用函数封装一下组装报文的部分，后面报文格式变了，最终也就变成了函数的替换。
