提供多个APIs会减少代码重用吗？

Question

在一个组织中，假设您有一个内部工具，用于不同的团队和不同的用例。这个包提供不同语言的API。

• 可以说，拥有多个API可以让更多的人使用这个工具，因为他们不需要学习新的语言，也可以使用他们最喜欢的语言。
• 另一方面，人们也可能认为这使得代码重用变得更加困难。如果A组使用X语言并使用该工具开发了一个很好的脚本，B团队只有在使用X语言的情况下才能重用该脚本。

我的问题是:根据您的经验，拥有多个API(可能会有更多的人使用该工具，但他们无法共享代码)或单个API(使用该工具的人较少，但他们可以共享代码)的全球影响是什么？

示例

一个组织已经使用Python和APIs创建了一个内部包来获取天气预报。

一个团队使用Python创建了一个新的组件，它为用户的位置汇总天气预报和流量(借助另一个工具)。

虽然这段代码很有用，但它与天气预报工具的API无关，它不够通用/防弹/有意义，不足以成为一个单独的包。

另一个使用Python的团队可以重用这个新组件，只需做一些小小的调整，而使用C的团队将不得不从头开始重写整个组件。

Answer 1

提供多个API不会降低您自己的项目在这些API之间重用自己的代码的能力(如果设计得很好)，也不会限制在项目之间共享代码的能力(否则，我们每次生成新程序时都必须重写操作系统)。

我要把你的问题改写为：

提供多个API是否限制了我的客户端共享和重用代码的能力？

简短回答:不。

更长的答案:其他的东西可以，而不是API的数量。

重用本身没有难以克服的技术障碍。尤其是在这个时代。

有许多库允许一种语言调用另一种语言。这可以通过解释另一个程序(嵌入式插件、lua、tcl等)来实现.(甚至c)，或者通过JNI、COM、HTTP、SOAP等将调用编组到编译的组件，或者甚至通过直接/动态链接组件。

即使组件已经不支持它，也应该有合理的可能为组件提供一个shell，它允许shell脚本(从任何桌面/服务器语言中可用)与它一起工作。

因此，从用户的角度来看，没有技术上的原因可以解释为什么他们不能与希望使用它的其他人分享他们的好脚本。

事实上，主要问题是任何公共服务/图书馆维护者的问题。当您共享代码时，有许多附带的责任。

• 它必须是可靠的-这个代码是依赖的，它必须工作，或合理地失败。
• 它需要是稳定的-更新应该保持接口行为。打破的变化应该被标记，有工作周围，和迁移路径。
• 它需要被文档化--你不能在不知道如何使用的情况下使用最优秀的脚本。
• 它需要维护-- Bugs发生，漏洞被发现，上游系统发生变化。这些问题必须解决。
• 它需要被分发--您不能访问的代码是不可用的，无论是在服务后面，还是在二进制中，还是作为源。
• 它需要反馈回路(一个社区)-代码只是一个个体社区的假象，他们知道问题正在解决，这是有史以来最重要的事情。代码只是对解决方案的最佳猜测。

我不会考虑让我的软件依赖于至少没有这些附带属性的其他软件。作为一个API提供程序，您知道这些事情是多么的重要。

如果您自己的客户端共享代码的能力对您的平台/应用程序至关重要。考虑提供类似于GitHub的服务，或者某种形式的包管理器。这样既可减轻下游发展商的负担，又可减轻客户的负担。它还会提高你自己软件周围的社区意识，让这些人彼此接触。他们将研究如何具体地重用彼此的代码。

*边注：C可以嵌入功能齐全的python环境.和Python可以很容易地被C库扩展。

Answer 2

另一方面，人们也可能认为这使得代码重用变得更加困难。如果A组使用X语言并使用该工具开发了一个很好的脚本，B团队只有在使用X语言的情况下才能重用该脚本。

