我几乎被解雇了在我们的企业应用程序中选择反应

这是2018年夏天。我的老板阿德里安让我在一个大加拿大公司的首席技术官詹姆斯加入他的Skype呼叫。

虽然相互了解，但我发现詹姆斯是一个雄心壮志的聪明人。他的愿景是将大规模的桌面WPF应用程序迁移到云中的Web。

我喜欢他友好的态度，我可以告诉他渴望与我们合作。他已经在印度拥有一个发展伙伴，但他们缺乏建立Web应用程序的经验。

Adrian A D我遵循这种情况的标准方法。我们有几个电话，然后我们开始发现的发现阶段，我们试图掌握大局并找到非功能性要求。这些是我们应该关注的要点：

大应用程序 - 超过220页，其中大部分是维护屏幕，其中大约20％是高度定制的。

显示大量数据，尤其是在具有各种功能的网格中：分组，列冻结，行展开，自定义列，您将其命名为。

新团队成员的快速仓库，特别是对于在旧桌面应用程序上工作的.NET开发人员。

作为架构师，我的角色是创建一个技术提案，其中包含架构细节，方法，路线图，指导方针，最重要的是，将使用的技术堆栈。

詹姆斯多次提到他想要一个未来的技术，他并不赞成角度，因为它在Angularjs被贬值后它具有糟糕的声誉。

我已经成功地使用了一个角度和反应来实现了一些中小型项目，所以我并没有真正附加到其中任何一个。我觉得要么可以做这项工作。

对于这个项目，我选择与Redux的反应......我会在两年后后悔。

我们为三个开发人员分配了一个团队来努力解决概念证明，并在两个月后，这是一项成功。超级响应用户界面，燃烧 - 快速构建时间和高的发展速度。大家都开心。

在概念证明之后，现在是客户外包团队的开发人员加入的时候了。我们还没有开始知识共享会议，并将CTH发送给我一封电子邮件，“嘿，răzvan。我们真的不得不和我的外包团队明天见面。“

“依赖注入在哪里？你是什​​么意思'没有必要？'这里是一个：InversifyJS！“

“功能组件？不不不。我们不喜欢他们。让我们使用类组件！“

“为什么这些函数只是围绕，为什么他们封装在服务类内，以使它们静态？”

“API的重试策略在哪里？让我们使用pollyjs来实现一个。“

“为什么文件名dash-case当类名是pascalcase时？它应该反映类名，所以从现在开始，我们会将它们命名为somepageComponent.tsx。“

而且，最让我惹恼我的那个：“我如何使用Visual Studio且不是Visual Studio代码运行它？”

这对我来说很清楚。他们希望使用.NET指南和设计模式反应。我已经看到这一切发生了很多次 - 开发人员，他们难以适应新技术的做事方式。所以我不害怕进入辩论，了解为什么那些对反应不寻常的模式。

但在这种情况下，CTO正在支持他的团队，这是正常的。他只知道我只有两个月了，而他一直在与他的团队合作多年。我必须妥协并同意他们的提案。

我刚才意识到反应不是Java或.NET开发人员友好。由于类似的设计模式，在这种情况下，角度将是一个更好的选择。

React是一个未致力于未致病的图书馆，这意味着它没有关于如何实施跨领域问题的意见。因此，您和您的团队有责任为如何做到，特别是您要使用的其他图书馆的意见。当然，您将使用第三方库，因为您不想重新发明轮子。还有很多选择反应的一切。

对于概念证明，我已经对我们应该如何处理大部分交叉的关注点。现在他们必须与新的团队成员一起重新婚姻。这是讨论的最小主题列表：

所以我们花了三个星期制作这些决定。我可以觉得你尖叫着我，“来吧，男人！挑选这些图书馆没有3个星期！“

嗯...欢迎来到企业项目。有许多决定。对于每个人来说，您必须通过创建概念证明，当前调查结果，在决策日志中的所有内容中创建决策标准，进行研究，验证验证结果，并将库保持最新。它需要一段疯狂的时间，它甚至没有乐趣。

而且我甚至不考虑每个开发人员在学习所有第三方图书馆时花在学习所有第三方图书馆的时间。我从未见过具有相同依赖性，项目结构和指南的两项反应项目。这意味着知识无法从项目到项目转移，就像角度或Vue一样。

