React 毁了 Web 开发?

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

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

c8ac5be647cb6c4dfb9d0a7c16db2a43.jpg

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

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

e1712366dec6315d60954041b26383b5.png

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

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

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

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

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

比如说,你为什么不告诉我,你知道:

如何编写简单易读的代码

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

如何管理状态

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

如何测试代码

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

如何发布代码

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

如何编写可审查的代码

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

如何建立稳固的项目标准

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

如何审核别人的代码

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

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

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

如何建立最小化可行产品

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

如何优化:不要太早,也不要太晚

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

如何结对编程

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

如何持续重构

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

添加新评论