正如其他人所指出的那样，如果功能在本质上是不平凡的，那么我会以两种语言都可以访问(并因此重用)的方式对其进行集中。

我的问题是:根据您的经验，拥有多个API(可能会有更多的人使用该工具，但他们无法共享代码)或单个API(使用该工具的人较少，但他们可以共享代码)的全球影响是什么？

一般说来，我一直在开发支持多种语言的产品，这些语言甚至可以追溯到提供自己专有语言的产品(在只嵌入Python或Lua这样的东西之前，它还很流行。)

实际上，您确实倾向于放松在这些不同语言中工作的开发人员之间的协作。他们通常会发展不同的社区和心态，以及思考和做事的方式。脚本社区将以不同的方式思考和处理问题，并可能产生与Java开发人员社区或本地C++插件开发人员社区不同的小实用程序代码来共享。而且，这些不同的组之间可能存在一些冗余的工作，无论是以代码复制的形式还是其他形式(例如:甚至出版书籍和记录如何编写软件)。

从积极的方面来说，您可以扩展为开发做出贡献的人员，并且能够使用多种语言，有时对单个开发人员甚至是有用的。嵌入式脚本语言可能会更快地编写一些东西，并且更容易分发和移植(因为没有需要构建的二进制文件)和更安全(例如:不可能分割错误)，而当性能是合法的问题时，本机代码可能很有用。

另一个使用Python的团队可以重用这个新组件，只需做一些小小的调整，而使用C的团队将不得不从头开始重写整个组件。

如果该组件足够有用，可以共享，那么我将设法避免这个限制。在我们的例子中，用脚本编写的插件可以执行/评估用本机代码编写的插件，反之亦然(在我们的例子中，这些都是实际的需求，因为我们的插件体系结构是关于插件注册组件，这些组件将相互评估/执行，重点是让实现插件的语言变得不重要)。

我发现，重复的工作更多的是在一些小事情上，而这些小事情并不能提高生产力--就像文档工作、实用功能、共享代码片段等中的一些小重复，以及实际上使用不同编程语言进行语言和思考的开发人员提供的更宽松的协作。

如果我可以闲逛一下的话，我也不总是会发现积极地最大化代码重用而不是仅仅务实地寻求将代码重用保持在实用和可维护的范围内是有效率的。在最坏的情况下，你可以看到委员会在一些中央库(例如:当开发人员争论一个包围盒类是否应该存储中心和半大小或两分钟/最大向量时，如果他们仅仅使用单独的类(在本地项目中使用单独的类)，那么应该如何在某些中央库中设计一些非常琐碎的功能(例如:开发人员争论是否应该存储中心和半大小或两分钟/最大向量，而在本地项目中，仅仅使用单独的类就完成了大量的工作)，更多的争论、脚尖步进和最糟糕的是，发现功能被转移到中心位置，这些地方在生产中还没有经过彻底的测试和验证，还没有足够稳定地指导许多依赖关系，只有这样，它才能得到重复的中心变化，从而破坏一切使用它。

因此，这些天来，我发现把代码重用的程度提高到如此狂热的程度并没有多大用处。我并不是说容忍大规模的复制工作，或者错误被复制，或者诸如此类的东西，而是为了把它放松到一个务实的水平(比如，我们不需要花2个小时在开发人员会议上讨论如何设计一个可重用的边界盒类，在这样的一致意见似乎是不可能的情况下完全满足每个人的需求，如果有几个开发人员在他们的项目中为他们的需要开发一个特定的类，那么就不会发疯)，并对开发人员正在实现的最终目标进行可靠性和测试，即使在他们可能做的事情上有一点冗余。

Answer 3

你应该从不同的角度来看待这个问题。在上面有一个具有多个接口的模块的意义是永远不会像这样重用。重用本身并不是一个目标，它充其量只是一个结果。关键是要有一个重要逻辑的实现，这样它就可以由正确的人集中地控制和维护，并且它将永远是相同的逻辑，无论是哪个用户。