欢迎访问 licqi IT技术
我们一直在努力

为什么“开发人员友好性”是API设计的核心

Douglass C. Smith 教授在 2006 年 IEEE 的报告中指出:后者的进程和发展将超越具体算法语言的发展。实际上是,开发人员也应该注意到这一点了:开发过程中的阻碍从学习算法和数据结构转换到了选择,学习和使用层出不穷的 API 上。但是很多程序员没有意识到 API 的优劣所导致的区别,以及为此需要设计好的 API 所要付出的努力。

微软在 API 设计上是很费心血的,这种努力和专注始于上世纪 80 年代 Windows 的诞生。他们理解一个平台的成功取决于这个平台所能吸引和拥有的开发者(Steve Ballmer 的视频 ”developers,developers,developers” )。 .Net 的首席架构师 Krzysztof Cwalina 出了一本专门《.NET 设计规范:约定、惯用法与模式》 指导开发人员。相似的,Sun(Oracle)也有相关的 Java SDK 的书籍。在一次采访中,Sun 的前任首席架构师,Joshua Bloch (现任职 Google)洋洋洒洒地总结了 19 页 Sun 在 API 设计上的理念。同样的,SAP 雇佣了 Carnegie Mellon 大学的研究人员具体研发新的网络服务接口(web services interfaces)。这些业内大佬们的实例无不给了我们一个信号,API 设计在推动软件使用和程序开发中的价值。

译者注:本文通过学术统计报告理论上证实 API 质量的重要性,循序渐进地例证:API 的优劣如何评判,API 的改进能多大程度地提高编程效率,以及为什么我们需要一个对开发人员友好(Developer-Friendly)的 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 的设计质量直接联系到编程的实际效率。2007的一份研究报道的数据表明 API 上哪怕是细微的变化,例如使用构造函数(constructor)取代工厂方法(factory methods)也可以大幅度地提高程序员的编程效率。他们的数据显示,使用 constructor,不管程序员的经验、技术的区别,他们大多能在同样短的时间内完成;而使用 factory methods,程序员们所需要的时间可以相差 10 倍。也就是说 factory methods 的 API 很打程度上取决于使用者。而取决于个人的工具不是一个好工具。相似的报道显示了编程效率可以相差 10 倍如果一个方法被放到不同的 class 里面。

很多时候在 API 软件不能很好地被使用的情况下,程序员会被指责太自我,或者恐惧新事物,不确定,疑惑(FUD)。但是实际情况是,API 的质量不够好才是主导因素。常见的问题是 API 的文档不够清晰明了;API 的方法太情景锁定(specific to scenario);API 有太多 Dependencies,与其使用它,还不如自己写来地快。我们可以得出结论,只要 API 的质量不得到提高,软件的采用率也就不会上升。

 

为什么“开发人员友好性”是 API 设计的核心
 

什么是好的 API

什么是好的 API?什么是程序员需要的?API 需要什么质量去吸引程序员?我们的设计努力应该付出在哪里?

第一点:intuitive: 直观

什么是直观的?具体又如何实现?Wikipedia 上解释直观(intuitive)“不需要刻意努力的理解”(understanding without apparent effort),Merriam Webster 的解释是“不需要刻意有理推导来获取知识或者认识的力量”(“the power or faculty of attaining to direct knowledge or cognition without evident rational thought and inference”)。细说开去,我们可以用一个博士学位来讨论人类的认知过程,我们就不展开了。就 API 设计来讲,intuitive design 就是站在使用者的角度,保持逻辑一致。

第二点,simple: 简洁

这个会在以后的博文里面具体展开。这里我们就说一个纲领:需要平衡复杂的功能和简单的用户界面。

第三点是 easy to understand, remember, and use 易于理解、记忆和使用

这是任何专家都会给出的建议,但是实际操作却很难自始至终做到这点。尽量使用程序员们熟悉的逻辑和概念,用他们的语言(逻辑和语法)和他们对话,尽量减少引进新的概念和规则。尊重他们熟悉的命名方式,这样可以帮助他们记忆。这些减少刻意学习和使用的设计理念在 API 设计中很重要,因为它直接决定了开发人员适应 API 的速度和程度。

简单适用:程序员没有太多时间去评估一个 API 的好坏去决定是否使用。大多数时候,我们就试用两个方法,看看好不好用。API 设计应该鼓励试用:核心情景必须能被简单采用,而且要有实例(sample code)来帮助采用。其二,API 要安全(safe)。这个包括两点,一是本身那个情景(scenario)要稳定。其次,如果出现问题,错误报告要全面、明确。

最后一点:documented 文档备案。

拿到新的 API,我们程序员会直接动手,而不是读说明书。如果没有人读,APIs 到底需要文档吗?动手是浅尝辄止,我们叫了个方法,然后它做了意料之中的事情,至于它有可能会出现什么问题,然后有什么解决方法,或者同样的事情,是否有更加有效的方法完成,一行程序是不能了解的。这个就是为什么我们需要文档,全方位、多角度的解释(Redundancy),不是简单的重复同一种内容(repetition)。

特定功能性 API (purpose-made APIs)

好的 API 是设计出来的。以上所列举的 API 的特性和优点不会自然流露在程序里面,把一组能被重复使用的独立函数放在一起不是一个好的 API。软件与软件之间的界面会在独立板块的结界出现,但是这些界面如果不是结构上设计好的,他们放在一起不会是好的 API。这个不是因为程序员的个人技术好坏,而是实际操作过程中容易迷失全景的概念。并且这样生成的 API 很难维护,每次更新或者改错都会引出新的问题。Erich Gamma 说过“好的 API 不会是偶然的发生,而是刻意的出现。他们是一笔巨大的投资”。API 设计应该作为一个单独任务,从实际写程序的过程中独立出来。设计出来的 APIs 是 purpose-made APIs. 他们应该包括文档备案(documentation),实例(code samples),教程(tutorials)和单元测试(unit tests)。他们鼓励不同的采用方式,支持快速有效的用户端,如此才能与时俱进。

最后,正如 Joshua Bloch 所说:“公共 API,就像钻石,恒久美,永流传。你只有一个机会去把她做好,请竭尽全力。”

(“Public APIs, like diamonds, are forever. You have one chance to get it right so give it your best”.)

原文:http://blog.jobbole.com/10197/

赞(0) 打赏
未经允许不得转载:licqi IT技术 » 为什么“开发人员友好性”是API设计的核心
分享到: 更多 (0)

评论 抢沙发

评论前必须登录!

 

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