这是一个创建于 1060 天前的主题，其中的信息可能已经有所发展或是发生改变。
我自己臆想下，大概可能有几个方面
- 一个超级大的组件，几千行代码堆在一起。
- 组件有一堆参数，并且完全不知道参数代码什么意思，甚至连参数本身的命名风格都不统一。
- 完全违反了函数式编程的重要法则： 副作用太多，失控。debug 搞半天都不知道是哪个变量出的问题。
- 同样功能，同类型的逻辑到处都是，同一款轮子一遍又一遍的被制造出来。大概是为了多创造些就业机会吧？
- 无用的 div/css 太多了。 ...
这些你们有遇到过嘛？或者有别的，我没想到的？
 |
1
shisang 2022-01-24 09:40:50 +08:00
第一条无法忍受，其他都可以自己改。一个几千行代码的组件你要把代码看清楚都费劲
|
 |
2
Ritr 2022-01-24 09:48:33 +08:00
这 5 条都很难搞啊，关键是第一条太难搞了
|
 |
3
Twinkle 2022-01-24 09:52:32 +08:00
哎，现在接手项目的代码全中，连缩进都不是统一的，命令行上百个 warning 。
|
 |
4
relaxgo 2022-01-24 09:54:55 +08:00
哎，现在接手项目的代码全中，连缩进都不是统一的，命令行上百个 warning 。
|
 |
5
liyang5945 2022-01-24 09:57:25 +08:00
我前同事之前离职跑路，给我留下一个一万多行的组件，这几条全中，只不过是 vue 的，到现在我都没搞清楚完整的逻辑，碰到 bug 只能慢慢找
|
 |
6
huai 2022-01-24 10:02:34 +08:00
在类组件的方法里，转发 this （.call .apply)
|
 |
7
nito 2022-01-24 10:05:50 +08:00  5
ref 滥用，父组件调用子组件函数，数据流混乱，违背单向数据流的思想。
|
 |
8
wanguorui123 2022-01-24 10:15:11 +08:00
XML 里一堆业务逻辑无法调试
|
 |
9
meteor957 2022-01-24 10:16:30 +08:00
@nito 看场景吧，不想违背单向数据流的话，很多时候状态要提升到父组件。容易造成性能问题，并且也造成父组件 state 庞大。
|
|
10
meteor957 2022-01-24 10:21:04 +08:00
以前碰到过 所有组件的状态(包括 visible 显隐这种)全部放在 redux 中，然后一层一层往下传，props 对象滚到几百行，及其痛苦。
|
 |
12
murmur 2022-01-24 10:29:40 +08:00
我觉得我们写的就差不多，没用 redux ，都是 event
|
 |
15
cenx 2022-01-24 10:38:55 +08:00
大概是这样？
``` <Vue data={{ nums: [1, 2, 3] }} template={` <div v-for="num in nums"> {{num}} </div> `} /> ``` |
 |
16
DOLLOR 2022-01-24 10:40:14 +08:00
增、改、查，三个页面代码不复用，每次维护工作量 x3 。
|
 |
17
Bojackk 2022-01-24 10:47:15 +08:00
react ，文件后缀 js ，一个页面 5k-8k 行，一个 Modal 写了两遍，初始化一个，更新一个。
目前的屎山，完全力不从心。 |
 |
18
einq7 2022-01-24 10:57:36 +08:00
@1sm23 #14 同问，我知道一种办法。函数组件可以通过 useImperativeHandle 让你在使用 ref 时自定义暴露给父组件的方法。不过这个实践好像不符合 react 哲学
|
 |
19
Leviathann 2022-01-24 11:20:12 +08:00
@1sm23 把下面的组件状态提升到上面，再把修改状态的方法传给下面调用
|
 |
20
gaoryrt 2022-01-24 13:24:53 +08:00
有了 react 还用 jq
|
 |
21
devwolf 2022-01-24 13:27:44 +08:00
虽然记不清了，但至少包括“我以前写的代码”
|
 |
22
dongdongdong 2022-01-24 14:07:57 +08:00
我正在写要一个比较烂的，这个项目经过 4-5 个人的手，我也就凑合写了，写的难受的一批
|
 |
23
yuthelloworld 2022-01-24 14:13:39 +08:00
TS 能避免一些问题
|
 |
24
ddch1997 2022-01-24 15:00:01 +08:00
通过 props 传递 this
|
 |
25
jin5354 2022-01-24 16:26:43 +08:00
别怕，大厂每日亿级曝光年入几十亿的业务线代码也全都是报错，没人敢动，每次跑起来都要🙏🏻
|
|
26
Twinkle 2022-01-24 16:49:58 +08:00
@ColdBird 我来的第一天就提交了用 prettier 格式化的修改，code review 的时候领导说先不用格式化，本着以前能跑就不要动的想法，摊手>.< 不是不想，只是无能为力
|
 |
27
EridanusSora 2022-01-24 16:51:29 +08:00
useEffect 里一堆 document.querySelector 操作 DOM 的见过没
|
 |
28
learnshare 2022-01-24 16:57:48 +08:00
表面上是个 React 页面，实际上是几千行 jQuery
DOM 操作谁也讲不清楚，反正总有一个能跑 |
 |
29
xff1874 2022-01-24 17:10:11 +08:00
@EridanusSora 这种用法就是不熟悉 react 的思想，
|
 |
30
daliusu 2022-01-24 17:18:52 +08:00
我觉得 react 反倒是出的几千行的那种比较少，vue 倒是非常常见这种，react 有个毛病是有些人为了拆分故意给所有东西都拆的乱七八糟，然后会看到一堆各种传参各种写法的组件和函数混在一起，点来点去一会就给自己绕晕了
|
|
31
daliusu 2022-01-24 17:19:57 +08:00
另外就是，这种东西如果有 ts ，并且严格写规则，还是可以搞一搞的，没有 ts 是真的动都不敢动，绕来绕去的往往比一个组件几千行更容易踩坑了
|
 |