在执行功能用户故事的情况下，这三周后，CTO开始担心。

九个月后，我们创建了超过50页。开发人员注意到函数组件与类组件一样好并开始使用它们。因此，现在项目不再遵循原始编码指南。它更像是每个开发人员的个人选择。对我来说，没关系。

React Hooks被释放并受欢迎。球队的感情很多。一些开发人员被课程混淆了人员和机器的建议冒犯了，而其他人则热衷于新的编码模式。

我们正在使用的所有第三方库都添加了对钩子的支持，看起来整个反应世界正在进行这方面。那么我们该怎么办？我们应该偏离原始编码指南并添加第三种实施组件吗？无法返回和将现有页面和组件迁移到挂钩！

该团队赞成使用Redux挂钩，因为无需使用Redux Connect（）并将转储组件与容器分开。这是有道理的，我们同意现在开始，新页面和组件将使用钩子。我们会像他们一样离开旧的。

这就是我们如何以三种做事的方式结束。没有一致性了。

要使事情更糟糕，一些开发人员开始推动不再使用Redux但是使用的想法。这意味着我们将扰乱单一全球州的想法。

悬念仍然是一个实验特征。我担心在它被发布时会发生什么。

当我们为持续集成进行设置时，构建花了大约三分钟，包括NPM Install。但现在，一年后，它需要大约15分钟。

我们还必须配置node.js以将RAM扩展到4GB，因为2GB不再足够了。这不是一个大问题。什么是关于开发人员开始抱怨建设需要这么多时间，热重新加载在开发45-60分钟后停止工作，重启需要超过五分钟 - 特别是对于那些带Windows机器的人（显然是Linux系统Node.js的速度要快得多。有时，它们必须完全删除node_modules并再次下载依赖项，因为它根本无法正常工作。

在Node_Modules中有1,200多个依赖项时，您可以期待什么，总共大小为600MB？

对于企业应用程序，一切都是关于成本的。让我们说，开发商必须每天六次重新启动，每小时每小时40美元。六次/天x五分钟x 240天/年x $ 40 /小时x八个开发人员= 38,400美元/年。这对企业来说并不大量，但它为项目提案国提供了一个很好的年度奖金。毕竟，它等于一个全新的Tesla模型3。

大多数开发人员对我不同意，但我觉得企业逻辑的大部分都是Redux Async行动。大多数情况下，它是唯一可以执行验证，API调用，错误处理，触发Redux突变的地方，或触发通知烤面包机。如果这些不被视为前端应用程序的业务逻辑，那么是什么？

我们使用Redux-Saga，这是一个糟糕的决定，因为它增加了不必要的复杂性。干得好足够好。

在Enterprise应用程序中，您必须升级并遍历依赖于依赖项。这是一个很好的做法，因为你想要安全更新，性能改进和小增量API更改，同时希望没有破坏变化。它看起来像redux-saga被遗忘了。最后的更新是一年多的更新，GitHub问题的数量仍在增加，而无需任何人都会修复它们。

开发人员喜欢作出三个原因：简单，灵活性和生态系统。 React的团队喜欢尝试新的想法，但这杀了生态系统！他们应该勇敢，责备它！

实际上，反应大多是向后兼容的，但反应的生态系统不是。开发人员和第三方图书馆将始终使用最新的功能和架构模式，而旧实验将被留下来死亡。这不应该是小型和中型项目的问题，因为您可以更容易地适应。但对于大年的项目来说，这些实验可以是交易破坏者。

它已经是9月2020年9月，我决定在技术指导委员会的风险评估结果中包括反应 - 佐贺。

因为30％的业务逻辑在SAGAS内，我将其标记为高风险。那是当CTO失去他的脾气并指责我在开始项目时责备了差的决定。

这只是产品经理所需的火花。他用它作为开始询问问题的机会，如：

事情升级到管理层。我花了很多时间寻找证据证明我们当时做了最好的决定 - 不是我想度过我周末的方式。

几个回顾性会议后，我们再次航行了平静的水域。毕竟，该项目几乎完成了。它接近进入维护模式。

我喜欢反应。 我为所有个人项目使用它，并希望推荐新的工作计划。 但是，在我难以愉快的经验之后，我不会鼓励对企业应用程序使用它。 再也不。