Jaroslav Tulach的最新著作《实用API设计》涵盖了软件项目的API设计主题。 Jaroslav讨论了API设计在现代软件应用程序中的重要性，构成良好API的不同因素是什么以及如何实现API框架。 他将他作为NetBeans IDE项目的架构师的经验带到了本书的写作中。 在书中，Jaroslav基于他在NetBeans项目上的经验，讨论了一些有关如何使用Java API（更重要的是如何不使用）的真实示例。
InfoQ与Jaroslav谈了他的新书，写作的主要动机以及其他主题。 访谈涵盖的主题包括软件质量的评估和验证，敏捷和精益软件开发方法论在设计API框架，体系结构和设计评论中的作用。
我们还将为读者提供实用API设计书的摘录 （〜4 MB PDF）。
InfoQ ：编写“实用API设计”书的动机是什么？
Jaroslav Tulach（JT） ：这本书是基于我在过去十年中设计和维护NetBeans API时收集的笔记。 而且，它们基于将NetBeans API知识转移到其余NetBeans开发团队的过程。 大约五年前，我开始考虑将笔记转换成书。 但是，花了一些时间才真正开始。 在其他各个方面，其他任务都陷入了困境。 其他时候，我只是害怕无法完成这本书，以及害怕被出版商拒绝等。
但是，在2007年夏天，我在一次家庭聚会上与妻子的堂兄聊天。 当我告诉他我的疑惑时，他说：“您知道该写些什么；您知道这是一个有趣的话题；您知道自己是该领域的专家。那么……为什么还没有开始写作呢？” 。
每当我完成完成“ Practical API Design”一书的动机时，总是会被我想起这个评论，这在这种长期运行的项目中是可以预期的。 顺便说一下，让我借此机会再次感谢所有帮助我完成本书的人。
InfoQ ：在书中，您讨论了实现模块化体系结构的“组件注入”技术。 总体上，特别是API设计中，诸如依赖注入 （DI）， 面向方面的编程 （AOP）和注释之类的角色设计概念可以发挥什么作用？
JT ：我相信将应用程序模块化为不同的部分是非常可取的。 当这些部分彼此不了解时，甚至更好，以便某人可以从各个独立的部分组装应用程序。 为了使这种由松散耦合的零件进行组装，必须进行某种形式的注射。 Spring风格的依赖注入很好。 java.util.ServiceLoader也可以正常工作。 我将本书的第7章专用于比较这些替代方法和其他替代方法。
曾经有一段时间，人们听到“字节码操纵”这一短语时发疯了。 情况不再如此。 人们不再害怕执行与Java编译器产生的字节码不同的字节码。 但是，如果您告诉他们直接进入.class文件并操作这些位，则担心会返回。 这是为什么？ 我相信这是由于AOP。 AOP使字节码更改正常，而无需了解类文件格式。 实际上，AOP可以看作是字节码操作的高级语言。 它不像直接对.class文件进行更改那样强大，但是它对大众来说是平易近人的，并且通常可以理解。 这完美地说明了良好的抽象使一切变得更有用的原理。 该原理在字节码操作以及API设计领域都是适用的。
在下一版NetBeans IDE的开发过程中，我们开始大量使用批注。 基本上，我们将新的注释定义为基于旧XML的API的外观。 在编译期间，注释由我们的注释处理器处理。 在处理结束时，将生成正确的（旧的和复杂的）XML。 我无法开始描述我们对这种解决方案的满意程度！ 我们的API突然变得更好了。 现在，注册信息已成为Java源代码的一部分。 代码完成自动在IDE中起作用。 在编译过程中，将验证所有注册的正确性。 基于这些经验，我只能向所有API设计人员推荐编译时注释！
InfoQ ：您在书中写过有关如何检查API库质量的信息。 您能否详细说明团队如何对正在编写的软件进行持续的评估和验证？
JT ：程序员之间的共同智慧是设计不能由委员会来完成。 但是，如何在不进行团队设计的情况下设计规模不断扩大的系统？ 不在团队中工作会损害一致性吗？ 是的，部分。 尽管现在和将来的软件项目都是由团队设计的，但大多数人似乎可以在单独工作时保持设计的一致性。 在这样的环境中保持一致性要困难得多，但是肯定是可能的。
像往常一样，有两种选择：要么在质量下降时进行检测，要么在集成之前防止此类问题的发生。 我已经将完整的第16章专门用于这些主题。 我在那里描述需要验证和检查哪些方面以及如何自动检查它们。 这样，我们可以为情况开始恶化做好准备。 此外，本章还介绍了“ API审查”过程，NetBeans团队将遵循该过程在集成之前审查API更改。 这样我们可以防止事情甚至考虑回归。
InfoQ ：诸如SCRUM，XP和看板之类的敏捷和精益软件开发方法将如何帮助参与API框架设计和开发的项目团队？
JT ：问题是，敏捷方法学是否有助于API框架的设计和开发……还是适当地模块化应用程序并将其拆分为具有API的许多库，都会简化敏捷方法学的使用？ 两者都可能是真的。
API设计领域有一些合理的规则。 例如，您需要从一开始就意识到API的第一个版本并不完美。 另外，您需要预想您的用户是谁。 另外两个基本原则是，几乎必须要进行单元测试，并且应该始终以随时准备进一步开发API的方式进行设计。
这些建议中的许多建议也几乎都是敏捷方法论的指导规则。 因此，我认为适当的API设计和敏捷方法只能相互加强。
InfoQ ：您可以讨论您的团队如何在NetBeans开发项目中进行体系结构和设计审查吗？
JT ：我们有两种模式：标准审核和快速通道审核。 后者用于较小，增量，兼容和无争议的更改。 它基于“乐观锁定策略”：准备代码更改diff并将其附加到问题跟踪系统。 然后，人们有一周时间来评论或否决更改。 如果在该时间段内没有人反对，则可以立即应用更改。 这对于单个方法更改或对现有库的类扩展非常有效。
标准审查的目的是审查整个新的库或子系统。 这是一个两轮审查。 首先，我们回顾一下这一概念。 然后，如果该概念被接受，则在集成到主代码存储库之前，将再次检查结果。 所有审阅详细信息都记录在NetBeans网站上。
InfoQ ：在创建可重用的组件库时，软件架构师应牢记的最佳实践和“陷阱”是什么？
JT ：很难一一列举...在《实用API设计》一书中，我花了400页。 :-)但是，让我们来看看一些有趣的事情：“您认为字母API包含什么？” 类的名称？ 大概。 他们的字段或方法的名称？ 是的，如果它们是公共的或受保护的。 但这就是全部吗？
不，不是。 您是否曾经认为应用程序读取的文件是API？ 而且开放套接字也不是API吗？ 那环境变量呢？ 和本地化的消息？ 您的代码产生的文本输出如何？ 所有这些都会影响您的应用程序或库的行为。 它们也可以在外部观察和使用。 因此，它是某种API。 意识到这一点并始终牢记这一点非常重要。
InfoQ ：在当前的经济和市场环境下，软件架构师的角色是什么？
JT ：棘手的问题。 一般的答案是学习提供市场需求。 但是我怀疑没有人真的确定那是什么。 除...
...软件开发中的问题之一与“大爆炸”更改有关，也就是说，在这种情况下，您发现产品存在太多错误和设计问题，并且无法修复，需要完全重写。 到这一点需要很长时间，通常需要在多个发行版中增加证据。 但是，在大多数软件项目的生命周期中，有人提供了执行“大爆炸”更改的机会。 最初，报价被拒绝，因为每个人都知道重写将是痛苦且昂贵的。 然而，在下一个版本中，尽管证据越来越多，但是团队意识到没有逃脱的可能。 到那时，整个项目都停止了，强制对子系统进行不兼容的重写，然后其他团队需要适应变更。 尽管原始计划是多么现实，但此过程通常比预期花费更长的时间。 最后，我们现在有了一个闪亮的新产品，该产品比以前少了很多错误，但只能处理原始功能的一半。 不用说，这根本不是一个有效的过程。
实用API设计书描述了避免这些“大爆炸”更改的最佳实践。 首先，它解释了什么是兼容性，并倡导小的，渐进的，向后兼容的更改，同时始终关注未来的发展。 这种模式根本不需要破坏性的“大爆炸”更改。 另一方面，有时需要进行如此大的更改。 因此，这本书讨论了提供替代共存行为的方法，并解释了在必要时如何桥接它们。
如果我们对应用程序进行模块化，并使用API将每一部分视为一个库，则可以最大程度地减少停止世界的“大爆炸”重写，并用持续的分布式改进代替它们。 起初这可能会稍微贵一些，但长期的拥有成本肯定会更低。
综上所述，对于您的原始问题有以下答案：“也许软件架构师应该了解有关正确API设计的更多信息，并使用它来创建更具成本效益的产品团队。”
InfoQ ：您如何看待即将发布的JDK版本7中的新功能和API，以及诸如Closures之类的已删除功能？
JT ：Java需要的第一件事是每个人都采用的标准模块系统。 最近，我和一个Ruby家伙争论了Ruby中API设计的好处。 最初，“鸭式打字”似乎是Ruby的一大优势。 然后我们同意Ruby的真正优势在于其所有“宝石”及其所有库依赖项……而Java则没有。 这需要解决。
我知道有现有的模块系统。 顺便说一下，其中之一在NetBeans IDE下运行。 但是，绝不是世界上每个图书馆在设计时都考虑了模块化。 这必须更改。 Java语言本身需要支持模块化。 如果我现在能获得Java的模块化，我什至愿意等待几年的关闭。
InfoQ ：如果您必须选择最喜欢的Java语言功能，那会是什么？ 而您最不喜欢的功能呢？
JT ：据说Java有很多缺点。 但是，我想它的缺点之一也是它的最大优点：据说Java很冗长。 没错，您可以使用许多其他语言编写较短的程序来完成相同的任务。 因此，Java非常冗长。 但是，冗长的好处是人们也能够阅读他们所写的内容。 Java程序可由其代码的维护者阅读和理解。 此外，这可以在打印的页面上完成，而无需IDE的“声明”功能和“代码完成”功能。 我想我对Java的冗长性并不真正满意，但是我确实很欣赏Java的冗长性。
InfoQ ：最后，除了您自己的书以外，您还为读者提供IT和非IT书籍推荐吗？
JT ：我的书引用了Effective Java and Gang of Four的Design Patterns书。 这些是必须阅读的，的确是众所周知的。
除了这些，我还参考了彼得·沃彭卡（Petr Vopenka）写的一本关于几何史的完美著作： “欧洲知识的基石” 。 一开始听起来可能很无聊，但事实并非如此，我感到很爱上它。 实用API设计的许多“哲学”部分都是基于该书的思想。 因此，如果您属于发现这些部分有趣的阵营，我建议您注意这本书。 有一个问题：尚未翻译成英文。
InfoQ ：谢谢Jaroslav。
1022
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
