【CSDN 编者按】什么样的项目需要怎样的方案都是需要根据实时需求来决定，本文一起来看看作者与 React 的故事……
编译 | 弯月 责编 | 张文
出品 | CSDN（ID：CSDNnews）
故事发生在 2018 年的夏天。我们接到了一个大项目，要求将某个大规模的桌面 WPF 应用程序迁移到云 Web。
在经过一番询问和探讨之后，我总结出了几个非功能性的需求：
这是一个大型的应用程序，包含 220 多个页面，其中大部分是维护页面，大约 20%是高度定制的页面。
需要显示大量的数据，尤其是以各种表格的形式：分组、列冻结、行扩展、自定义列等等。
模块化架构，可以由多个团队同时分担项目。
长期项目。新功能将随着时间的推移而不断增加。
不需要离线支持。
需要让新的团队成员快速适应工作，特别是开发桌面应用程序的.NET开发人员。
架构师的职责是提出技术方案，包括架构细节、方法、路线图和指南等，最重要的是决定我们即将采纳的技术栈。
由于客户提到他们不赞成 Angular，因此在经过多番考量以后，最终我敲定了 React 和 Redux。但是，我万万没想到，两年后我会为这个决定而后悔。
.NET 开发人员加入团队
经过概念验证后，我们决定让客户的外包团队（.NET 开发团队）加入这个项目。然而，很快客户就提出了一系列的问题：
“依赖注入在哪里？为什么我们不需要依赖注入？比如说这个 InversifyJS 就需要！”
“函数组件？不，我们不喜欢函数组件，我们想使用类组件！”
“为什么这些函数都是独立的？为什么不把它们封装在服务类中，让它们静态化？”
“API 的重试策略在哪里？我们用 PollyJS 实现一个吧。”
“为什么文件名使用了短线，而类名是驼峰式大小写？文件名应该反映类名，我建议从现在开始，文件应该命名为 SomePageComponent.tsx。”
“怎样才能在 VisualStudio 上运行代码？我不想使用 Visual Studio Code。”
很明显，他们想使用.NET 准则和设计模式编写 React 代码。这种情况很常见，开发人员很难适应新技术的工作方式。所以，我也不害怕向他们解释他们的做法不符合 React 的惯例。
通过这个问题，我也意识到 Java 或.NET 开发人员不适应 React。在这种情况下，可能 Angular 才是更好的选择，因为它们的设计模式很类似。
我们要考虑的远不止 React 本身
React 是一个没有观点的库，这意味着对于如何实现跨领域的问题，它没有任何主张。因此，如何使用 React 的责任就落到了我们团队肩上，尤其是采用哪些其他的库。当然，你肯定会使用第三方库，因为谁都不想重新发明轮子。然而，在 React 中，有很多库可供选择。
为了进行概念验证，针对应该如何处理跨领域的问题，我提出了自己的看法。接下来，我们需要与新的团队成员一起重新验证。讨论的主要问题包括：
应该使用哪个路由库？
除了 Redux 之外，异步操作还应该使用什么？Thunk？Saga？
应该使用 Axios，还是 fetch 浏览器 API？
Redux-Forms、Formiq 还是 Final-Form，哪个更好？
应该使用 styled-components、makeStyle、SASS 还是纯 CSS？
国际化库用哪个？
所以说，我们需要再花三个星期来做出这些决定。可能有人会说，挑选这些库根本不需要三个星期。
但是，在企业项目中，每一个决定，你都必须创建决策标准、考察研究、创建概念证明、验证发现、提出发现、在决策日志中记录所有过程，并保持库的更新。这需要花费大量的时间，但一点乐趣都没有。
此外，每一位开发人员都需要花时间学习所有的第三方库。我从未见过两个 React 项目具有相同依赖项、项目结构和准则。这意味着知识无法在项目之间传播，就像在 Angular 或 Vue 中一样。
我们花了三周的时间，而功能开发方面毫无进展，客户开始担心了。
React Hooks 广受好评
九个月后，我们创建了 50 多个页面。开发人员发现函数组件并不比类组件差，于是，他们开始使用函数组件。项目也不遵循原始的编码准则了。这是每一位开发人员的个人选择，我并不在意。
后来，React Hooks 发布了，而且广受好评。我们团队内出现了分歧。有些开发人员对于 ReactHooks 提出的一些观点（比如“类不仅让人类感到困惑，而且机器也不是很明白”）感到不满，还有一些开发人员则非常热衷于这种新式的编程方式。
我们使用的所有第三方库都增加了对 Hooks 的支持，似乎整个 React 世界都在朝着这个方向发展。那我们该怎么办呢？我们应该偏离最初的编程准则，并添加实现组件的第三种方法吗？似乎我们已无退路，只能将现有的页面和组件迁移到 Hooks！
我们团队赞成使用 Redux Hooks，因为我们不需要使用 Redux 的 connect()，并将界面组件与容器分开。这很合理，于是我们同意从现在开始，新建的页面和组件都使用 Hooks。但旧的页面和组件保持不变。
因此，我们中间出现了第三种处理方式，一致性不复存在了。
更糟糕的是，一些开发人员提出了一个想法：放弃 Redux，使用 useState。这意味着我们将彻底抛弃保持统一的思想。
Suspense 仍然是实验性的功能。我担心发布之后的情况。
开发速度减慢
当初持续集成刚建立起来的时候，构建大约花了三分钟，包括 npm 安装。但是，一年以后，大约需要 15 分钟。
此外，我们还必须配置 Node.js，将 RAM 扩展到 4GB，因为 2GB 不够用了。这不是什么大问题。但令人担忧的是，开发人员开始抱怨构建时间太长，在开发进行 45～60 分钟后，热重载就不能正常工作了，而且重启需要 5 分钟的时间，尤其是 Windows 用户（很显然 Node.js 在 Linux 系统上的运行速度要快得多）。有时，他们不得不完全删除 node_modules，然后重新下载依赖项，否则就无法正常工作。
当一个系统的总大小超过了 600MB，node_modules 中有 1200 多个依赖项时，你觉得情况会怎样？
对于企业应用程序，一切都要考虑成本。假设开发人员每天必须重启6次系统，他们的时薪为：每小时 40 美元，那么 6 次/天 x 5 分钟/次 x 240 天/年 x 40 美元/小时 x 8 个开发人员 = 38,400美元/年。对于企业而言，这可不是一个小数目，但是对于项目发起人来说，这是一笔不错的年终奖金，可以购买一辆全新的特斯拉 Model 3了。
Redux-Saga 慢慢走向衰落
大多数开发人员不同意我的观点，但是我认为企业的大部分业务逻辑都在 Redux 的异步操作内。大多数时候，这是唯一可以进行验证、API 调用、错误处理、触发 redux 变更或触发通知的地方。如果说这些不属于前端应用程序业务逻辑，那是什么？
我们使用了 Redux-Saga，但这是一个糟糕的决定，因为它增加了不必要的复杂性。当初要是选择 Thunk 就好了。
在企业应用程序中，你必须不时地升级并重新验证依赖关系。这是一个好习惯，因为你想要安全更新、性能改进和小幅的 API 更新，同时还希望没有重大变化。似乎 Redux-Saga 已经落伍了。上一次更新是在一年以前，GitHub 上的议题数量仍在不断增加，但没有人修复。
开发人员喜欢 React 的原因有三个：简单，灵活和生态系统。React 的团队喜欢尝试新的想法，但对于这个生态系统来说，这种做法弊大于利。他们应该勇敢承担责任。
实际上，React 大多是向后兼容的，但是 React 周围的生态系统却不是。开发人员和第三方库总是会使用最新的功能和架构模式，而旧的实验都会被淘汰。对于中小型项目而言，这应该不成问题，因为你随时可以调整。但是对于大型的长期项目来说，这些实验都具有破坏性。
最终，我决定将 React-Saga 记入技术指导委员会的风险评估结果。因为 30%的业务逻辑都在 saga 中，所以我将其标记为高风险。
于是，客户终于按捺不住了，开始发脾气，指责我做出了错误的决定。接下来，我收到了一连串的质问：
“为什么我们必须花那么多时间来升级库？”
“为什么开发速度会减慢？”
“为什么应用程序有那么多 bug，而且不稳定？”
后来，这件事情惊动了高层。我花了大量时间来寻找证据，证明我们的决定是当初那个时间点上的最佳决定。我们开了几次反省大会，后来一切回归了平静。毕竟，项目已经做的差不多了，即将进入维护模式。
总结
我喜欢 React。论起个人项目或新创业项目，我还是会推荐 React。但是，在经历了这么多不太愉快的事情后，我不鼓励企业应用程序选择 React。
参考链接：https://medium.com/better-programming/i-almost-got-fired-for-choosing-react-in-our-enterprise-app-846ea840841c
程序员如何避免陷入“内卷”、选择什么技术最有前景，中国开发者现状与技术趋势究竟是什么样？快来参与「2020 中国开发者大调查」，更有丰富奖品送不停！
来源：CSDN
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！