构建还是购买？开发者生产力与灵活性
作者：Charles Mahler / 用例, 开发者
2022 年 6 月 3 日
导航至
本文最初发表于 The New Stack。
软件开发中一个常见的争论焦点是，是使用现有的工具或服务（它们提供更好的开发者生产力），还是坚持使用更底层的工具或定制构建的解决方案（它们提供更多的控制，并可能提供更好的性能和灵活性）。这可以归结为构建还是购买的决策。
这两种方法是当前许多科技行业意识形态冲突的根源
- 云与运行您自己的硬件
- 在应用开发中使用更高级别的动态编程语言与更低级别的语言
- 自托管与托管服务
- 内部定制构建的工具与现成的软件即服务解决方案
当使用开发者工具时，简单到使用客户端库与直接通过应用程序编程接口访问之间的选择就说明了这种冲突。在本文中，我将介绍在选择客户端库与直接使用 API 时需要考虑的一些因素，以 InfluxDB 为例。正如我们将看到的，开发者生产力和效率与灵活性和控制之间的这种潜在权衡也可能在软件开发的其他领域中看到。
标准的论点
以下是关于构建与购买的辩论中，每一方提出的一些主要论点。
购买团队的论点
- 更专注于核心业务。
- 团队可以更快地行动和添加功能。
- 预构建的开源工具或专门的托管服务，效率更高，可以节省成本。
- 硬件资源已经变得如此便宜，以至于开发者时间更有价值，因此提高开发者生产力应该是首要任务。
反对这种观点的常见论点是，这种心态导致了“软件吞噬世界”。许多较早的企业将软件视为应外包的成本中心，但最终被认真对待软件并将其视为竞争优势的科技公司所取代。
为了捍卫使用预构建的解决方案，像 Instagram 和 Dropbox（以及许多其他公司）这样的公司是云服务的早期采用者，这使他们能够更专注于产品而不是基础设施。
构建团队的论点
- 移除收取溢价的服务提供商，可以节省成本。
- 开发 内部专业知识 可以带来长期利益。
- 与更通用的工具相比，可以为公司特定需求开发工具，而通用工具可能缺乏灵活性。
- 更少的外部依赖项，可以防止停机或安全问题。
反对这一方的常见论点是，许多科技公司对用户的价值主张不是关于他们的技术在幕后如何运行。其他批评包括“不要重新发明轮子”的建议和 非我发明 综合征的诊断。大多数用户根本不在乎幕后工作原理；他们只希望最终结果能够正常工作。
另一方面，Amazon Web Services 能够发展成为一项业务，是因为亚马逊在为其市场运营自己的服务时积累了内部知识。这种内部知识最终催生了一个万亿美元的云计算市场，彻底改变了科技行业。如果亚马逊遵循常识并试图外包这些运营，他们今天就不会在云行业中处于领先地位。
客户端库与 API
为了使事情更具体一些，让我们看一个非常简单的例子，它展示了双方的优点。开发者是 InfluxData 的 InfluxDB（一个 时间序列数据库）的主要受众。它同时提供 客户端库 和通过 API 直接访问数据库，以便为开发者提供最适合其用例的选项。
客户端库开箱即用地提供最佳实践，因此开发者可以快速开始读取和写入数据。诸如批处理请求、重试失败的请求和处理异步请求之类的事情都得到了处理，因此开发者不必考虑这些。对于希望测试 InfluxDB 或将其快速集成到其应用程序中以存储 时间序列数据 的开发者来说，使用客户端库是有意义的。
另一方面，需要更多灵活性和控制的开发者可以选择 直接与 InfluxDB 的 API 交互。一些公司在添加外部依赖项方面有漫长的流程，或者已经有用于处理服务之间通信的现有内部库，因此客户端库不是一种选择。许多 公司 已经创建了他们的产品作为在 InfluxDB 之上构建的扩展或平台，这得益于 API 的灵活性。但这比使用客户端库需要付出更多的努力。
从小规模来看，以 InfluxDB 为例，您可以看到最佳选择将取决于具体情况。对于一家将使用 InfluxDB 来监控其软件或非其产品核心部分的相邻任务的公司来说，客户端库是有意义的，因为它们允许快速集成和开发者生产力。
另一方面，如果一家公司将 InfluxDB 用作其产品的核心部分，或者由于其他情况需要更大的灵活性，则可以使用 API。通过提供选项，InfluxDB 试图为开发者提供两全其美的方案。
没有唯一的正确答案
尽管人们可能希望对这些类型的问题有一个明确的答案，但现实情况是，这取决于每个公司及其业务所处的位置。需要考虑的两个主要因素是
您的软件项目对您作为企业的核心价值是否至关重要？
就产品与市场的契合度而言，您的企业是否处于可以通过构建定制软件来获得额外优势的位置？
对于仍在努力寻找其产品与市场契合度的初创公司而言，速度是最重要的因素，专注于速度更有意义。对于一家 более 成熟的公司来说，构建定制工具、提高软件效率或迁移到您自己的硬件可以提供优于竞争对手的优势。
