如何正确地进行多语言编程

您正在引入 Erlang；除非您是一家没有现有代码库的新公司，否则这意味着您计划成为一个多语言编程的组织。即使您的路线图计划完全替换所有现有代码，也将会存在一个过渡期，在此期间您必须使用多语言编程。因此，您应该计划适当地支持多语言编程的工作流程。

在本章中，我们将介绍常见的关于多语言编程的神话和错误观念，建议为语言的可行性制定标准，并提出您的组织可能遇到的几个挑战性问题。

多语言编程的神话

当工程师开始讨论将组织转变为多语言编程组织的想法时，会提出很多信念和论点。让我们看看常见的抱怨

• 随着需要支持更多工具和构建链，构建工程变得更加复杂
• 需要审核和维护更多的依赖项以保持所有内容的最新状态
• 随着时间的推移，一些语言会变得不受欢迎，需要付出更多努力进行培训、招聘或重写
• 我们已经在进行多语言编程，并且有一个组件没有人愿意碰，因为一个开发人员曾经用其他人都不知道的语言编写了它

构建工程是一个合理的担忧，就像许多拥有专门 IT 部门的组织为每个开发人员提供相同类型的计算机一样，以减少必须支持的配置数量。话虽如此，随着普遍容器化的出现，这个问题不太普遍。Docker 镜像和 Kubernetes 等运行时已经提供了一种一劳永逸的接口，该接口从本地开发扩展到生产运行。在熟悉编程语言的人员的帮助下维护构建镜像，随着时间的推移，主要降低了所有相关内容的复杂性。

除了使用可以扫描和报告问题的工具外，没有必要的方法可以解决依赖项激增和监控问题。依赖项的表面积主要是一个管理复杂性的问题，并不一定与您使用的语言数量相关。例如，我们看到一个 JavaScript 演示项目的依赖项树大于公司用于整个部门的成熟 Erlang 软件。其他工具（例如依赖项漏洞扫描程序）也越来越普遍地支持 Hex 包。

如果您的公司有一个流程，即每个依赖项都必须由安全团队、法律部门（出于许可目的）和工程师（出于代码质量目的）进行审查，您会发现实际上它效果并不好。人们要么坚持使用预先批准的库列表，要么只审查顶级依赖项。在某些情况下，他们永远不会更新过时的库，因为他们宁愿避免所有繁文缛节。在其他情况下，开发人员会将依赖项写入他们的项目中，以避免在他们觉得必须快速发布东西时跨越多个部门进行审查，最终得到的代码几乎没有经过审查，并且可能质量很差，因为他们可能重写了已有的库。我们认为这是一个组织问题，而不是编程语言问题。

不受欢迎的语言或“难以招聘”的语言始终是一个问题。不幸的是，这不是您可以实际解决的问题，因为没有人知道未来。是让一种主要的语言变得不受欢迎，然后您的整个技术栈都难以配备人员更糟糕，还是让其中一半难以配备人员更糟糕？Python 的情况又如何呢？从 2.x 到 3.x 的迁移非常困难，以至于库和组件基本上将它们视为不同的语言？我们认为，那些不局限于单一语言，而是习惯于在几种语言之间切换（而不仅仅是大量语言）的组织，会训练自己更好地适应编程语言市场的变化。

然后我们有关于某个开发人员不关心组织做什么或知道什么的抱怨，他们开始用其他人都不知道的语言发布东西。该开发人员可能正在将其作为简历填充的一部分，然后在跳槽到新工作后让每个人都滞后。即使您强制使用单一语言，也无法防止这种情况。地狱，开发人员可以通过使用您公司的主要语言但尝试使用该语言或其库支持的新框架或新范式来做到这一点。拥有一个不受支持的 Lambda 可能比已知部署上下文中的一种新语言更棘手。

我们主要认为这种负面行为，即让此类工作完全孤立地进行，是必须解决的流程失败，而不是责怪所使用的工具。

最后，还有一个主要的论点可以反驳。人们普遍认为，使用多种语言会造成障碍，如果您使用一种语言和一个框架，那么您将更容易在开发人员之间进行迁移。事实上，我们将此称为反对多语言编程组织的最大神话。

这是错误的，因为它假设开发人员就像机械部件一样。只要接口相同，它们就可以互换。它忽略了与语言无关的所有内容。不同的团队有不同的习惯和动态，您需要适应。他们在具有不同历史和挑战的项目上工作，可能在不同的领域，具有不同的重点和在工程方式上的权衡。除此之外，即使在单一语言中，迁移也存在成本：不同的框架、库、工具链或这些工具链的不同版本都需要一些适应。

我们认为，总的来说，这些因素代表着一个通常与学习新编程语言一样重要（如果不是更重要的话）的挑战。即使它很重要，学习新语言的成本也低于看起来的那么高，主要是因为它包含了所有这些底层问题，这些问题可能仍然存在于单一语言中。成本看起来很高，因为我们传统上不为任何具有挑战性的事情提供支持，并且在切换生态系统或团队时必须从头开始学习它们。

最低可行语言

基于前面提到的这些神话和常见抱怨，我们建议一种直接解决这些底层问题的方法，无论使用哪种编程语言。我们还提出了必须满足的最低标准，以便采用某种编程语言。虽然最初将这些因素作为必须执行的硬性规则提议可能很诱人，但我们相信，让工程师参与他们的创建将比其他选择提供更好的认可和自我监管。

