江苏龙网

  1. 主页 > 生活百科 > >

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

软件架构

【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 应用程序日益加剧的复杂性 。人类摆脱原始社会的狩猎与采集，文明高度发展正是依托于劳动的专业化 。三层模型能够让各个专业职能追求卓越 。虽然这种模型可以很好地服务于拥有专业团队的大型组织，但严格应用到小企业则会适得其反 。另外，同步和通信的开销，专业化与分工会导致交付周期加长，这个问题也不容忽视 。你见过多少这样的团队能够快速交付成果？
如果你的工作是流水线式的，也就是说，你只需提供稳定的、可预测的输入和输出，而且时间安排是固定的，那么专业化能够大放异彩 。然而，小型组织和个人开发者没有这样奢侈的环境 。相反，更快地反应和适应更适合他们 。也就是说，交付周期越短越好 。
前进之路
值得庆幸的是，除了我们之外，还有很多人都意识到了这些挑战 。新一代工具正在出现，以弥合差距，并实现快速开发应用程序的目标 。
【三层软件架构导致程序员负担翻倍？】


推荐阅读


上一篇：没有了

下一篇：谷歌的Project IDX会扼杀其他应用程序开发框架吗？