今天是2018年的夏天。我的老板Adrian让我通过Skype与一家加拿大大公司的CTOJames通话。在相互了解的过程中，我发现詹姆斯是一个有远大抱负的聪明人。他的愿景是将大型桌面WPF应用程序迁移到云中的Web。我喜欢他的友善，并且可以看出他渴望与我们合作。他在印度已有开发合作伙伴，但他们缺乏构建Web应用程序的经验。在这种情况下，阿德里安和我遵循标准方法。我们还有几个电话，然后我们开始发现阶段，我们试图了解全局并找到非功能性需求。这些是我们应该关注的要点：一个大型应用程序——超过220个页面，其中大部分是维护屏幕，其中大约20%是高度定制的。显示大量数据，尤其是在具有各种功能的网格中：分组、列冻结、行扩展、自定义列，应有尽有。允许多个团队同时处理项目的模块化架构。多年项目。随着时间的推移，将添加新功能。无需离线支持。新团队成员可以快速入门，尤其是使用遗留桌面应用程序的.NET开发人员。作为一名架构师，我的任务是创建一个技术提案，其中包含架构细节、方法论、路线图、指南，最重要的是要使用的技术栈。James多次提到他想要一种面向未来的技术，在AngularJS被弃用后，他不赞成Angular，因为它的名声不好。我已经使用Angular和React成功地实施了一些中小型项目，所以我对两者都不感兴趣。我认为任何一个都可以完成这项工作。对于这个项目，我选择了ReactwithRedux……两年后我会后悔的。我们指派了一个由三名开发人员组成的团队来进行概念验证，两个月后，它取得了成功。超灵敏的用户界面，超快的构建时间和高开发速度。大家都开心。障碍1：.NET开发人员加入团队在概念验证之后，是时候从客户的外包团队中引入开发人员了。我们还没有开始知识共享会议，CTO给我发了一封电子邮件说，“嘿Razwan。我们明天真的要和我的外包团队见面。“我们开了个会，技术负责人带着问题和解决方案来找我：“依赖注入在哪里？”“你说不需要是什么意思？”这是一个：InversifyJS！“功能组件？不不不。我们不喜欢他们。让我们使用类组件吧！”“为什么这些函数只是挂着，为什么不把它们包装在服务类中使它们成为静态的？”“API的重试策略在哪里？让我们使用PollyJS实现一个。它应该反映类名，所以从现在开始我们将其称为SomePageComponent.tsx。”而且，最让我烦恼的是：“如何使用VisualStudio而不是VisualStudioCode来运行它？”我很清楚他们想在React中使用.NET准则和设计模式。我已经看到这种情况发生过很多次——开发人员很难适应新技术的工作方式。所以我不害怕就这些不寻常的原因展开辩论React的模式。但是在这种情况下，CTO支持他的团队是正常的。他认识我只有两个月，而与团队合作多年。我不得不做出让步并同意他们的提议。我才意识到React对Java或.NET开发人员不友好。由于类似的设计模式，在这种情况下Angular将是更好的选择。障碍2：只有React是永远的React是一个无视图的库，这意味着它没有意见如何实现横切关注点。因此，你和你的团队有责任提供关于如何使用它的输入，尤其是要使用的其他库。当然，您将使用第三方库，因为您不想重新发明轮子。在React中，有很多选项可供选择。对于概念验证，我已经对如何处理大多数交叉问题有了自己的看法。现在，他们必须与新的团队成员一起重新验证。以下是讨论的基本主题列表：我应该使用哪个路由器？除了Redux，我还应该使用什么来进行异步操作？树干？Saga我们应该使用Axios还是获取浏览器API？Redux-Forms、Formiq还是Final-Form？样式化组件、makeStyle、SASS还是纯CSS？国际化图书馆？所以我们又花了三个星期做出这些决定。我能感觉到你对我尖叫，“来吧，伙计！不可能花三个星期的时间来挑选那些图书馆！”嗯...欢迎来到企业项目。有很多决定。对于每一个，您都必须创建决策标准、进行研究、通过创建概念证明来验证发现、展示发现、在决策日志中记录所有内容，并使库保持最新。这花了很多时间，而且一点都不好玩。而且，我什至没有考虑每个开发人员花在学习所有这些第3方库上的时间。我从未见过两个具有相同依赖项、项目结构和指南的React项目。这意味着知识不能像在Angular或Vue中那样在项目之间传递。三周后，功能性用户故事的实施没有任何进展，CTO开始担心了。障碍3：ReactHooks流行九个月后，我们创建了50多个页面。开发人员注意到功能组件与类组件一样好，并开始使用它们。所以现在这个项目不再遵循原来的编码指南。它更像是每个开发人员的个人选择。对我来说，没关系。ReactHooks已经发布并且非常受欢迎。团队的心情很复杂。一些开发人员对类混淆人类和机器的想法表示不满，而另一些开发人员则热衷于新的编码模式。我们使用的所有第三方库都添加了对Hooks的支持，整个React世界似乎都在朝着这个方向发展。那么我们该怎么办？我们是否应该偏离最初的编码指南并添加第三种实现组件的方式？没有办法返回并将现有页面和组件迁移到Hooks！团队青睐ReduxHooks，因为不需要使用Reduxconnect()和从容器中转储组件。这是有道理的，我们同意从现在开始，新的页面和新的组件都将使用Hooks。我们会保留旧的。这就是我们最终得到三种治疗的方式。没有更多的一致性。更糟糕的是，一些开发人员开始萌生不再使用Redux而是使用useState的想法。这意味着我们将破坏拥有单一全球状态的想法。悬念仍然是一项实验性功能。我担心它发布时会发生什么。障碍4：开发放缓当我们进行持续集成设置时，构建大约需要三分钟，包括npm安装。但是现在，一年后，大约需要15分钟。我们还必须配置Node.js以将RAM扩展到4GB，因为2GB不够用。这不是什么大问题。令人担忧的是，开发人员开始抱怨构建时间过长，热重载在开发45-60分钟后停止工作，并且重新启动需要超过5分钟-特别是对于那些使用Windows机器的人（显然是Linux系统用户）来说，速度要快得多节点）。有时，他们不得不完全删除node_modules并再次下载依赖项，否则它将无法工作。当你在总大小为600MB的node_modules中有1200多个依赖项时，你会期待什么？对于企业应用程序，一切都与成本有关。假设开发人员必须以每小时40的价格每天重新启动六次。6次/天x5分钟x240天/年x40/小时x八名开发人员=38,400/年这对企业来说不是很多钱，但对于项目发起人来说却是一笔不错的年度奖金。毕竟，它相当于一辆全新的TeslaModel3。障碍5：Redux-Saga快死了大多数开发人员不同意我的看法，但我认为大部分业务逻辑都在Redux异步操作内部。在大多数情况下，这是唯一可以进行验证、API调用、错误处理、触发redux突变或触发通知烤面包机的地方。如果不将其视为前端应用程序的业务逻辑，这是什么？我们使用Redux-Saga，这是一个糟糕的决定，因为它增加了不必要的复杂性。Thunk足够好。在企业应用程序中，您必须不时升级和重新验证依赖项。这是一个很好的做法，因为您需要安全更新、性能改进和小的增量API更改，同时希望没有破坏性更改。看来Redux-Saga已经过时了。最后一次更新是一年多以前，没有人修复它们，GitHub问题的数量仍在增长。开发人员喜欢React有以下三个原因：简单性、灵活性和生态系统。React的团队喜欢尝试新想法，但它正在破坏生态系统！他们应该勇于承担责任！事实上，React大部分是向后兼容的，但围绕React的生态系统不是。开发人员和第三方库将始终使用最新的功能和架构模式，而旧的实验将被淘汰。对于中小型项目，这应该不是问题，因为您可以更轻松地调整它。但对于大型的多年项目，这些实验可能会破坏交易。已经是2020年9月了，我决定将React-Saga纳入技术指导委员会的风险评估结果。由于30%的业务逻辑在saga中，我将其标记为高风险。就在那时我们开始了这个项目，CTO大发雷霆，指责我做出了错误的决定。这正是火花产品经理所需要的。他以此为契机开始提出这样的问题：“为什么我们要花这么多时间升级图书馆？”“为什么开发速度变慢了？”“为什么应用程序变得有问题且不稳定？”事情升级到管理层。我花了很多时间寻找我们当时做出最佳决定的证据，而不是我想如何度过周末。经过几次复习，我们再次驶过平静的水面。毕竟，该项目已接近尾声。即将进入维护模式。结论我喜欢React。我将它用于我所有的个人项目，并想推荐它用于新的工作计划。然而，在我不愉快的经历之后，我不鼓励将其用于企业应用程序。不再。顺便说一句，我并不孤单。原文链接：https://medium.com/better-programming/i-almost-got-fired-for-choosing-react-in-our-enterprise-app-846ea840841c