在决定什么代表最低可行语言 (MVL) 时要记住的第一点是，您希望帮助您的组织成为一个学习型组织，让您的开发人员互相培训以不断适应。目标是指导学习，并为要考虑查看的技术的成熟度级别提供界限。

为此，我们建议使长期支持的成本变得显而易见。只要您的开发人员可以为该支持提供合理的路径，就没有理由禁止该语言。例如，要求回答以下问题

• 如何部署它？
• 如何为其提供可观察性？指标、日志和跟踪支持如何，以及如何将它们添加到项目中？
• 哪些构建工具将被批准供人们使用，开发人员应该如何设置他们的开发环境？
• 提供了哪些测试框架，以及如何将它们与您现有的整体测试标准协调起来？
• 如何编写它的文档？
• 将来我们将向谁询问有关它的问题？我们是否有任何本地专家和支持者？有多少，如果我们低于某个阈值，我们将怎么办？
• 如果您进行 RPC、消息传递、数据序列化，使用特定数据库，应该为每个使用哪些库？是否有必要编写它们？
• 如何处理语言中的代码结构、编写和调试？是否应该提供基本指南或工具？
• 如何招聘这些开发人员？如何培训那些不了解该语言的人？
• 我们是否有任何基本的入门文档来帮助人们开始使用上述任何因素？

根据需要添加或删除问题。您可以对一些问题进行情境化，例如内存占用、前端语言的要求、移动开发、后端语言、桌面软件等。制定您的工程师认为应该提供的基线。以抽象的方式回答它们，不要考虑单一的编程语言。将其中一些项目分类为关键的、不错的和等等。您可能会得到如下所示的表格

建立一个要达成的基本标准，即没有这些标准您就无法采用该语言的关键项目，等等。将其转换为您可以用来验证决策的相当客观的记分卡。否则，发生的情况是 CTO 或架构师会推动他们喜欢的任何技术，而不考虑实际的支持。组织的默认反射实际上是找到某个上级喜欢的东西，并推动它，让组织的其他成员适应这些反复无常。记分卡（无论您想要它多么简单或复杂）旨在让人们意识到采用或更改技术的成本，以及他们需要提供什么来帮助彼此使用它。

针对您要采用的语言运行记分卡，看看您是否真的可以成功地采用它，或者可能缺少什么才能做好它；针对您已经采用的语言运行记分卡，看看它们是否会通过。如果它们没有通过，请从解决差距开始。培养一个以您的工程师认为他们需要更有效地完成工作为指导的知识库。为公司的一些领域专门化和调整需求，看看这将把您带到哪里。

即使在一个强制使用单一语言的公司里，你很可能也会缺少很多“锦上添花”或更高层次的需求；当我们选择将这些支持留给社区处理时，最终也会导致内部支持资金不足。这就是遗留代码库产生的方式。你可能还会发现，不同的团队对他们特定专业领域的事情有着截然不同的判断。那些一直与基础设施组件打交道的团队，最终可能会与那些从事最终用户功能的团队有非常不同的需求。你可以开始专门化评分卡，或将特定领域的元素纳入其中。

生产语言

在迭代你已经建立的所有这些标准时，你应该牢记一些最终目标。例如，你可能希望最终涵盖以下内容（请注意，其中许多内容已包含在本文本中，以便更容易地帮助更多 Erlang 用户）

• 如何安装和设置你的开发环境，包括所有需要的版本
• 经过验证且大多数项目都在使用的库的批准列表
• 围绕启动新项目的流程（设置测试、使用哪些代码检查工具、如何启动 CI/CD、代码片段和模板等）
• 你可以获得帮助的地方（例如内部邮件列表、聊天室或需要联系的人员姓名）
• 学习资源库，可以是书籍、教程、视频或你认为有用的内部文档
• 安全指南
• 使服务或应用程序达到生产级别的待办事项清单
• 如何对你的代码进行基准测试
• 如何为你的代码添加监控
• 架构和贡献指南
• 针对常见问题的运行手册和剧本
• 面试问题

并非所有这些都需要在 Wiki 中进行详尽的教程；一些可以通过结对编程、午餐学习、演示文稿等方式完成。请注意，无论你选择如何帮助人们学习这些内容，你所聘用的或调到不同团队的开发人员都必须自己弄清楚所有这些，许多人没有明确的支持。这种无形的劳动一直在进行。目的是让它变得可见。

在选择支持多语言并呈现你的团队认为有助于他们从一个项目转移到另一个项目（而不创建孤立的技术）所必需的内容时，你实际上可能会使团队之间的切换比只使用一种编程语言而没有这些支持更容易。如果你真的想帮助将这些原则融入你的文化中，表明你重视参与制定和改进标准实践的团队，以及努力将现有代码库提升到理想的卓越水平的团队。要获得足够的参与度来逐步构建这些资源并保持其活力可能很棘手，因此最后一点尤其重要。

简而言之，让我们关注人们如何学习并帮助他们学习，而不是假装他们已经知道一切。准备围绕领域知识的入门指南。规划出你目前服务不足的工程师领域，以及可能需要投资的领域。建立保持特定语言知识和工具活力的社会方式。并可能发现你以前不知道但最终对你的团队完成工作至关重要的因素。