逐步改善，设计优秀的API( 五 ) _api

【逐步改善，设计优秀的API】一切皆有可能。但对于那种开发人员之间的沟通问题，最好还是要描述清楚。如果你要设计一个API ，那么在这个API没有成熟前，最好能够清楚地告诉其用户：“这个API还没有完善，你可以尝试使用这个API ，但一定要小心。”在有了稳定的版本以后，还可以骄傲地告诉用户：“这是我开发过的最好的API！放心使用这些API ，我可以保证它能一直提供支持。”这样做可以俘获API用户的“芳心” ，让他们“拜倒在你的石榴裙”下。但请一定要注意，对于API ，要能够清楚地标识其当前状态，以便用户了解相应版本是否可以稳定使用。
如果想告诉类库的用户当前发布的版本还不稳定，那么最简单的方式就是把其版本标识为0.x 。因为它还没有到达1.0版本，表示还在开发中，也就可能还会有所变化。不管用哪种版本标识方式，最重要的是要让API的用户清楚地知道当前版本的状态，以便他们决定如何使用该API 。
逐步改善
我已经提过多次，这里再多重复一次，第一个版本远非完美。事实上，不仅第一个版本，哪个版本都不会是一个完美的版本。不管怎么样，设计的场景不可能完全准确，不可能完全符合之前的方案。对于版本间的变化，也有两种极端的处理方式：一种是逐步改善，还是一种则是完全重写。
什么叫逐步改善呢？比如说，增加了一个方法或一个类，或者是向DTD文件中加了一个新的元素，又或者是增加了一个能够影响类库功能的属性。在保证老版本API能正常运行的情况下，演化出新版本API 。这种改进是一步步进行的。
关于“逐步改善”有一个谬论，就是说“因为只有少许的改动，所以以前用户使用老版本API编写的程序可以在新版本上继续运行” 。每一个改变都有潜在的风险，因为它可能引发一个甚至更多的不兼容问题。每一个不兼容问题（即使看似微不足道）都会反映到客户开发的程序中，可能就会产生非常严重的后果。开始时，要能够把真正的内容与最初的设想保持一致，而且任何一个小的改变都不会引发任何问题，这样才可能避免阿米巴虫模型出现。
如果考虑到向后兼容性问题，那么也许重写一个全新的版本可能是更现实一些，这样可以清楚地告诉类库的用户，如果要移植到一个新版本上，就要花费一些时间进行代码迁移工作。与前面“逐步改善”的方式相比，这样做显得更诚实一些。但这样做也在很多方面都存在问题。首先，如果新旧版本保持兼容，那么迁移的工作量就非常小，否则完全重写一个实现需要投入大量的时间，还需要一个充分的理由来说服用户接受这样的方式。如果没有令人信服的原因来说服用户，相信用户宁愿守着老的版本。要知道，每个项目最重要的问题就是日程计划的安排。如果没有一个充分的理由，没有人愿意花费大量的时间将代码升级到新版本上，他们会去做其他更重要的事情。
如果用这种态度为API的客户提供服务，那么就不会带来一个好的合作氛围。但还有更坏的合作方式，就是完全不提供迁移的方案。有时候，对于一个愿意迁移到新版本的API客户来说，还是可以接受一个API完全重写。但如果说让所有的用户都只使用老的版本或者强迫他们立即都升级到最新版本，对于分布式开发来说，这两种方式都不现实，正如本书一开始所说的那样。如果API经常产生重大的变化，而且要强迫用户随之迁移，那么客户就会转向其他的方案，而放弃现有的API 。