三层软件架构导致程序员负担翻倍？

【CSDN 编者按】本文作者从工程师、技术领导者和开发人员角度，在发现自己身陷应用程序“管道”复杂性的困境之中，如何巧妙解决困境！

原文链接：https://yrashk.medium.com/repeating-yourself-thrice-doesnt-turn-you-into-a-3x-developer-a778495229c0

作者 | Yurii Rashkovskii译者| 弯月

责编 | 夏萌

出品 | CSDN（ID：CSDNnews）

3是一个神奇的数字。我们可在脑海中集中精力思考的事情不能超过3个。因此，从逻辑上讲，三层软件架构（数据库、后端和前端）是一个很好的模型。

既然如此，为什么构建一个功能需要花费这么多时间呢？

作为工程师、技术领导者和开发人员，我们经常发现自己身陷应用程序“管道”复杂性的困境之中。

三层模型给开发人员带来了一系列耗时的琐事。三层之间无数字节被打乱、重复定义三遍数据结构，我们苦苦挣扎于解决不同代码库之间的同步，同时还要努力优化性能、管理数据库模式变化，并保持数据的一致性。

因此，我们十分渴望能拥有更多的时间来创新，并为用户构建酷炫的新功能。

我们忘记了即使在清晰的三层架构中，需要考虑的事情也不止三个。作为一个单独的开发者小团队，我们必须留出一部分空间思考非技术问题，例如用户、他们的需求和沟通。即使在技术领域，三层架构中每一层之间的完全分离也迫使我们必须考虑另外两件事：相邻层之间的通信和同步。

三层架构以及每一层的集成让我们疲于忙碌。假设你有一个小型博客应用程序，你想为每篇博客文章添加一个“类别”。听起来是一件很简单的事情。但是，如果遵循现代 Web 开发的所有良好实践，则需要完成下列所有操作：

• 编写一个数据库架构迁移，在数据库中创建“类别”的结构。另外，还需要编写一个“向下”迁移来删除新建的“类别”，以便能够在必要时快速回滚。
• 修改 Go 结构定义、JAVA 类或者你选用的特定于后端语言的结构定义，而且还需要保持与新旧数据库架构的兼容性。最后，再为处理这个新数据结构的函数编写后端单元测试。
• 编写新的数据库查询，并编写文档记录 API 响应的变化。
• 更新前端的 Type 类型，添加新字段，同时确保无论是否有这个新字段都可以解析后端响应。最后，再针对这段逻辑编写单元测试。
• 更新 React 组件，显示帖子的“类别”。
• 确保所有层中“类别”的数据验证保持一致。
• 编写集成测试，确保每一层的新代码都能与系统的其余部分正常工作。
• 同步数据库架构、后端和前端之间的更新推出。如果项目是多个团队协同工作，则需要通知他们何时以及如何推出此次更新。

最终，在用户看来，不过是博客文章顶部多了一小行文本。但对于开发人员来说，这是一项艰巨的任务，需要数十小时的工作才能实现。

这种低效也会影响到最终用户。在各层之间移动字节是有代价的：网络延迟、数据的序列化以及反序列化等。我们很难让用户相信加载一篇有用信息不超过几个字节的帖子实际上需要通过 3G 网络传输几十秒的时间。我们很难向用户解释为什么看似一件很简单的功能，我们却无法实现，因为会占用太多资源。

我们如何走到了这一步？

三层架构是一个巧妙的构造，凝结了寻求优化劳动分工的数字工匠的聪明才智。

三层结构的出现不是为了成为 Web 开发人员的桎梏，而是为了应对 Web 应用程序日益加剧的复杂性。人类摆脱原始社会的狩猎与采集，文明高度发展正是依托于劳动的专业化。三层模型能够让各个专业职能追求卓越。虽然这种模型可以很好地服务于拥有专业团队的大型组织，但严格应用到小企业则会适得其反。另外，同步和通信的开销，专业化与分工会导致交付周期加长，这个问题也不容忽视。你见过多少这样的团队能够快速交付成果？

如果你的工作是流水线式的，也就是说，你只需提供稳定的、可预测的输入和输出，而且时间安排是固定的，那么专业化能够大放异彩。然而，小型组织和个人开发者没有这样奢侈的环境。相反，更快地反应和适应更适合他们。也就是说，交付周期越短越好。

前进之路

值得庆幸的是，除了我们之外，还有很多人都意识到了这些挑战。新一代工具正在出现，以弥合差距，并实现快速开发应用程序的目标。

如何解决这个问题

开发人员采用了多种解决方法来缓解三层模型的问题，其中包括：

• 无代码工具：Budibase之类的工具可以大幅缩短开发时间，帮助半技术人员快速构建完整的应用程序。但这类工具缺乏灵活性，而且很难维护，因此往往会限制应用程序长期发展。如果你希望应用程序能够不断成长和发展而不必重写，那么就不可以使用无代码工具编写应用程序。也无法借助现代版本管理软件，向同事发送电子邮件警告他们不要碰这段代码，感觉像回到了中世纪。此外，无代码工具大多无法脱离平台。
• 后端即服务（BaaS）：Firebase 等服务提供了预制的、通用后端，消除了大量后端和数据库的重复工作，并大大加快了应用程序的开发速度。然而，这些服务会束缚用户，很难在本地开发，而且还会导致应用程序的独立性降低，托管、部署和维护的成本升高。许多 BaaS 最终都被放弃或者被收购，导致每个人不得不紧急重写代码。最后，即便提供商不出问题，你仍然需要处理前端和 BaaS 之间的同步。
• Database-over-HTTP Web 服务器：PostgREST 和 Hasura GraphQL 等工具通过 HTTP 公开数据库。这类数据库极大地减少了开发人员需要完成的后端工作，同时仍然保持轻量级、易于部署且成本低廉。但它们只解决了一部分问题。它们的目标并不是成为构建应用程序的标准方法，而且你还要花时间同步前端代码和数据库结构。此外，除了以 JSON 的形式原样表示未处理的数据库内容之外，你无法执行更多操作来响应 Web 请求。

上述所有解决方案都是朝着正确方向迈出的一步，但我们仍然不满意快速开发应用程序工具的现状。我们相信，在不久的将来，构建一个可投入生产的应用程序所需工作量将比现在少十倍。我们不只是默默等待新工具的到来，而是正在编写这些工具，努力将这一愿景变为现实。虽然我们还没有找到方法来消除三重工作，但如今我们的项目从一个想法到可运行的 Web 应用程序所需的时间已大幅削减，而且无需牺牲协作开发的便利性和部署的速度。

• 例如，Ophir 正在开发 SQLPage，这是一个基于 SQL 的快速应用程序开发框架，能够让构建图形 Web 应用程序像编写数据库查询一样简单。SQLPage 提供了一个不依赖于数据库的解决方案，没有任何依赖性。以 SQL 为基础，只需一天即可构建完整的 Web 应用程序。
• 与之类似，Yurii 正在开发 Omnigres：这是一款大型应用程序设计的工具，可简化直接在 Postgres 数据库内运行复杂后端逻辑的开发。它将 Postgres 转变为一个完整的后端应用程序平台。

避免下一个项目承担三重工作

三层模型有其缺点，特别是对于独立开发人员和小型团队来说，它会导致开发人员在重复性的任务上花费过多时间，影响应用程序的性能和开发速度。