因为在企业软件中采用了React,我差点被公司开除

百家 作者:CSDN 2021-02-01 09:18:32

【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 中国开发者大调查」,更有丰富奖品送不停!


小米实现隔空充电技术;程序员离职小技巧;GitLab 涨价|开发者周刊

云版 Android 系统来了?

隐藏了十年的 Sudo 漏洞曝出:无需密码就能获取 root 权限

Linux 在 M1 上跑起来了

关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

公众号 关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接