本文最初发布于 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/

投票统计

是否原创:0 %

0 % Complete (success)

是否有价值:0 %

0% Complete

是否有素质:0 %

0% Complete (warning)

是否合法:0 %

0% Complete

   群组工具

   外部链接