什么是好的API设计？

摘要：有人言，API设计是编程工作中最难的事情。甚至有人认为至少要有10年的工作经验才能接触它。不过这里提出了一个引人思考的问题：究竟是构建什么样的库需要花费10年的时间去学习？

有人言，API设计是编程工作中最难的事情。甚至有人认为至少要有10年的工作经验才能接触它。其实通过好的培训或导师学习这个进度可以缩短很多，也有这样或那样的时候，一些没有经验的程序员却设计出好的API。不过这里引发出一个问题：“究竟是构建什么样的库需要花费10年的学习时间？”

在走出校门后，我很幸运地加入到Atalasoft公司，这是一家生产设计API的公司。在这里我受到了严格的训练。我的导师Steve Hawley是一个喜欢把大部分时间都花费在研究各种困难问题上的人，并且他会把这些问题压缩到一个非常精美的包里。Steve没有太多的耐心教他的下属，他爱好刻录光碟，在这样的环境下，虽没达到青出于蓝而胜于蓝的地步，但却让我学到很多。

在他的价值观里是没有清晰明确的声明或者条条框框的东西，我称为90-9-0.9。他希望90%的人仅通过剪切和粘贴几行代码就可以解决常规问题。下面9%的目标是用来进行简单地配置，通过查看文档以及技术支持来解决问题，甚至有些问题在几分钟内就可以解决。0.9%的人会用各种乱七八糟的方式来扭曲你开发的库，有时是因为性能原因，有时却是利用其他一些你意想不到的古怪（但可执行）手段。为客户的需求牺牲0.9%是完全正常的，只要保证客户需求可以实现且文档按照要求显示出来。

最后，还有1%的人会误解你的产品能力，这些人会让你非常不高兴。忽视还是重视？最好做个市场调查，看看他们的是否值得你去扩展库且让他们成为其中的一员。

Atalasoft的条形码产品是一个很好的例子，在产品上花很多精力去仔细调优和预处理，扫描许多文档且没有发现问题。预处理后，在许可证允许的前提下默认会全力尝试各种类型的条形码。这已经相当快了，在这么短的时间里可以给任何人进行扫描操作。尽管有时候会借助一些昂贵的设备给用户进行大规模批量化扫描，但速度还是不够理想，所以扫描者可以修改一个简单的枚举属性进行配置。偶尔有些扫描的确很困难，比如扫描一个带有条形码的香蕉。对于这样的事情，可能会让你中断乃至更换条形码引擎。但是谁会拿着这样的产品去读狗身上剃出来的条形码呢？如果你是这样的人，建议你去寻找其他产品用吧！

第一次看到这种情况的时候，我认为这样的设计真糟糕。整个组件就像一个非常不统一且基于DIY（do-it-yourself）事件的插件系统。虽然如你所见，Atalasoft不会为一名架构宇航员的美感进行优化，他们会为减轻客户支持负担而进行不断调优。正如我不喜欢用面向对象的思想来编写内部库一样，在开放一个所有级别都能操作的简单接口上，我认为没有比这更好的范式。

在过去的两年里，我一直在Bayard Rock公司负责API方面的工作，我们一直在研发一些反洗钱方面的项目。这意味着会做许多小型或中型实验项目并且在以后会被整合到同行大的平台上。在大多数情况下，Atalasoft风格的黑色装箱（black-boxing）是起不到任何作用的。我们只有一个客户并且我们会根据他们的需求调整我们的外部API。

然而，在一个细粒度级别中代码重用是非常重要的，在这种情况下，最重要的是构建大型库，即把许多分类函数快速的组合在一起（通过简单的组合和没有全面的单元测试），目前，我们正在进行优化实验并且快速发展我们的组件。

那么，什么是好的API设计？其实，正如Steve所言，没有什么清晰明确的框架可套，也更没有什么捷径可走。我们既需要按照常规来进行设计，还需要综合客户要求将我们的设计理念融入进去，当然，得预防那些像扫描香蕉那样稀奇古怪的事情的发生。或许这就是为什么它会如此困难？我们也曾发表过《设计公共API的六个注意事项》文中作者根据自己的亲身经验总结了几条API设计注意事项，大家不妨一起品尝下！