本文最初发布于 Dunk 的个人博客。

本文介绍的技术栈帮助 Atmos 在只有 1-2 名全职工程师的情况下，发展到 1 万多个客户。多亏了这个技术栈，我们才得以安全、快速地迭代。我们的效率要比最直接的竞争对手高 10-20 倍，因为我们的工程团队是他们的 10 到 20 分之一。

我们主要是通过减少精神消耗和维护负担来保持效率。我们的产品很多——Web、iOS、Android、储蓄、支票、贷款、存款、作业——单个开发人员要能够理解、维护和改进所有这些产品。

将更多精力放在更重要的事情上

为了最大化编码效率，我们在客户端和服务器端围绕 JavaScript 统一了技术栈——我们没有时间在技术栈的不同部分用 Kotlin、Swift、Svelte 和 Python 复制特性。我们用一台服务器运行所有项目的所有代码——我们没有时间采用微服务。甚至，我们有很大一部分前端逻辑在网页和手机之间共享——我们没有时间把一个东西写（更重要的是调试！）两次。

所有函数都遵循了完全相同的超级简单的代码风格，无论是在 Web 上、移动设备上，还是服务器上。我们很少抽象，并且在所有服务器和 App 中都使用相同的简单查询语法。代码越简单、抽象程度越低，似乎 Bug 也会越少。

我们尽可能减少库的使用，必要时我们会使用简单而又经过充分测试的库，而且还要能够同时在服务器、移动端和 Web 上运行。这样一来，更新技术栈某一个部分的库就会使另一个部分受益，就像著名的 Boring Technology（https://boringtechnology.club/） 演讲提到的那样，围绕 React 和 Hapi 统一技术栈使我们能够在构建新产品的同时改进现有产品（参见下面的异花授粉）。需要理解并学习如何使用和审核的依赖关系也更少。缺点是库的更新会相互阻塞，我们需要在一项任务的单个库上投入大量的精力。

我们尽可能在产品之间共享代码。Web、移动端和服务器上的类似逻辑保存在一个共享的 Atmos 库中，技术栈的所有部分都可以访问。通过这种方式，对权限错误的单个更改或 Bug 修复就可以修复技术栈中所有需要修复的位置，很好地保持了同步。我们还可以根据需要在 Web、移动端和服务器之间转移代码和测试。

每个代码库都有很好的内部测试覆盖，因为我们的内部测试人员只需要测试很少的几个代码库。即使是不好理解的代码路径中的 Bug 也极有可能在内部被发现，原因有两个。首先，大多数团队成员每天都使用我们的产品作为他们的个人银行，所以，对于一些明显的问题，我们会在它们影响用户之前迅速发现。其次，因为大多数业务逻辑都是共享的，所以在 Web 上使用一个不好理解的功能，同时也为该功能在移动端的实现提供了基本的移动测试覆盖。例如，一个使用 iOS 支票存款的团队成员会在 Android 用户发现之前发现因重构而遭到破坏的权限。这是我们在自动化测试基础上做的工作。

我们在合并代码库时存在许多异花授粉（cross-pollination）的情况。我们将移动端代码合并到 Web 代码中，以实现业务逻辑共享。对移动组件的改进也会改善 Web 体验。类似地，我们将贷款客户端合并到原始客户端中，为的是利用它的 DevOps。除此之外，在设计新产品时，原始产品也再次获得了设计上的改进（在这种情况下，仅限 Web 的 Material-UI 被通用的 Tailwind 所代替）。原来的服务器也从新的贷款服务器的改进中受益，获得了无阻塞帐户开户功能，删除了大量的死代码。

下面我将详细介绍下我们的技术栈。

技术栈第 1 部分：纯 JavaScript iOS、Android&Web 应用

• Web、iOS 和 Android 上均使用 React。Web 端使用客户端渲染的 React，移动端使用 React Native/Expo。

• 依赖关系会定期更新和审计。

• 两个客户端项目使用一个存储库，共享逻辑、实用函数、数学运算、权限等位于共享文件夹 /common 中。

• 将 Tailwind 作为 React 和 React Native 共用的样式语言（感谢 twrnc）。

• 将 Redux 作为共享的 API 请求 / 状态逻辑库。

• 为了提供原生体验，路由无法共享：移动端使用 React Navigation，而 Web 端使用 React Router。

• 对于 Web 和移动端的每次提交，Jest 都会在 CI 时针对“关键路径”特性（如申请、登录、转账等）进行自动化集成测试。

技术栈第 2 部分：纯 JavaScript API

• Node/Hapi：单个服务器运行所有储蓄、支票、贷款、捐款代码。

• Heroku：为了尽可能减少 DevOps 耗费的时间。

• BullMQ & Redis：存款、贷款、月度作业等所有特性共用一个作业队列。

• Postgres 数据库，这里没有用到非关系型数据库的地方。

• 定期升级和审计程序包，包括 Node 版本，以便解锁新特性，确保安全性。

• 关键路径用户流（申请、登录、交易）的集成测试覆盖由 CI 强制执行。

其他：登录页和内部仪表板

• 使用 Webflow CMS 创建静态登录页。

• 重新配置仪表板，以便访问服务器作业，并检测欺诈、批准用户、批准贷款、查看增长情况等。如果有一个任务需要完成，我们就手动执行，如果是第二次遇到同样的任务，我们就为它编写一个服务器作业，如果是第三次，我们就为该服务器任务编写一个接口，这样工程部门就再也不会被这个循环阻塞了。

其他可选方案

在一个完美的世界里，我们应该使用单个代码库，由一个庞大的单体在服务器端完成所有渲染，并使用一个单人框架（one-person framework），但鉴于现代客户对 iOS、Android 和 Web 原生应用的期望，我们需要平衡效率和竞争力。

• Flutter、Flutter on Web、Dart 服务器 —— 注：1 种语言，Dart 在后端的应用尚不成熟，Flutter on Web 尚未完成，谷歌对哪个项目有承诺吗？

• Swift iOS、Kotlin Android、Django/Rails for Web & 服务器—— 注：3 种语言，但全是原生的，这会失去本文介绍的大多数好处。

• React for Web、Cordova React iOS & Android、Express 服务器 —— 注：1 种语言，移动端原生程度感觉低一些，50% 的用户把移动端作为主要平台。

• Rails for Web、iOS、Android & 服务器（Hey.com 的风格），移动应用导航本地渲染。注：1 种语言，新方法，或许已经过实战检验？我们会尽量选择上述的无聊技术 :)

小   结

总之，Atmos 的技术栈并非适合每个软件项目，但我们强烈建议小型初创公司使用。与当前可用的其他任何解决方案，它能让我们在单位时间内为客户提供更多的价值。

原文链接：https://nikodunk.com/2022-05-10-the-tech-stack-for-maximum-efficiency/