如何更改整体产品的体系结构以加快其开发速度，如何在保持工作一致性的同时将一个团队分成几个团队？ 对于我们来说，这些问题的答案是创建新的API。 在切口下，您会找到有关解决方案路径的详细故事以及所选技术的概述，但首先是一个小题外话。
几年前，我在一篇科学文章中读到，进行全面的培训需要越来越多的时间，并且在不久的将来，将需要八十年的时间来获取知识。 显然，在IT中，这个未来已经来临。
我很幸运地在那些年没有分后端和前端程序员的年代开始编程，当时没有听起来像“原型”，“产品工程师”，“ UX”和“ QA”这样的词。 世界变得更简单了，树木越来越高，树木越来越绿，空气越来越干净，孩子们在院子里玩耍，而不是停放汽车。 无论我当时想如何返回，我都必须承认，这不是超级恶棍的意图，而是社会的进化发展。 是的，社会可以有不同的发展，但是，正如您所知，历史不能容忍虚拟的情绪。
背景知识
BILLmanager只是在方向没有严格分开的时候出现。 它具有一致的体系结构，能够控制用户的行为，甚至可以使用插件进行扩展。 时间流逝，团队开发了产品，一切似乎都很好，但是开始观察到奇怪的现象。 例如，当程序员从事业务逻辑时，他开始制作格式很差的表格，使其变得不便且难以理解。 或者，看似简单的功能的添加花费了数周的时间：在架构上，模块紧密耦合，因此在更改一个模块时，必须对其进行调整。
当应用程序因未知错误而崩溃时，便利性，人机工程学和全球产品开发通常会被忘记。 如果早期程序员能够朝着不同的方向进行工作，那么随着产品的增长和对产品的要求，这变得不可能。 开发人员看到了整个图片，并了解到，如果该功能不能正确，稳定地运行，则表单，按钮，测试和升级将无济于事。 因此，他推迟了一切，坐下来纠正了不幸的错误。 他做出了他的小壮举，任何人都没有意识到（正确地交付给客户的力量已不复存在），但是该功能开始起作用。 实际上，为了使这些小壮举能够吸引客户，团队应包括负责不同领域的人员：前端和后端，测试，设计，支持，推广。
但这只是第一步。 团队发生了变化，并且产品的体系结构在技术上仍保持着密切的联系。 因此，无法以所需的速度开发应用程序；更改接口时，必须更改后端逻辑，尽管数据本身的结构通常保持不变。 所有这些都必须要做的事情。
前端和后端
要成为一个专业的人，既漫长又昂贵，因此，现代的应用程序员世界在很大程度上被分为前端和后端。
一切似乎都很清楚：我们正在招募前端程序员，他们将负责用户界面，后端最终将能够专注于业务逻辑，数据模型和其他引擎盖。 同时，后端，前端，测试人员和设计人员将留在一个团队中（因为他们生产共同的产品，所以只专注于产品的不同部分）。 组成一个团队意味着拥有一个信息空间，最好是领土空间； 一起讨论新功能并分解完成的功能； 协调一项重大任务的工作。
对于一些抽象的新项目，这已经足够了，但是我们已经编写了应用程序，并且计划的工作量和实施的时间清楚地表明，一个团队无法做到。 篮球队有5人，足球队有11人，而我们只有30人。这不适合5到9人的完美Scrum团队。 有必要分开，但是如何保持连贯性呢？ 为了行动起来，有必要解决架构和组织上的问题。
他们说：“我们将在一个项目中做所有事情，这将更加方便”。
建筑学
当产品过时时，放弃并编写新产品似乎是合乎逻辑的。 如果您可以预测时间，那么这是一个不错的决定，它将适合所有人。 但是就我们而言，即使在理想条件下，新产品的开发也将花费数年。 此外，该应用程序的特殊性使得很难在完全不同的情况下从旧版本切换到新版本。 向后兼容性对我们的客户非常重要，如果不存在，他们将拒绝升级到新版本。 在这种情况下从头开发的可行性令人怀疑。 因此，我们决定在保持最大的向后兼容性的同时升级现有产品的体系结构。
我们的应用程序是一个整体，其接口是在服务器端构建的。 前端仅实现从其接收的指令。 换句话说，后端不负责用户界面。 在架构上，前端和后端充当一个，因此，更改一个，我们被迫更改另一个。 这不是最坏的事情，更糟的是，更糟的是-如果不了解服务器上正在发生的事情，就不可能开发用户界面。
有必要将前端和后端分开，以创建单独的软件应用程序：开始开发它们的唯一方法是以所需的速度和数量。 但是，如果两个项目彼此高度依赖，该如何并行执行两个项目并更改其结构？
解决方案是附加系统- 一层 。 中间层的想法非常简单：它必须协调后端和前端的工作，并承担所有额外费用。 例如，当付款功能在后端侧分解时，该层将合并数据，而在前端侧，则无需更改； 或为了得出用户订购的所有服务的信息显示板的结论，我们不在后端执行其他功能，而是在层中聚合数据。
除此之外，该层还增加了服务器可以调用的确定性，并将最终返回该确定性。 我希望在不知道执行操作的函数的内部结构的情况下就可以进行操作请求。
通过划分职责范围来提高稳定性。
通讯技术
由于前端和后端之间的强烈依赖，因此无法并行进行工作，这减慢了团队的工作速度。 以编程方式将一个大项目分成几个项目，每个项目都有行动自由，但同时我们需要保持工作的一致性。
有人会说，通过提高软技能可以实现一致性。 是的，需要开发它们，但这不是万能药。 查看交通情况，那里的驾驶员要有礼貌，知道如何避免随机障碍，在困难的情况下互相帮助，这一点也很重要。 但是！ 没有交通规则，即使有了最好的通讯，我们在每个交叉路口都会发生事故，并有无法按时到达的风险。
我们需要很难打破的规则。 正如他们所说，使遵守变得容易而不是违反。 但是，任何法律的实施不仅带来好处，而且带来间接费用，我们确实不想放慢主要工作的步伐，让每个人都参与其中。 因此，我们创建了一个协调小组，然后创建了一个团队，其目的是为成功开发产品的不同部分创造条件。 她设置了允许不同项目作为一个整体工作的界面-遵循这些规则比打破规则更容易。
尽管新API的技术实现只是其任务的一小部分，但我们将此命令称为“ API”。 由于将通用代码段放入一个单独的函数中，因此API团队将分析产品团队的一般问题。 这是我们前端和后端之间进行连接的地方，因此该团队的成员必须了解每个方向的细节。
也许“ API”不是团队最合适的名称，关于体系结构或大规模愿景的更合适，但是，我认为，这琐碎的事情并没有改变本质。
API
服务器上的功能访问接口已经存在于我们的初始应用程序中，但对用户而言却显得很混乱。 将前端和后端分开需要更多的确定性。
新API的目标来自实施新产品和设计思想的日常困难。 我们需要：
- 系统组件的连接性较弱，因此可以并行开发后端和前端。
- 高可伸缩性，因此新的API不会干扰构建功能。
- 稳定性和一致性。
对于API解决方案的搜索并非像通常所接受的那样从后端开始，而是相反，考虑了用户的需求。
最常见的是各种REST API。 近年来，通过诸如swagger之类的工具向其添加了描述性模型，但是您需要了解这是相同的REST。 而且，实际上，它的主要正负同时是规则，这些规则仅是描述性的。 也就是说，在实现各个部分时，没有人会禁止这样的API的创建者偏离REST假设。
另一个常见的解决方案是GraphQL。 它也不是完美的，但是与REST不同，GraphQL API不仅是描述性模型，而且是真实的规则。
早些时候，我谈到了该系统，该系统应该协调前端和后端的工作。 中间层正是那个中间层。 考虑了使用服务器的可能选项后，我们选择了GraphQL作为frontend的API 。 但是，由于后端是用C ++编写的，因此GraphQL服务器的实现原来是一项艰巨的任务。 我不会描述为克服这些困难而遇到的所有困难和技巧，它并没有带来真正的结果。 我们从另一侧看问题，并决定简单是成功的关键。 因此，我们选择了经过验证的解决方案：带有Express.js和Apollo Server的独立Node.js服务器。
接下来，您必须决定如何访问后端API。 最初，我们着眼于提高REST API的方向，然后尝试使用C ++中的Node.js插件。 结果，我们意识到这一切都不适合我们，并且在对后端进行了详细分析之后，我们选择了基于gRPC服务的API 。
收集了使用C ++，TypeScript，GraphQL和gRPC的经验后，我们得到了一种应用程序体系结构，该体系结构允许灵活地开发后端和前端，同时继续创建单个软件产品。
结果是一种方案，其中前端使用GraphQL查询与中间服务器进行通信（知道要问什么以及它将得到什么回报）。 解析器中的graphQL服务器调用gRPC服务器的API函数，为此，它们使用Protobuf方案进行通信。 基于gRPC的API服务器知道从哪个微服务中获取数据或向谁发送请求。 微服务本身也建立在gRPC上，以确保查询处理，数据键入的速度以及使用各种编程语言进行开发的能力。
架构变更后的总体工作方案
这种方法有许多缺点，主要是建立和协调电路以及编写辅助功能的额外工作。 但是，如果有更多的API用户，这些费用将得到回报。
结果
我们走了开发产品和团队的进化之路。 成功或冒险变成失败，现在判断还为时过早，但可以总结出中间结果。 我们现在所拥有的：
- 前端负责显示，后端负责数据。
- 在前端，在查询和接收数据方面仍然保持灵活性。 该界面知道您可以向服务器询问什么以及应该给出什么答案。
- 后端有机会对用户界面将继续工作充满信心地更改代码。 无需重做整个前端，就可以切换到微服务架构。
- 现在，当尚未准备好后端时，您可以将模拟数据用于前端。
- 当团队不同地理解同一任务时，协作方案的创建消除了交互问题。 减少了更改数据格式的迭代次数：我们遵循“七次测量，一次切割”的原则。
- 现在，您可以并行计划冲刺工作。
- 为了实现单个微服务，您现在可以招募不熟悉C ++的开发人员。
从这一切来看，我认为有机会有意识地发展团队和项目是主要的成就。 我认为我们能够创造条件，使每个参与者可以更有目的地提高他们的能力，专注于任务而不是分散注意力。 每个人都只需要在自己的站点上工作，现在可以在高度参与且无需不断切换的情况下进行工作。 不可能在所有事情上都成为专业人士，但是现在对我们来说没有必要了 。
该文章原来是评论，而且非常笼统。 她的目标是从技术角度显示关于如何更改体系结构以继续产品开发的主题的复杂研究的路径和结果，并演示将团队分为同意的部分所面临的组织困难。
在这里，我简要地谈到了一个产品上的团队和团队合作问题，API技术的选择（REST与GraphQL），Node.js应用程序与C ++的连接等问题。以上每个主题都单独撰写了一篇文章，如果您感兴趣，那么我们将写它们。