V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
ianva
V2EX  ›  程序员

我们需要什么样的帮助,由“前端收徒”想到的

  •  
  •   ianva ·
    ianva · 2021-05-18 16:46:05 +08:00 · 4692 次点击
    这是一个创建于 1045 天前的主题,其中的信息可能已经有所发展或是发生改变。
    看了前端收徒的帖子挺有感触的是,大多数的指导和培训都只是帮助初学者入门,但大部分的有经验的从业者也是需要一些帮助,我们经常会抱怨公司的某个 legacy 项目烂如💩山,那💩山是怎么来的?有很多朋友面对这个情况励志重构,但限于眼界和经验,重构出的结果在几次需求的变更之后又成为了变成了新的山峰。

    我接触过很多初级的开发者,他们可能都会使用库和框架,都能实现功能,但问题是他们代码可能运行不了两周就得重写,我也面试过一些前端的 leader,确实有丰富的经验,了解过从上古到现代的各种框架,如数家珍,但真让他去做一个项目,都无法完成基本的建模,数据和状态甚至都无法分辨。

    作为开发,其实大量的时间都是面对业务,新技术只是改善了开发的体验,但并没有提升项目的质量,和开发人员的素养。我们真正需要的是抽象的能力,比如 SICP 中提到的的,构造过程抽象,构造数据现象,模块化、对象和状态,元语言抽象,这是我们编程思考的基础。

    前端的开发可能是这方面确实最大的一个群体,很多人没想到过一设计好一个 view model,能够让项目的维护性稳定有多大的提升。很多人都在讨论 react hooks 如此好用,但从没考虑过如何使用它剥离业务。很多人没有数据分层的概念,以至于无法在维护的时候理清逻辑等等。

    我们如何能改善这些,我觉得我们不止是需要培训,我们需要在做具体业务的时候有人能够指导,所以 code review 应该是不错的方式。

    有想法做一个这方面的业务实践,本人做过大厂的架构,也在创业公司和外企做过 leader,还是有一些实践,但我觉得如果有经验的开发者都能去做这样的事情我们面对的💩山也回越来越少。
    48 条回复    2021-07-30 20:31:07 +08:00
    yitingbai
        1
    yitingbai  
       2021-05-18 16:47:44 +08:00
    不需要
    kop1989
        2
    kop1989  
       2021-05-18 16:50:39 +08:00
    code review 的问题在于说会暴露业务,这其实是所有人都不愿意被看到的。

    而且在你对次项目、产品没有足够了解的前提下,聊 code review 其实都是鸡同鸭讲。

    那么,会有人把自己的产品思路、业务、逻辑、代码公布给另外一个人,只求另外一个人的 code review 建议么?
    NillSpake
        3
    NillSpake  
       2021-05-18 16:51:59 +08:00
    其实现在很多规约插件,例如阿里规约等等等,个人感觉引入几个插件将插件提示的能优化的都优化了,基本上都没什么大问题,而且还能快速统一规范
    ianva
        4
    ianva  
    OP
       2021-05-18 16:53:34 +08:00
    @kop1989 只是提供一种方式,如何做应该会有很多办法,比如一个虚拟项目
    ianva
        5
    ianva  
    OP
       2021-05-18 16:54:00 +08:00
    @NillSpake 优化和规范并不能解决这些问题,知是有助于统一
    rioshikelong121
        6
    rioshikelong121  
       2021-05-18 16:54:27 +08:00
    不能暴露业务代码是个问题。 但是我觉得我们可以组织一波重构、Clean Code 之类的活动或者群。 先出一个题目,然后大家抽空实现下,然后进行交叉 review,也可以是 group 形式的 review 。

    我愿意参加这样的活动。
    ianva
        7
    ianva  
    OP
       2021-05-18 16:55:19 +08:00
    @rioshikelong121 挺好的建议,出题也是个有挑战的事情,其实具体业务是最容易的
    Mithril
        8
    Mithril  
       2021-05-18 16:56:11 +08:00   ❤️ 3
    其实无论是什么样的开发,抽象能力都是最关键的。
    如何分析需求,从中抽象出来数据模型,对结构分层抽象以隔离变化,如何设计接口从而保证测试友好。
    这些才是保证项目顺利进行下去,并且稳定可维护的关键。
    但这些恰恰又是没法在一两个小时的面试中考察到的,也难以通过几次分享,几篇文章讲明白。只能通过带着新手 Review 代码,同时给他讲明白为何要这样设计,并且让他跟自己的设计进行对比学习才能逐渐学会。
    成本实在是太高了。
    ianva
        9
    ianva  
    OP
       2021-05-18 16:57:26 +08:00
    @Mithril 是的,相比学会一个新技术,真是授人以渔
    kop1989
        10
    kop1989  
       2021-05-18 17:00:25 +08:00
    @ianva #4 这个 idea 不错,可以理解为是业务抽象界的“LeetCode”,但也很容易被抹黑为“收割廉价劳动力”😂
    ianva
        11
    ianva  
    OP
       2021-05-18 17:01:10 +08:00
    @kop1989 为啥是“收割廉价劳动力”
    wiwby
        12
    wiwby  
       2021-05-18 17:08:29 +08:00
    大量门外汉培训一下就转前端了,能有啥设计和抽象能力,哈哈哈
    ianva
        13
    ianva  
    OP
       2021-05-18 17:11:03 +08:00
    @wiwby 培训赚钱
    godbasin
        14
    godbasin  
       2021-05-18 17:17:56 +08:00   ❤️ 1
    需要发现我的宝藏博客: https://godbasin.github.io/front-end-playground/
    ----
    哈哈哈推了个广告,其实个人觉得:
    1. 入门的难题在于不知道如何下手,调试技巧、常用工具、怎么通过关键字搜索找到解决办法,等等
    2. 入门阶段过了之后,工作内容也比较简单,这时候会比较迷茫,前端内容又多又广,不知道该怎么学习、怎样提升自己,这个之前我有简单整理个视频讲了下,还是比较建议比较迷茫的小伙伴看看的: https://www.bilibili.com/video/BV1gK4y1N7Qp/
    3. 至于剩下的,更多是工作中的一些工作方式和方法、思考问题的角度和方式,这些软技能对我们工作的影响常常会被很多人忽略,但它们都是特别重要的技能

    于是乎又来了广告,推荐自己的一本新书: https://www.ituring.com.cn/book/2942

    这一大段话看起来全是自己的推广,但是其实我认为很多内容的确可以带来不少的帮助,真心希望大家可以读一下,书不贵只有 28 块钱,而且我开了 pdf 的下载,所以其实更多我是希望大家能看到其中的内容,我的愿望是以后不需要依赖专栏、书籍购买的方式,就有足够的渠道可以给大家分享更多有价值的内容~~~
    ianva
        15
    ianva  
    OP
       2021-05-18 17:28:16 +08:00
    @godbasin 满满的干货啊,支持一下
    chogath
        16
    chogath  
       2021-05-18 17:34:48 +08:00
    根据楼主的发言,可以归结为三个子前提:

    1. 合理的项目架构;
    2. 与时俱进的调整项目的复杂度;
    3. 稳定的核心团队与可落地的方法论;

    不论从哪个角度,都很难实现;所以说没有银弹。
    agdhole
        17
    agdhole  
       2021-05-18 17:48:13 +08:00
    最佳实践
    chogath
        18
    chogath  
       2021-05-18 17:54:59 +08:00
    @godbasin 你可真是个小聪明
    005008
        19
    005008  
       2021-05-18 18:06:36 +08:00
    只能在需求和场景下对应优化了
    KuroNekoFan
        20
    KuroNekoFan  
       2021-05-18 19:25:40 +08:00
    数据分层真的是好的实践吗?每当我改别人的东西发现需要 jump 好多文件我就觉得蛋疼
    no1xsyzy
        21
    no1xsyzy  
       2021-05-18 19:53:25 +08:00
    @KuroNekoFan 正确的数据分层,一次都不用 jump (动态语言和类型系统羸弱的除外
    KuroNekoFan
        22
    KuroNekoFan  
       2021-05-18 21:05:53 +08:00 via iPhone
    @no1xsyzy 我质疑数据分层可能有点笼统,不知道贴主是不是专职前端开发,但是在我看来前端开发如果从“数据”(后端意义上的数据模型)着手,有可能会比较别扭,而从交互 /功能着手,才会比较顺畅,另外我说 jump 很多的问题,具体来说是,一个状态改变,可能是在离用到这个状态的代码很远的地方开始,由一条很长的链路触发的,不过仔细想了想,这种问题也很难说跟“数据分层”有什么关联,毕竟“数据分层”也挺笼统的,另外在 react hooks 流行之后,react-redux 那套数据分层应该是不再被视做银弹了
    ianva
        23
    ianva  
    OP
       2021-05-18 21:10:23 +08:00
    多年专职前端,hooks 分层业务很好
    ianva
        24
    ianva  
    OP
       2021-05-18 21:17:03 +08:00   ❤️ 1
    @KuroNekoFan 交互也需要分层的,对前端来说交互就是业务,在交互复杂的 container,更是要把不同的交互方式拆分出来,数据层和 container 的对接也可以用 hooks 隔离出来。
    当必然交互层的分隔甚至有多种方式,比如把组件抽成无状态的组件和通过 context 拆出的纯状态操作,等等,这都可以让当前的复杂的容器交互变的更简单
    ianva
        25
    ianva  
    OP
       2021-05-18 21:23:52 +08:00
    另外 react 这样的库让数据驱动变的更自然和容易,在我们之前使用 jQuery, YUI, 的时候我们做这件事情是需要成本本经验的,即便在那个时候你不去从数据驱动的方式入手,那代码是更难以维护的,也就是说为什么前端的老项目维护起来如此困难,能够做到这些的开发太少了
    KuroNekoFan
        26
    KuroNekoFan  
       2021-05-18 21:26:07 +08:00 via iPhone
    @ianva 怎么说呢,还是名词定义问题吧,你这层回复我就觉得很对…个人认为 ui 编程本质就不是一个纯数据问题,过于强调数据就比较难搞
    ianva
        27
    ianva  
    OP
       2021-05-18 21:30:11 +08:00
    UI 在目前的本质就是数据对视图的映射,所以这就是我说的,大部分的前端欠缺建模的意识的,但不自知,因为缺少尝试,如果走 BFF,GraphQL, 可能会更容易理解
    ianva
        28
    ianva  
    OP
       2021-05-18 21:42:45 +08:00
    @ianva 想了下你的疑惑,我大概可以了解到可能存在的问题,
    “具体来说是,一个状态改变,可能是在离用到这个状态的代码很远的地方开始,由一条很长的链路触发的”
    状态为什么要和前端的 view model 有关系,当前的 view model 应该是从视图着手去描述你的业务,这是和交互无关,和状态无关的东西,这层 model 是要将后端的数据映射过来的,这层决定着项目的业务逻辑和稳定,后端接口的变化也在这一层隔离出来,所有的 container 的数据都应该基于这个模型
    charlie21
        29
    charlie21  
       2021-05-19 00:54:23 +08:00 via iPhone
    要求从数据着手时能从数据着手
    要求从功能着手时能从功能着手
    前提是把活儿推给一个对当前工程足够熟悉(建立 profile )的人 ...
    btw 前端的活儿有多少是要 “接手” 的?
    一次性消费品的气息很重的
    对于这种东西,你完全可以自己写个 service 重新组装数据阿
    把💩山堆得方方正正边界感十足就可以了,方便打包。这已经是银弹了阿
    no1xsyzy
        30
    no1xsyzy  
       2021-05-19 01:23:23 +08:00
    @KuroNekoFan 按楼主的 SICP 的话,数据分层其实就是指 bottom-up 的架构形式(相对地,从交互或者功能着手叫做 top-down )
    状态的改变不应当跨层。比如说你有一个底层的 IndexedDB API,你在这基础上搭建了一个 PouchDB,那你不再应该采用 idb 去操作这些数据。在这之上,你构造了一个(经典 demo ) to-do,你也不应当让用户去操作 PouchDB 更别说 idb 了。
    hooks 倒可以用来做数据分层(只是一般用来描述局部状态,不需要很多分层),反而 redux 似乎根本没有做数据分层,倒是把所有数据搅作一团任人随意乱窜。BTW,在软件工程领域「银弹」一词的隐喻是「这东西看上去很好,但没有(或者不能)解决实际问题」,更深地隐喻是「这个问题本身无解,所有提出的解基本上非坏即蠢」——类似那个段子:在一个没有猫的黑屋子里找一只黑猫,并大喊「我找到了」。

    话说,目前采用这种封装思维的似乎就是 Svelte
    xujinkai
        31
    xujinkai  
       2021-05-19 01:33:05 +08:00 via Android
    这个是真的难,既需要丰富的经验,也需要不断的思考。
    貌似也没什么书籍会讨论这么具体,前一阵子刚看完 unix 编程艺术,很有收获,但还是很宽泛。
    还有什么不错的书目,求楼下推荐
    ianva
        32
    ianva  
    OP
       2021-05-19 08:32:28 +08:00
    @charlie21 前端除了营销页,几乎大部分项目都是有很长的周期的,现在公司的所做的所有项目都是要长期维护的,还包括祖传几代的 AngularJS 项目
    ianva
        33
    ianva  
    OP
       2021-05-19 08:51:23 +08:00
    @xujinkai 相关书还 是很多的,unix 编程艺术其实主要关注的也是设计非常的重要,面向 Unix 命令行的工具的交互方式的探讨和设计。
    windyCity1
        34
    windyCity1  
       2021-05-19 09:13:52 +08:00
    现在公司每次提测基本都要 codeReview,我觉得提升很大,大佬手把手教优化,但是有一些深度优化没办法短时间讲清楚的就比较麻烦了。

    抽象化的学习,感觉很难。好像一直没找到什么特别好的学习途径。
    ianva
        35
    ianva  
    OP
       2021-05-19 09:18:22 +08:00
    @windyCity1 是的确实需要经验的积累,但这方面的分享其实是最匮乏的,github 虽然能够分享好代码,库,框架,但没办法分享这些设计的方法和抽象的方法
    DiamondYuan
        36
    DiamondYuan  
       2021-05-19 09:18:26 +08:00 via iPhone
    比如去给顶级前端项目提交 MR,大牛会免费帮你 CR,举几个我提交过的 vs code,Ant Design 。


    特别推荐 vs code,可以了解超大型跨端项目是如何组织代码的。
    ianva
        37
    ianva  
    OP
       2021-05-19 09:20:53 +08:00
    @DiamondYuan 能给大型的项目提交 MR 也应该有不错的能力了
    yunyuyuan
        38
    yunyuyuan  
       2021-05-19 09:27:01 +08:00
    还是得多思考
    Loserzhu
        39
    Loserzhu  
       2021-05-19 09:35:33 +08:00
    确实,深感自己抽象能力不够。😢😢
    手上的项目也蛮大的。每次开发完提 PR,reviewer 总能找到一堆问题。想试着想通过算法练习提高自己,不知道是自己太功利还是刷题太少。400 题下去,感觉提升很小。。
    JoStar
        40
    JoStar  
       2021-05-19 09:42:27 +08:00
    @Loserzhu 屎山的问题我觉得不是刷算法题能解决的。

    个人愚见:可以阅读下《代码大全》,然后 review 一下开源社区流行库的代码,不断总结。
    Loserzhu
        41
    Loserzhu  
       2021-05-19 09:49:49 +08:00
    @JoStar 谢推书。最近在看、仿写一些简单的库如 axios 、koa 这些。
    我们项目架构可以说非常好了,一直迭代,使用各种新技术。只是我太菜了而已😂
    每次 review 完,深感我是头蠢🐷,为什么想不到这么写?
    magichacker
        42
    magichacker  
       2021-05-19 10:28:40 +08:00
    想要去学习,但是都不知道该看什么样的知识提升最快。很多人还是考虑一个时间成本的问题。有些文章,有些书籍干货很少,而且从没接触过这方面内容的人初次接触,像无头苍蝇一样,最后考虑到时间成本问题,只能是放弃了
    taowen
        43
    taowen  
       2021-05-19 11:24:50 +08:00
    https://github.com/taowen/modularization-examples 我搞了一个飞书群,主题就是业务逻辑拆分
    ianva
        44
    ianva  
    OP
       2021-05-19 11:26:25 +08:00
    @taowen 你这个挺棒的
    Actrace
        45
    Actrace  
       2021-05-19 11:35:43 +08:00
    没有银弹,而且很多东西都没法教,只有实际上手项目才能明白。
    事实上,各个级别的项目都有适应的架构(屎山),在未达到顶峰之前,更高级的架构也只是累赘。

    所以很多算法出身的人其实他确实就只能去码代码,做不了架构。
    jones2000
        46
    jones2000  
       2021-05-19 13:19:46 +08:00
    首先要劝退, 不适合开发的人直接劝退,不需要浪费大家时间了。

    收徒带人, 必须要有真实的项目实战,从项目立项,需求分析,设计,构架,编写单元测试,开发,上线,升级 ,重构 ....... 整一个流程。 脱离整个流程,单独讲一个点是没有意义的。一般都带 1-2 年。
    archxm
        47
    archxm  
       2021-05-19 17:46:27 +08:00
    盒饭需要吗?炒饭、炒面、烤串。。。需要吗?
    YuanJiwei
        48
    YuanJiwei  
       2021-07-30 20:31:07 +08:00
    和楼主有同样想法的朋友,可以联系我。我们一起尝试建立这样的机制。这是我初步尝试 https://github.com/xueyushu/programmer,先建立一个程序员交流的平台, 可能现在做的还比较 low,会继续努力的。 @ianva @Mithril @xujinkai @windyCity1 @JoStar @DiamondYuan @rioshikelong121 有兴趣交个朋友吗?个人微信 base64:(eXVhbnNkdQ==) 如果冒昧打扰了,望见谅。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2719 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 77ms · UTC 15:41 · PVG 23:41 · LAX 08:41 · JFK 11:41
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.