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

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

无代码工具：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 转变为一个完整的后端应用程序平台。

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