设计好的API( 五 ) _兼容

如果考虑到向后兼容性问题，那么也许重写一个全新的版本可能是更现实一些，这样可以清楚地告诉类库的用户，如果要移植到一个新版本上，就要花费一些时间进行代码迁移工作。与前面“逐步改善”的方式相比，这样做显得更诚实一些。但这样做也在很多方面都存在问题。首先，如果新旧版本保持兼容，那么迁移的工作量就非常小，否则完全重写一个实现需要投入大量的时间，还需要一个充分的理由来说服用户接受这样的方式。如果没有令人信服的原因来说服用户，相信用户宁愿守着老的版本。要知道，每个项目最重要的问题就是日程计划的安排。如果没有一个充分的理由，没有人愿意花费大量的时间将代码升级到新版本上，他们会去做其他更重要的事情。
如果用这种态度为API的客户提供服务，那么就不会带来一个好的合作氛围。但还有更坏的合作方式，就是完全不提供迁移的方案。有时候，对于一个愿意迁移到新版本的API客户来说，还是可以接受一个API完全重写。但如果说让所有的用户都只使用老的版本或者强迫他们立即都升级到最新版本，对于分布式开发来说，这两种方式都不现实，正如本书一开始所说的那样。如果API经常产生重大的变化，而且要强迫用户随之迁移，那么客户就会转向其他的方案，而放弃现有的API 。
总而言之，还是要准备使用增量改进的方式！人们需要软件加以改进，但改进时引入的伤害也应该最小化，特别是要避免重新编写的那种大变化。如果因为API设计上的问题，使得无法增量改进，那么也许会有充足的理由进行一次重新编写，但这种大的变化应该限定于开发方式上的一些基础性变化。本书的大部分篇幅都会讨论用于API增量改进的设计实践。如果出现了很大的变化，我们会同时强调要为一个API提供多个大版本类库。只有这种方式才能保证API能够变得更好，而且使API用户的痛苦最小化。