你们遇到过的觉得比较烂的 react 代码大概长什么样?

2022-01-24 09:26:56 +08:00
 luffy

我自己臆想下,大概可能有几个方面

  1. 一个超级大的组件,几千行代码堆在一起。
  2. 组件有一堆参数,并且完全不知道参数代码什么意思,甚至连参数本身的命名风格都不统一。
  3. 完全违反了函数式编程的重要法则: 副作用太多,失控。debug 搞半天都不知道是哪个变量出的问题。
  4. 同样功能,同类型的逻辑到处都是,同一款轮子一遍又一遍的被制造出来。大概是为了多创造些就业机会吧?
  5. 无用的 div/css 太多了。 ...

这些你们有遇到过嘛?或者有别的,我没想到的?

5348 次点击
所在节点    职场话题
50 条回复
devwolf
2022-01-24 13:27:44 +08:00
虽然记不清了,但至少包括“我以前写的代码”
dongdongdong
2022-01-24 14:07:57 +08:00
我正在写要一个比较烂的,这个项目经过 4-5 个人的手,我也就凑合写了,写的难受的一批
yuthelloworld
2022-01-24 14:13:39 +08:00
TS 能避免一些问题
ddch1997
2022-01-24 15:00:01 +08:00
通过 props 传递 this
jin5354
2022-01-24 16:26:43 +08:00
别怕,大厂每日亿级曝光年入几十亿的业务线代码也全都是报错,没人敢动,每次跑起来都要🙏🏻
Twinkle
2022-01-24 16:49:58 +08:00
@ColdBird 我来的第一天就提交了用 prettier 格式化的修改,code review 的时候领导说先不用格式化,本着以前能跑就不要动的想法,摊手>.< 不是不想,只是无能为力
EridanusSora
2022-01-24 16:51:29 +08:00
useEffect 里一堆 document.querySelector 操作 DOM 的见过没
learnshare
2022-01-24 16:57:48 +08:00
表面上是个 React 页面,实际上是几千行 jQuery
DOM 操作谁也讲不清楚,反正总有一个能跑
xff1874
2022-01-24 17:10:11 +08:00
@EridanusSora 这种用法就是不熟悉 react 的思想,
daliusu
2022-01-24 17:18:52 +08:00
我觉得 react 反倒是出的几千行的那种比较少,vue 倒是非常常见这种,react 有个毛病是有些人为了拆分故意给所有东西都拆的乱七八糟,然后会看到一堆各种传参各种写法的组件和函数混在一起,点来点去一会就给自己绕晕了
daliusu
2022-01-24 17:19:57 +08:00
另外就是,这种东西如果有 ts ,并且严格写规则,还是可以搞一搞的,没有 ts 是真的动都不敢动,绕来绕去的往往比一个组件几千行更容易踩坑了
anguiao
2022-01-24 17:28:17 +08:00
@daliusu
如果拆分出的组件不能复用、也不能显著提升可读性的话,个人认为没有必要拆。
完成同一个功能的代码逻辑,就应该写在一起。如果只为了降低单个组件的行数而去拆分,我感觉没有意义。
einq7
2022-01-24 17:35:39 +08:00
@anguiao #32 隐藏实现,只专注于当前组件的逻辑,降低浏览代码时的心智负担?
7gugu
2022-01-24 20:08:18 +08:00
已经在工作室某个轮子上看到了符合一二点的代码了😂,又长又臭一动就崩,每个学期都有新的需求,为了学校免费不断网的权限凑活着写吧。
weimo383
2022-01-24 20:19:44 +08:00
@EridanusSora effect 本来就是给你 dom 操作用的吧。。。副作用
vision1900
2022-01-24 20:30:38 +08:00
@weimo383 他的意思应该是滥用副作用,react 本来是声明式编程,强行被大量的手动更新 dom 变成了命令式编程
charlie21
2022-01-24 20:51:42 +08:00
堪比遇到过的觉得比较烂的 php 代码,远古时代的没有 mvc 的 php ,模板语言+运算逻辑
luffy
2022-01-24 21:26:59 +08:00
这些代码最终发展路线也许是这样的:

某个老板有一天觉得自己都准备好了,就差一个码农团队了。开始大张旗鼓从人才市场或者自己的人脉中招人。
他们甚至有的自身就是码了很多年的老码农。
这些老板一开始都非常的小心,非常的谨慎的招人, 非 985/211 不可,不是大厂出来的也不考虑。
他们觉得这样至少过滤掉了不适合的人了。

接下来,他们终于如愿以偿的招到自己认为是 top 水准的技术主管或项目经理。
但他们没想到的,这些招来的主管其实可能只是个履历好看一点的半吊子架构师。

而且这些架构师,技术主管一开始也是信心满满,打算搞一套优雅的软件。
但他们始终高估了自己。随着业务的进行,·破窗理论· 无可避免的发生了。
老板说,这个要赶快上线啊,技术主管也慌了,来不及了,心里想,算了,先上线吧,这个代码能工作就行了。

有一就有二,有二就有三,这样的事接连不断的发生着,恶性循环开始了。
终于有一天,团队里这些搬砖的陆陆续续的有人走了。

新来的人看到前人留下的代码是这样的,
心里想着,之前的人这样,我也这样好了。
然后一个跳不出去的怪圈就开始了。

故事至此结束了嘛? 没有,有一天老板觉得有必要招个更厉害的专家来解决各种疑难杂证。
然后就花大价钱,开出比天还高的招聘要求。
这时,真正的架构师都会意识到这绝非一个人力所能及,都放弃了。
最后,老板只能招来另一个半吊子的专家,继续把这个坑挖得更深一些。

到了最后的最后,软件实在是改不下去了。但也有可能是公司先倒了,或者项目先挂了。

这个故事发展路径怎么样了? 符合实际情况嘛?
kensoz
2022-01-25 08:01:51 +08:00
一个明明不需要 redux 的项目用了 redux
一个组件一个 store ,把 jsx 当成 html ,把 redux 当 js
一些需要共享的变量却写在了子组件中
一些 a 组件需要用的状态却写到了 b store 中
redux 书写风格一言难尽
silk
2022-01-25 08:56:29 +08:00
瞎操心 管好自己得了

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/830183

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX