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

导读:现今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所有的服务和方案(package)进行评价。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”.)

 

原文作者:Ferenc Mihaly    编译:伯乐在线 – 潘文佳

【如需转载,请标注并保留原文链接、译文链接和译者等信息,谢谢合作!】

 

 

收藏 评论

关于作者:潘文佳

潘文佳:软件工程师。从事iPhone/iPad、Android手机应用开发。关注移动应用产品设计和市场展望。(新浪微博:@小粉豬潘小佳) 个人主页 · 我的文章

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部