React 毁了 Web 开发！-技术圈

作者 | Ivan Lučin

译者 | 弯月责编 | 欧阳姝黎

出品 | CSDN（ID：CSDNnews）

以下为译文：

React 是一个很好的库，对于Web开发很重要，因为它引入了声明式与反应式模板，这在当时是每个人都需要的范式转变。当时（也就是6～7年前），我们面临着需要的范式转变的问题，而React 很好地解决了这个问题。

另外提一句，在React之前，Ember也解决了同样的问题。然而，它的性能并不那么好，而且该框架规定了太多东西，远不如React。

然而，React在开始流行之后，发展变得一团糟。React社区中开启了一种新趋势，一切都围绕着炒作、新奇和创造新范式的转变。每隔几个月就会涌现一些新的库，为我们应该如何编写 React Web 应用程序设定新标准，同时还会解决大部分已经解决的问题。

下面，我们以“状态管理”为例来说明。由于 React 缺少传统的依赖注入系统（DI 是通过组件组合实现的），所以社区不得不自己解决这个问题。然而，后来就变成了一遍又一遍地解决这个问题，每年都会带来一套新的标准。

React 只是一个渲染引擎，在常见的Web应用程序中，你需要使用很多库来构建项目的框架，例如数据层、状态管理、路由、资产捆绑器等。

React 背后的生态系统给了你太多这样的选择，而这个技术栈也因此而变得支离破碎，并引发了著名的“Javascript 疲劳”。

此外，还涌现了一种趋势：“框架比较热潮”。各个JS框架之间经常会展开渲染速度以及内存占用等属性的比较。其实，这些因素在大多数情况下根本无关紧要，因为应用的速度缓慢并不是由于JS框架的速度过慢而引起的，而是因为糟糕的代码。

然而，就像世界上所有的趋势一样，这个趋势有点过，甚至危及了新一代的 Web 开发人员。我就在想，为什么一个库能成为Web开发人员简历中最耀眼的技术？更糟糕的是，它甚至算不上一个库，只不过是库中的一个模块。人们常常将 React hook视为一项“技术”，甚至可以与代码重构或代码审查等实际技术相提并论。

认真地说，我们什么时候才能停止吹捧这种技术？

比如说，你为什么不告诉我，你知道：

如何编写简单易读的代码

不要向我炫耀你掌握了某个GitHub上获得星星数最多的库；而是给我展示一两个优秀的代码片段。

如何管理状态

不要讨论某个流行的状态管理库，而是告诉我为什么“数据应该下降而动作应该上升”。或者说，为什么应该在创建的地方修改状态，而不是组件层次结构中更深的地方。

如何测试代码

不要告诉我你知道 Jest 或 QUnit，而是解释一下为什么很难自动化端到端的测试，以及为什么最低程度的渲染测试只需付出10%的努力，却能带来90%的好处。

如何发布代码

不要告诉我你使用 CI/CD（因为如今每个项目里的成员都不止一个人），而是解释为什么部署和发布应该分离，这样新功能就不会影响到已有功能，而且还可以远程启动新功能。

如何编写可审查的代码

不要说你是一名“团队成员”，而是告诉我代码审查对审查者来说同样困难，而且你知道如何优化PR才能提高可读性和清晰度。

如何建立稳固的项目标准

除非团队中只有你一个人，否则你就必须遵守项目中的标准和惯例。你应该告诉我命名很难，而且变量的范围越广，投入到命名中的时间就应该越多。

如何审核别人的代码

因为代码审查可确保产品质量、减少bug和技术债务、共同建立团队知识等等，但前提是将代码审核贯彻到底。代码审查不应该只是自上而下的活动。对于经验不足的团队成员来说，这是一个很好的学习机制。

如何在JS框架中找到自己的方式

这与GitHub上的星星数量无关，你应该学习如今大多数 JS 框架都拥有的共同原则。了解其他框架的优缺点可以让你更好地了解自己选择的框架。

如何建立最小化可行产品

技术只是制造产品的工具，而不是流程。与其将时间浪费在技术争论上，还不如花点时间优化流程。

如何优化：不要太早，也不要太晚

因为在大多数情况下根本不需要优化。

如何结对编程

因为结对编程与代码审查一样，这是最重要的共享知识和建立团队凝聚力的实践。而且也很有意思！

如何持续重构

因为每个项目都有技术债务，你应该停止抱怨，并开始重构。每次开发新功能之前都应该进行小型代码重构。大规模的重构和重写永远不会有好结果。

以上就是我认为 React 毁了 Web 开发的原因。很多人对这一说法很感兴趣，并热切地加入了辩论。如果你认为React 并没有那么糟糕，请在下方留言。

原文链接：https://medium.com/building-productive/react-ruined-web-development-dd65342a833f

声明：本文由CSDN翻译，转载请注明来源。

—————END—————