应对库接口原型变更
也许你经常遇到这类情况：你在代码里使用了别人提供的第三方库，当库升级为新版本后，你的代码在编译时无法通过，提示接口原型错误，经查发现原来是该第三方库提供的某接口的原型发生了变化，比如原接口被删除、增加了参数、参数减少了、修改了参数类型以及返回类型发生变化了等等。你也许会不由自主的大骂一句：F**k。
我们换位思考一下，假如你是某个库的Owner，当你遇到需要修改接口原型的情形时，你应该如何去做呢？这里考量出一些方法供参考：
1、谨慎评估：是否一定非得修改接口原型这么做，是否有其他办法解决此问题，毕竟修改接口原型涉及改造面太大了；
2、退而求次，另立新接口，并告知调用者本库的那个老接口已经被标识为obsoleted了。以后就不要用再用该接口了，而是直接用新的吧；
3、如果实在迫于无奈，只能变更接口原型才能达到目的，那么也要小心驶得万年船：考虑到你的客户，小心翼翼地规划库版本，可将那些无需变更接口的需求放入小版本中，支持快速发布，满足调用者需求；而那些只能通过变更接口才能实现的需求，可考虑都汇总到后续发布的某个较大版本的分支中，这样发布间隔变长，也在一定程度上降低了调用者为适应新库而进行修改的频度。
其实我们很是希望在进行库设计时，一旦接口原型敲定，就再也无需变化。但现实是残酷的，变化是永恒的。我们只能更加关注和完善前期设计，尽量减少而却无法避免接口原型变更的可能。
评论