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

但每一个设计良好的API ，都有着相同的动机。所以要有一个团队来配合API的作者对API进行评审工作。
一旦有一个API需要改动，任何人都可以提交一个改变的请求。其他人则需要在代码正式提交前，进行一次评审，检查新调整的内容是否符合一个优秀API的基本要求。比如说，我们会按照“优秀API规则”进行检查，保证能够满足这些规则。下面详细地列出了这些规则。
用例驱动的API设计：设计API时，要基于一些具体的场景和对API的认识进行抽象分析，最终给出设计。

文章插图
API设计的一致性：API往往是由多位设计者来完成的，但整个团队中必须能够保持“最佳实践”的一些基本原则。一个接口设计得再好，只要它违反整个团队的一致性，就宁愿退而求其次。
简单明了的API：简单而且常见的任务应该更容易处理。如果基于用例驱动的方式进行设计，就可以很容易地通过那些可以简单实现的场景来验证这些API是否可以完成那些重要的用例。
少即是多：一个API对外提供的功能应该只包括用例中说明的功能。这样可以避免出现需要的功能与实际提供的功能两者之间出现差异。
支持改进：以后也必须能够维护这个类库。如果出现新的需求，或者原作者离开，都不会出现放弃这个类库的情况。
一个API的生命周期
开发API的过程其实就是一个沟通交流的过程。沟通的双方就是API用户和API设计者。
API有可能是这样产生的，有些人写了一些代码，而另外的人发现这些代码的价值，就开始使用这些代码。在这种情况下， API是以一种自然的方式产生的。随后API用户和API作者有了相互沟通的渠道，开始交流经验，可能发现这个功能一开始的设计并不是很通用，或者说一开始时，作者并没有把这个功能当成一个API来设计。为了让这个功能成为一个API ，他们开始讨论如何进行调整才能改善这个功能。经过几轮的迭代，才会带来一个有用而且稳定的API 。
但再换一个角度来看， API设计者希望在没有对外提供一个API之前就能和相关的用户进行沟通。这种API的开发方式更接近于基于业务的设计方式。在这种场景下，系统中的两个组件间的协定是已经明确的，至少说也是已经有了需求。收集需求，定义问题域，明确用例，再由指定人员来设计API 。现在，其他人员就可以使用这个API ，并可以给出自己的建议，列出Bug ，提出一些功能方面的改进意见。这些建议都有助于改进API ，使其用途更广，也更稳定。
尽管这些API的案例各有其不同的缘由，但有相同的特点：每一个都需要时间来让用户进行试用，并进行反馈，然后才能宣称这个API是可以正常运行的。当然不是说这样做就可以带来稳定的API ，有时候，也有可能最终什么都得不到。如果出现这种情况，最好还是放弃这个API吧。有时候，可能交流的双方无法进行高质量的正式交流。在开始的时候可以简单地聊一下，交流相应的需求，但如果新发布的版本也证明了这种简单的沟通方式并不合适，那么双方也许应该更进一步地进行交流，使得沟通能更简单更有效一些。