32
anguiao 2022-01-24 17:28:17 +08:00
|
 |
34
7gugu 2022-01-24 20:08:18 +08:00
已经在工作室某个轮子上看到了符合一二点的代码了😂，又长又臭一动就崩，每个学期都有新的需求，为了学校免费不断网的权限凑活着写吧。
|
 |
35
weimo383 2022-01-24 20:19:44 +08:00 via Android
@EridanusSora effect 本来就是给你 dom 操作用的吧。。。副作用
|
 |
36
vision1900 2022-01-24 20:30:38 +08:00 via Android
@weimo383 他的意思应该是滥用副作用，react 本来是声明式编程，强行被大量的手动更新 dom 变成了命令式编程
|
 |
37
charlie21 2022-01-24 20:51:42 +08:00
堪比遇到过的觉得比较烂的 php 代码，远古时代的没有 mvc 的 php ，模板语言+运算逻辑
|
 |
38
luffy OP 这些代码最终发展路线也许是这样的:
某个老板有一天觉得自己都准备好了，就差一个码农团队了。开始大张旗鼓从人才市场或者自己的人脉中招人。 他们甚至有的自身就是码了很多年的老码农。 这些老板一开始都非常的小心，非常的谨慎的招人, 非 985/211 不可，不是大厂出来的也不考虑。 他们觉得这样至少过滤掉了不适合的人了。 接下来，他们终于如愿以偿的招到自己认为是 top 水准的技术主管或项目经理。 但他们没想到的，这些招来的主管其实可能只是个履历好看一点的半吊子架构师。 而且这些架构师，技术主管一开始也是信心满满，打算搞一套优雅的软件。 但他们始终高估了自己。随着业务的进行，·破窗理论· 无可避免的发生了。 老板说，这个要赶快上线啊，技术主管也慌了，来不及了，心里想，算了，先上线吧，这个代码能工作就行了。 有一就有二，有二就有三，这样的事接连不断的发生着，恶性循环开始了。 终于有一天，团队里这些搬砖的陆陆续续的有人走了。 新来的人看到前人留下的代码是这样的， 心里想着，之前的人这样，我也这样好了。 然后一个跳不出去的怪圈就开始了。 故事至此结束了嘛？ 没有，有一天老板觉得有必要招个更厉害的专家来解决各种疑难杂证。 然后就花大价钱，开出比天还高的招聘要求。 这时，真正的架构师都会意识到这绝非一个人力所能及，都放弃了。 最后，老板只能招来另一个半吊子的专家，继续把这个坑挖得更深一些。 到了最后的最后，软件实在是改不下去了。但也有可能是公司先倒了，或者项目先挂了。 这个故事发展路径怎么样了？ 符合实际情况嘛？ |
 |
39
kensoz 2022-01-25 08:01:51 +08:00
一个明明不需要 redux 的项目用了 redux
一个组件一个 store ，把 jsx 当成 html ，把 redux 当 js 一些需要共享的变量却写在了子组件中 一些 a 组件需要用的状态却写到了 b store 中 redux 书写风格一言难尽 |
 |
40
silk 2022-01-25 08:56:29 +08:00
瞎操心 管好自己得了
|
 |
41
sjhhjx0122 2022-01-25 08:56:47 +08:00
为了拆组件而拆组件
一堆 hook ，恨不得每个方法都抽成 hook 用 redux |
 |
42
Rocketer 2022-01-25 09:07:40 +08:00 via iPhone
大组件令人讨厌，过度设计一样让人痛苦。
我现在经手的一个 Angular 项目，大部分文件都只有一两行代码，多的也不超过 10 行，拆得那叫一个细。 而且他还把很多模块发布成了库，得 npm install 才能用。 Q：这么高大上的项目，规模应该很大吧？ Ａ：其实很小，我估计我一个人做也超不过半年。 Q：那是架构师为了炫技？ Ａ：我也没看出来，因为这代码里完全没有注释，仅此一点就让人觉得他很不专业。 |
 |
43
dvsilch 2022-01-25 09:36:33 +08:00
我个人是见过写 Vue 的把一个页面分成几个所谓的「组件」然而状态全在 vuex 里维护，导致一个 store1000 多行看都没法看
但是话说回来了如果放在 data 里东西也多得要死不好维护，所以这个问题确实有点无解，至少我不是很喜欢仅仅为了拆逻辑把代码进行抽象 |
 |
45
hu1e 2022-01-25 11:03:15 +08:00
现在的代码就是这样，只能说这种代码确实又创造了不少工作机会🤣🤣🤣
|
 |
46
weixiangzhe 2022-01-25 11:38:22 +08:00
@Twinkle 格式化完，锅就是你的了
|
 |
48
fernandoxu 2022-01-26 09:48:34 +08:00
我们项目是 antdpro1 搭建的，啥都升不动，class 、hooks 、jquery 混搭，舒服的一批
|
 |
49
Alander 2022-01-26 17:13:07 +08:00
effectA depends stateA => setStateB => effectB depends stateB => setStateC => effectC depends stateC => setStateD => ... => effectN depends stateN => setStateN+1
这种链式的 useEffect 依赖是真的可怕，我就想找个函数被调用的地方都找不全 |
|
50
luffy OP 这么多人有类似的反馈。
看来整个市场上的开发环境很恶劣啊。 如果有遇到开发环境比较 nice 的公司，各位一定要在这里分享。 |
Select Language