V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
luffy
V2EX  ›  职场话题

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

  •  1
     
  •   luffy · 120 天前 · 3561 次点击
    这是一个创建于 120 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

    50 条回复    2022-01-28 15:10:03 +08:00
    shisang
        1
    shisang  
       120 天前
    第一条无法忍受,其他都可以自己改。一个几千行代码的组件你要把代码看清楚都费劲
    Ritr
        2
    Ritr  
       120 天前
    这 5 条都很难搞啊,关键是第一条太难搞了
    Twinkle
        3
    Twinkle  
       120 天前
    哎,现在接手项目的代码全中,连缩进都不是统一的,命令行上百个 warning 。
    relaxgo
        4
    relaxgo  
       120 天前
    哎,现在接手项目的代码全中,连缩进都不是统一的,命令行上百个 warning 。
    liyang5945
        5
    liyang5945  
       120 天前
    我前同事之前离职跑路,给我留下一个一万多行的组件,这几条全中,只不过是 vue 的,到现在我都没搞清楚完整的逻辑,碰到 bug 只能慢慢找
    huai
        6
    huai  
       120 天前
    在类组件的方法里,转发 this (.call .apply)
    nito
        7
    nito  
       120 天前   ❤️ 5
    ref 滥用,父组件调用子组件函数,数据流混乱,违背单向数据流的思想。
    wanguorui123
        8
    wanguorui123  
       120 天前
    XML 里一堆业务逻辑无法调试
    meteor957
        9
    meteor957  
       120 天前
    @nito 看场景吧,不想违背单向数据流的话,很多时候状态要提升到父组件。容易造成性能问题,并且也造成父组件 state 庞大。
    meteor957
        10
    meteor957  
       120 天前
    以前碰到过 所有组件的状态(包括 visible 显隐这种)全部放在 redux 中,然后一层一层往下传,props 对象滚到几百行,及其痛苦。
    ColdBird
        11
    ColdBird  
       120 天前
    @Twinkle VsCode 有全文件执行格式化的插件
    murmur
        12
    murmur  
       120 天前
    我觉得我们写的就差不多,没用 redux ,都是 event
    ColdBird
        13
    ColdBird  
       120 天前
    @meteor957 目前的项目也有一部分是这样的,所有状态都在最顶层,一层一层传一下去,维护起来真是头痛
    1sm23
        14
    1sm23  
       120 天前
    @nito #7 那父组件想调子组件方法怎么办
    cenx
        15
    cenx  
       120 天前
    大概是这样?

    ```
    <Vue
    data={{ nums: [1, 2, 3] }}
    template={`
    <div v-for="num in nums">
    {{num}}
    </div>
    `}
    />
    ```
    DOLLOR
        16
    DOLLOR  
       120 天前
    增、改、查,三个页面代码不复用,每次维护工作量 x3 。
    Bojackk
        17
    Bojackk  
       120 天前
    react ,文件后缀 js ,一个页面 5k-8k 行,一个 Modal 写了两遍,初始化一个,更新一个。
    目前的屎山,完全力不从心。
    einq7
        18
    einq7  
       120 天前
    @1sm23 #14 同问,我知道一种办法。函数组件可以通过 useImperativeHandle 让你在使用 ref 时自定义暴露给父组件的方法。不过这个实践好像不符合 react 哲学
    Leviathann
        19
    Leviathann  
       120 天前
    @1sm23 把下面的组件状态提升到上面,再把修改状态的方法传给下面调用
    gaoryrt
        20
    gaoryrt  
       120 天前
    有了 react 还用 jq
    devwolf
        21
    devwolf  
       120 天前
    虽然记不清了,但至少包括“我以前写的代码”
    dongdongdong
        22
    dongdongdong  
       120 天前
    我正在写要一个比较烂的,这个项目经过 4-5 个人的手,我也就凑合写了,写的难受的一批
    yuthelloworld
        23
    yuthelloworld  
       120 天前
    TS 能避免一些问题
    ddch1997
        24
    ddch1997  
       120 天前
    通过 props 传递 this
    jin5354
        25
    jin5354  
       120 天前
    别怕,大厂每日亿级曝光年入几十亿的业务线代码也全都是报错,没人敢动,每次跑起来都要🙏🏻
    Twinkle
        26
    Twinkle  
       120 天前
    @ColdBird 我来的第一天就提交了用 prettier 格式化的修改,code review 的时候领导说先不用格式化,本着以前能跑就不要动的想法,摊手>.< 不是不想,只是无能为力
    EridanusSora
        27
    EridanusSora  
       120 天前
    useEffect 里一堆 document.querySelector 操作 DOM 的见过没
    learnshare
        28
    learnshare  
       120 天前
    表面上是个 React 页面,实际上是几千行 jQuery
    DOM 操作谁也讲不清楚,反正总有一个能跑
    xff1874
        29
    xff1874  
       120 天前
    @EridanusSora 这种用法就是不熟悉 react 的思想,
    daliusu
        30
    daliusu  
       120 天前
    我觉得 react 反倒是出的几千行的那种比较少,vue 倒是非常常见这种,react 有个毛病是有些人为了拆分故意给所有东西都拆的乱七八糟,然后会看到一堆各种传参各种写法的组件和函数混在一起,点来点去一会就给自己绕晕了
    daliusu
        31
    daliusu  
       120 天前
    另外就是,这种东西如果有 ts ,并且严格写规则,还是可以搞一搞的,没有 ts 是真的动都不敢动,绕来绕去的往往比一个组件几千行更容易踩坑了
    anguiao
        32
    anguiao  
       120 天前
    @daliusu
    如果拆分出的组件不能复用、也不能显著提升可读性的话,个人认为没有必要拆。
    完成同一个功能的代码逻辑,就应该写在一起。如果只为了降低单个组件的行数而去拆分,我感觉没有意义。
    einq7
        33
    einq7  
       120 天前
    @anguiao #32 隐藏实现,只专注于当前组件的逻辑,降低浏览代码时的心智负担?
    7gugu
        34
    7gugu  
       120 天前
    已经在工作室某个轮子上看到了符合一二点的代码了😂,又长又臭一动就崩,每个学期都有新的需求,为了学校免费不断网的权限凑活着写吧。
    weimo383
        35
    weimo383  
       120 天前 via Android
    @EridanusSora effect 本来就是给你 dom 操作用的吧。。。副作用
    vision1900
        36
    vision1900  
       120 天前 via Android
    @weimo383 他的意思应该是滥用副作用,react 本来是声明式编程,强行被大量的手动更新 dom 变成了命令式编程
    charlie21
        37
    charlie21  
       120 天前
    堪比遇到过的觉得比较烂的 php 代码,远古时代的没有 mvc 的 php ,模板语言+运算逻辑
    luffy
        38
    luffy  
    OP
       120 天前
    这些代码最终发展路线也许是这样的:

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

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

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

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

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

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

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

    这个故事发展路径怎么样了? 符合实际情况嘛?
    kensoz
        39
    kensoz  
       119 天前
    一个明明不需要 redux 的项目用了 redux
    一个组件一个 store ,把 jsx 当成 html ,把 redux 当 js
    一些需要共享的变量却写在了子组件中
    一些 a 组件需要用的状态却写到了 b store 中
    redux 书写风格一言难尽
    silk
        40
    silk  
       119 天前
    瞎操心 管好自己得了
    sjhhjx0122
        41
    sjhhjx0122  
       119 天前
    为了拆组件而拆组件
    一堆 hook ,恨不得每个方法都抽成 hook
    用 redux
    Rocketer
        42
    Rocketer  
       119 天前 via iPhone
    大组件令人讨厌,过度设计一样让人痛苦。

    我现在经手的一个 Angular 项目,大部分文件都只有一两行代码,多的也不超过 10 行,拆得那叫一个细。

    而且他还把很多模块发布成了库,得 npm install 才能用。

    Q:这么高大上的项目,规模应该很大吧?
    A:其实很小,我估计我一个人做也超不过半年。

    Q:那是架构师为了炫技?
    A:我也没看出来,因为这代码里完全没有注释,仅此一点就让人觉得他很不专业。
    dvsilch
        43
    dvsilch  
       119 天前
    我个人是见过写 Vue 的把一个页面分成几个所谓的「组件」然而状态全在 vuex 里维护,导致一个 store1000 多行看都没法看
    但是话说回来了如果放在 data 里东西也多得要死不好维护,所以这个问题确实有点无解,至少我不是很喜欢仅仅为了拆逻辑把代码进行抽象
    supuwoerc
        44
    supuwoerc  
       119 天前
    @Bojackk 5k 到 8k 行一个页面?这人工资给这都多了(狗头)
    hu1e
        45
    hu1e  
       119 天前
    现在的代码就是这样,只能说这种代码确实又创造了不少工作机会🤣🤣🤣
    weixiangzhe
        46
    weixiangzhe  
       119 天前
    @Twinkle 格式化完,锅就是你的了
    dany813
        47
    dany813  
       119 天前
    @Rocketer hah ,为了拆而拆,好蛋疼,深有感触
    fernandoxu
        48
    fernandoxu  
       118 天前
    我们项目是 antdpro1 搭建的,啥都升不动,class 、hooks 、jquery 混搭,舒服的一批
    Alander
        49
    Alander  
       118 天前
    effectA depends stateA => setStateB => effectB depends stateB => setStateC => effectC depends stateC => setStateD => ... => effectN depends stateN => setStateN+1

    这种链式的 useEffect 依赖是真的可怕,我就想找个函数被调用的地方都找不全
    luffy
        50
    luffy  
    OP
       116 天前
    这么多人有类似的反馈。

    看来整个市场上的开发环境很恶劣啊。

    如果有遇到开发环境比较 nice 的公司,各位一定要在这里分享。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1086 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 181ms · UTC 22:06 · PVG 06:06 · LAX 15:06 · JFK 18:06
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.