我差点因为在应用程序中选择使用React而被解雇

本文转载自公众号“读芯术”(ID：AI_Discovery)。差点程序

今天是因为应用用2018年夏天。我的中选择使老板阿德里安(Adrian)请我与加拿大一家大公司的首席技术官詹姆斯(James)一起进行Skype通话。

在相互了解的而被同时，我发现詹姆斯是解雇一个有雄心壮志的聪明人。他的差点程序愿景是将大规模的桌面WPF应用程序迁移到云中的Web。

我喜欢他的因为应用用友好态度，可以说出他渴望与我们合作。中选择使他已经在印度拥有开发合作伙伴，而被但是解雇他们缺乏构建Web应用程序的经验。

我和Adrian在这种情况下遵循标准方法。差点程序我们还有几个电话，因为应用用然后我们开始发现阶段，中选择使在此阶段我们试图把握全局并找到非功能性需求。而被这些是解雇我们应重点关注的要点：

一个大型应用程序-超过220页，其中大多数是维护屏幕，其中大约20%是高度定制的云服务器。 显示大量数据，尤其是在具有各种功能的网格中：分组，列冻结，行扩展，自定义列，即可为其命名。 模块化架构，允许多个团队同时处理项目。 多年项目。新功能将随着时间的推移而增加。 不需要离线支持。 为新团队成员快速入门，特别是对使用旧桌面应用程序的.NET开发人员而言。

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

James多次提到他想要一种面向未来的技术，网站模板他不赞成Angular，因为在AngularJS被弃用之后，它的声誉很差。

我已经使用Angular和React成功地实现了一些中小型项目，因此我对其中的任何一个都没有真正的兴趣。我觉得任何一个都能胜任。

对于这个项目，我选择React with Redux…两年后我会后悔的。

我们指定了一个由三名开发人员组成的团队来进行概念验证，两个月后，它成功了。超级响应的用户界面，超快的构建时间和高开发速度。每个人都很开心。

障碍1：.NET开发人员加入团队

经过概念验证后，是时候让客户外包团队的开发人员加入了。我们还没有开始知识共享会议，CTO给我发送了一封电子邮件，说：“嘿，拉兹万。我们真的必须明天与我的外包团队见面。”

我们开会，源码库技术负责人向我提出问题和解决方案：

“依赖注入在哪里?“不需要一个是什么意思?”这是一个：InversifyJS! “功能组件?不不不。我们不喜欢他们。让我们使用类组件!” “为什么这些函数只是四处徘徊，为什么不将它们封装在服务类中以使其静态化?” “ API的重试策略在哪里?让我们使用PollyJS实现一个。” “当类名是PascalCase时，为什么文件名会变成破折号?它应反映类名，因此从现在开始，我们将其命名为SomePageComponent.tsx。” 而且，最让我烦恼的是：“如何使用Visual Studio而不是Visual Studio Code运行它?”

对我来说很清楚他们想在React中使用.NET准则和设计模式。我已经多次看到这种情况发生-开发人员很难适应新技术的工作方式。因此，我不害怕就为何这些是React的异常模式展开辩论。

但是在这种情况下，CTO支持他的团队，这很正常。在与团队合作多年的时候，他认识我只有两个月。我必须做出让步，并同意他们的建议。

我刚刚意识到React不是Java或.NET开发人员友好的。由于类似的设计模式，在这种情况下，Angular会是更好的选择。

障碍2：永远只有React

React是一个没有观点的库，这意味着它对如何实现跨领域关注没有意见。因此，您和您的团队有责任就如何使用它，尤其是要使用的其他库提出意见。当然，您将使用第三方库，因为您不想重新发明轮子。在React中，有很多选项可供选择。

对于概念验证，我已经对如何处理大多数跨领域问题有意见。现在，他们必须与新的团队成员一起重新验证。这是讨论的基本主题列表：

应该使用哪个路由器? 除了Redux，异步动作还应该使用什么?Trunk?Saga 我们应该使用Axios还是访存浏览器API? Redux-Forms，Formiq还是Final-Form? 样式组件，makeStyle，SASS还是纯CSS? 国际化库?

因此，我们又花了三个星期来做出这些决定。我可以感觉到您对我尖叫：“快点，伙计!不可能花三个星期的时间来挑选那些库!”

好吧……欢迎来到企业项目。有很多决定。对于每一项，您都必须创建决策标准，进行研究，通过创建概念证明来验证发现，提出发现，在决策日志中记录所有内容以及使库保持最新。这花费了疯狂的时间，而且甚至没有乐趣。

