建造还是购买？开发者生产力与灵活性的比较

作者：Charles Mahler / 用例，开发者
2022年6月3日

本文最初发布于 The New Stack。

软件开发中的常见争论集中在是使用已有的工具或服务，这些工具或服务提供更高的开发者生产力，还是坚持使用低级工具或自定义构建的解决方案，这些解决方案提供更多的控制和潜在的更好的性能和灵活性。这可以归结为是建造还是购买的决定。

这两种方法构成了许多当前科技行业意识形态冲突的根源

• 云服务与自行运行硬件
• 使用高级、动态编程语言与低级语言进行应用程序开发
• 自托管与托管服务
• 内部自定义工具与现成的软件即服务解决方案

选择使用客户端库而不是通过应用程序编程接口直接访问客户端工具时，像选择使用 InfluxDB 这样的简单例子就可以说明这种冲突。正如我们将看到的，这种开发者生产力与效率与灵活性和控制之间的潜在权衡也可以在软件开发的其它领域看到。

标准论点

以下是争论双方就建造与购买提出的某些主要观点。

购买方的论据

• 允许更专注于核心业务。
• 团队能够更快地移动和添加功能。
• 预构建的开源工具或专业的托管服务更高效，可以节省成本。
• 硬件资源已经变得如此便宜，以至于开发者时间更加宝贵，因此提高开发者生产力应该是首要任务。

对此的常见反驳是这种思维方式导致了“软件吞噬世界”。许多将软件视为应外包的成本中心的老企业最终被那些认真对待软件并将其视为竞争优势的科技公司取代。

为使用预构建解决方案辩护，像Instagram和Dropbox（以及其他许多公司）都是云计算的早期采用者，这使得他们可以更多地关注产品而不是基础设施。

团队构建参数

• 去除收取高额费用的服务提供商，可以节省成本。
• 开发内部专业知识可以带来长期利益。
• 可以开发针对公司特定需求的工具，与通用性更强的工具相比，后者可能缺乏灵活性。
• 外部依赖性减少，可以防止故障或安全问题。

对此观点的常见反驳是，许多科技公司对用户的承诺并不在于其技术在幕后是如何运行的。其他批评包括“不要重复造轮子”的建议和“非发明在此”综合症的判断。大多数用户根本不关心事情在幕后是如何运作的；他们只希望最终结果能够正常运行。

另一方面，由于亚马逊内部知识的发展，亚马逊网络服务（Amazon Web Services）能够作为一个业务而发展起来。这种内部知识最终导致了价值万亿美元的云计算市场，彻底改变了科技行业。如果亚马逊遵循常规智慧并试图外包这些业务，他们今天就不会在云行业中领先。

客户端库与API

为了使事情更加具体，让我们看看一个简单示例，该示例显示了双方积极的一面。InfluxData的InfluxDB是一个时间序列数据库，其开发者是InfluxDB的主要受众。它既提供客户端库，也提供通过API直接访问数据库的方式，为开发者提供最适合其用例的选择。

客户端库提供了一些最佳实践，以便开发者可以快速开始读写数据。诸如批量请求、重试失败的请求和处理异步请求等问题都得到了处理，这样开发者就不必考虑这些问题。使用客户端库对于希望测试InfluxDB或快速将其集成到其应用程序中以存储时间序列数据的开发者来说是有意义的。

另一方面，需要更多灵活性和控制权的开发者可以选择直接与InfluxDB的API进行交互。一些公司有繁琐的过程来添加外部依赖，或者已经拥有处理服务之间通信的现有内部库，因此客户端库不是选择。许多公司已经创建了作为InfluxDB扩展或在其之上构建的平台的产品，这是由API的灵活性所实现的。但这比使用客户端库需要更多努力。

在微观层面，以InfluxDB为例，你可以看到最佳选择将取决于具体情况。对于打算使用InfluxDB来监控其软件或非核心产品的相邻任务的公司来说，客户端库是有意义的，因为它们允许快速集成和开发者效率提升。

另一方面，如果一家公司打算将InfluxDB作为其产品的核心部分，或由于其他情况需要更多灵活性，API是可用的。通过提供选项，InfluxDB试图为开发者提供两全其美的解决方案。

没有唯一正确的答案

尽管人们可能希望对这些类型的问题有一个明确的答案，但现实是这取决于每个公司及其商业状况。需要考虑的两个主要因素是

您的软件项目对您作为企业的核心价值是否至关重要？

您的业务在产品市场匹配方面是否处于有利地位，可以通过构建定制软件来尝试获得额外的优势？

对于仍在寻找其产品市场匹配的初创公司来说，速度是最重要的因素，专注于这一点更有意义。对于更成熟的公司来说，构建定制工具、提高软件效率或迁移到自己的硬件可以提供竞争优势。