【CSDN 编者按】什么样的项目需要怎样的方案都是需要根据实时需求来决定，本文一起来看看作者与 React 的故事……
故事发生在 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 中，所以我将其标记为高风险。于是，客户终于按捺不住了，开始发脾气，指责我做出了错误的决定。接下来，我收到了一连串的质问：后来，这件事情惊动了高层。我花了大量时间来寻找证据，证明我们的决定是当初那个时间点上的最佳决定。我们开了几次反省大会，后来一切回归了平静。毕竟，项目已经做的差不多了，即将进入维护模式。
总结
我喜欢 React。论起个人项目或新创业项目，我还是会推荐 React。但是，在经历了这么多不太愉快的事情后，我不鼓励企业应用程序选择 React。参考链接：https://medium.com/better-programming/i-almost-got-fired-for-choosing-react-in-our-enterprise-app-846ea840841c程序员如何避免陷入“内卷”、选择什么技术最有前景，中国开发者现状与技术趋势究竟是什么样？快来参与「2020 中国开发者大调查」，更有丰富奖品送不停！
☞云版 Android 系统来了？
☞隐藏了十年的 Sudo 漏洞曝出：无需密码就能获取 root 权限
☞Linux 在 M1 上跑起来了
关注公众号：拾黑（shiheibook）了解更多
[广告]赞助链接：
四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/
CSDN
关注网络尖刀微信公众号