而且，我什至没有考虑每个开发人员花费在学习所有这些第三方库上的时间。我从未见过两个具有相同依赖项，项目结构和准则的React项目。这意味着知识无法在项目之间转移，就像在Angular或Vue中一样。

在实施功能用户故事方面未取得任何进展的三周后，CTO开始担心。

障碍3：React Hooks受欢迎

九个月后，我们创建了50多个页面。开发人员注意到功能组件与类组件一样好，并开始使用它们。因此，现在该项目不再遵循原始的编码准则。对于每个开发人员来说，这更像是个人选择。对我来说，那没关系。

React Hooks已发布并广受欢迎。球队有百感交集。有人认为类会使人和机器混淆，有些开发者对此感到不满，而另一些人则热衷于新的编码模式。

我们正在使用的所有第三方库都增加了对Hooks的支持，整个React世界似乎都朝着这个方向发展。那我们该怎么办呢?我们是否应该偏离原始的编码准则，并添加实现组件的第三种方法?无法退回并将现有页面和组件迁移到Hooks!

该团队赞成使用Redux Hooks，因为不需要使用Redux connect()并将转储组件与容器分开。这是有道理的，我们同意从现在开始，新页面和新组件将使用Hooks。我们将保留旧的。

这就是我们最终得到三种处理方式的方式。不再有一致性。

更糟的是，一些开发人员开始提出不再使用Redux而是使用useState的想法。这意味着我们将破坏拥有一个单一全球状态的想法。

悬念仍然是实验性功能。我担心它发布后会发生什么。

障碍4：开发放缓

当我们进行持续集成的设置时，构建大约花了三分钟，包括npm安装。但是现在，一年后，大约需要15分钟。

我们还必须配置Node.js以将RAM扩展到4GB，因为2GB不够了。这不是大问题。令人担忧的是，开发人员已开始抱怨构建时间太长，在45-60分钟的开发后热加载就停止工作，并且重新启动要花5分钟以上的时间-特别是对于那些使用Windows机器(显然是Linux系统的用户)对于Node.js来说要快得多)。有时，他们不得不完全删除node_modules并再次下载依赖项，因为否则它将无法正常工作。

当node_modules中有1200多个依赖项，总大小为600MB时，您会期望什么?

对于企业应用程序，一切都与成本有关。假设开发人员每天必须以每小时$ 40的速度重新启动六次。六次/天x五分钟x 240天/年x $ 40 /小时x八个开发人员= $ 38,400 /年对于企业而言，这并不是一笔大数目，但是对于项目发起人来说，这是一笔不错的年度奖金。毕竟，它等于全新的Tesla Model 3。

障碍5：Redux-Saga快死了

大多数开发人员不同意我的观点，但是我认为大部分业务逻辑都在Redux异步操作内部。在大多数情况下，它是唯一可以进行验证，API调用，错误处理，触发redux突变或触发通知烤面包机的地方。如果不将这些视为前端应用程序上的业务逻辑，那又是什么?

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

在企业应用程序中，您必须不时地升级并重新验证依赖关系。这是一个好习惯，因为您希望安全更新，性能改进和较小的增量API更改，同时希望不进行重大更改。看来Redux-Saga已落伍。上一次更新是一年多以前的，而没有任何人修复它们，GitHub问题的数量仍在增加。

开发人员喜欢React的原因有三个：简单性，灵活性和生态系统。React的团队喜欢尝试新的想法，但这正在破坏生态系统!他们应该勇敢承担责任!

实际上，React大多是向后兼容的，但是React周围的生态系统却不是。开发人员和第三方库将始终使用最新的功能和体系结构模式，而旧的实验将被淘汰。对于中小型项目，这应该不成问题，因为您可以更轻松地进行调整。但是对于大型的多年项目，这些实验可能会破坏交易。

已经是2020年9月，我决定将React-Saga纳入技术指导委员会的风险评估结果中。

因为30%的业务逻辑都在saga中，所以我将其标记为高风险。那是当我们开始项目时，首席技术官发脾气，并责怪我做出了错误的决定。

这只是产品经理需要的火花。他以此为契机开始提出如下问题：

“为什么我们必须花很多时间来升级库?” “为什么发展放缓?” “为什么应用程序变得有bug和不稳定?”

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

几次回顾会议之后，我们再次驶过平静的水面。毕竟，该项目即将完成。即将进入维护模式。

结论

我爱React。我将其用于我的所有个人项目，并希望将其推荐用于新的工作计划。但是，在经历了令人不愉快的经历之后，我将不鼓励将其用于企业应用程序。再没有。

顺便说一下，我并不孤单。

原文链接：

https://medium.com/better-programming/i-almost-got-fired-for-choosing-react-in-our-enterprise-app-846ea840841c