这是一个创建于 1608 天前的主题，其中的信息可能已经有所发展或是发生改变。
看了前端收徒的帖子挺有感触的是，大多数的指导和培训都只是帮助初学者入门，但大部分的有经验的从业者也是需要一些帮助，我们经常会抱怨公司的某个 legacy 项目烂如山，那山是怎么来的？有很多朋友面对这个情况励志重构，但限于眼界和经验，重构出的结果在几次需求的变更之后又成为了变成了新的山峰。
我接触过很多初级的开发者，他们可能都会使用库和框架，都能实现功能，但问题是他们代码可能运行不了两周就得重写，我也面试过一些前端的 leader，确实有丰富的经验，了解过从上古到现代的各种框架，如数家珍，但真让他去做一个项目，都无法完成基本的建模，数据和状态甚至都无法分辨。
作为开发，其实大量的时间都是面对业务，新技术只是改善了开发的体验，但并没有提升项目的质量，和开发人员的素养。我们真正需要的是抽象的能力，比如 SICP 中提到的的，构造过程抽象，构造数据现象，模块化、对象和状态，元语言抽象，这是我们编程思考的基础。
前端的开发可能是这方面确实最大的一个群体，很多人没想到过一设计好一个 view model，能够让项目的维护性稳定有多大的提升。很多人都在讨论 react hooks 如此好用，但从没考虑过如何使用它剥离业务。很多人没有数据分层的概念，以至于无法在维护的时候理清逻辑等等。
我们如何能改善这些，我觉得我们不止是需要培训，我们需要在做具体业务的时候有人能够指导，所以 code review 应该是不错的方式。
有想法做一个这方面的业务实践，本人做过大厂的架构，也在创业公司和外企做过 leader，还是有一些实践，但我觉得如果有经验的开发者都能去做这样的事情我们面对的山也回越来越少。
我接触过很多初级的开发者，他们可能都会使用库和框架，都能实现功能，但问题是他们代码可能运行不了两周就得重写，我也面试过一些前端的 leader，确实有丰富的经验，了解过从上古到现代的各种框架，如数家珍，但真让他去做一个项目，都无法完成基本的建模，数据和状态甚至都无法分辨。
作为开发，其实大量的时间都是面对业务，新技术只是改善了开发的体验，但并没有提升项目的质量，和开发人员的素养。我们真正需要的是抽象的能力，比如 SICP 中提到的的，构造过程抽象，构造数据现象，模块化、对象和状态，元语言抽象，这是我们编程思考的基础。
前端的开发可能是这方面确实最大的一个群体，很多人没想到过一设计好一个 view model，能够让项目的维护性稳定有多大的提升。很多人都在讨论 react hooks 如此好用，但从没考虑过如何使用它剥离业务。很多人没有数据分层的概念，以至于无法在维护的时候理清逻辑等等。
我们如何能改善这些，我觉得我们不止是需要培训，我们需要在做具体业务的时候有人能够指导，所以 code review 应该是不错的方式。
有想法做一个这方面的业务实践，本人做过大厂的架构，也在创业公司和外企做过 leader，还是有一些实践，但我觉得如果有经验的开发者都能去做这样的事情我们面对的山也回越来越少。
 | 1 yitingbai 2021-05-18 16:47:44 +08:00 不需要 |
 | 2 kop1989 2021-05-18 16:50:39 +08:00 code review 的问题在于说会暴露业务，这其实是所有人都不愿意被看到的。 而且在你对次项目、产品没有足够了解的前提下，聊 code review 其实都是鸡同鸭讲。 那么，会有人把自己的产品思路、业务、逻辑、代码公布给另外一个人，只求另外一个人的 code review 建议么？ |
 | 3 NillSpake 2021-05-18 16:51:59 +08:00 其实现在很多规约插件，例如阿里规约等等等，个人感觉引入几个插件将插件提示的能优化的都优化了，基本上都没什么大问题，而且还能快速统一规范 |
 | 6 rioshikelong121 2021-05-18 16:54:27 +08:00 不能暴露业务代码是个问题。 但是我觉得我们可以组织一波重构、Clean Code 之类的活动或者群。 先出一个题目，然后大家抽空实现下，然后进行交叉 review，也可以是 group 形式的 review 。 我愿意参加这样的活动。 |
 | 7 ianva OP @rioshikelong121 挺好的建议，出题也是个有挑战的事情，其实具体业务是最容易的 |
 | 8 Mithril 2021-05-18 16:56:11 +08:00  3 其实无论是什么样的开发，抽象能力都是最关键的。 如何分析需求，从中抽象出来数据模型，对结构分层抽象以隔离变化，如何设计接口从而保证测试友好。 这些才是保证项目顺利进行下去，并且稳定可维护的关键。 但这些恰恰又是没法在一两个小时的面试中考察到的，也难以通过几次分享，几篇文章讲明白。只能通过带着新手 Review 代码，同时给他讲明白为何要这样设计，并且让他跟自己的设计进行对比学习才能逐渐学会。 成本实在是太高了。 |
| 10 kop1989 2021-05-18 17:00:25 +08:00 @ianva #4 这个 idea 不错，可以理解为是业务抽象界的“LeetCode”，但也很容易被抹黑为“收割廉价劳动力” |
 | 12 wiwby 2021-05-18 17:08:29 +08:00 大量门外汉培训一下就转前端了，能有啥设计和抽象能力，哈哈哈 |
 | 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 的下载，所以其实更多我是希望大家能看到其中的内容，我的愿望是以后不需要依赖专栏、书籍购买的方式，就有足够的渠道可以给大家分享更多有价值的内容~~~ |
 | 16 chogath 2021-05-18 17:34:48 +08:00 根据楼主的发言，可以归结为三个子前提： 1. 合理的项目架构； 2. 与时俱进的调整项目的复杂度； 3. 稳定的核心团队与可落地的方法论； 不论从哪个角度，都很难实现；所以说没有银弹。 |
 | 17 agdhole 2021-05-18 17:48:13 +08:00 最佳实践 |
 | 19 005008 2021-05-18 18:06:36 +08:00 只能在需求和场景下对应优化了 |
 | 20 KuroNekoFan 2021-05-18 19:25:40 +08:00 数据分层真的是好的实践吗？每当我改别人的东西发现需要 jump 好多文件我就觉得蛋疼 |
 | 21 no1xsyzy 2021-05-18 19:53:25 +08:00 @KuroNekoFan 正确的数据分层，一次都不用 jump （动态语言和类型系统羸弱的除外 |
| 22 KuroNekoFan 2021-05-18 21:05:53 +08:00 via iPhone @no1xsyzy 我质疑数据分层可能有点笼统，不知道贴主是不是专职前端开发，但是在我看来前端开发如果从“数据”（后端意义上的数据模型）着手，有可能会比较别扭，而从交互 /功能着手，才会比较顺畅，另外我说 jump 很多的问题，具体来说是，一个状态改变，可能是在离用到这个状态的代码很远的地方开始，由一条很长的链路触发的，不过仔细想了想，这种问题也很难说跟“数据分层”有什么关联，毕竟“数据分层”也挺笼统的，另外在 react hooks 流行之后，react-redux 那套数据分层应该是不再被视做银弹了 |
| 23 ianva OP 多年专职前端，hooks 分层业务很好 |
| 24 ianva OP 1 @KuroNekoFan 交互也需要分层的，对前端来说交互就是业务，在交互复杂的 container，更是要把不同的交互方式拆分出来，数据层和 container 的对接也可以用 hooks 隔离出来。 当必然交互层的分隔甚至有多种方式，比如把组件抽成无状态的组件和通过 context 拆出的纯状态操作，等等，这都可以让当前的复杂的容器交互变的更简单 |
| 25 ianva OP 另外 react 这样的库让数据驱动变的更自然和容易，在我们之前使用 jQuery, YUI, 的时候我们做这件事情是需要成本本经验的，即便在那个时候你不去从数据驱动的方式入手，那代码是更难以维护的，也就是说为什么前端的老项目维护起来如此困难，能够做到这些的开发太少了 |
| 26 KuroNekoFan 2021-05-18 21:26:07 +08:00 via iPhone @ianva 怎么说呢，还是名词定义问题吧，你这层回复我就觉得很对…个人认为 ui 编程本质就不是一个纯数据问题，过于强调数据就比较难搞 |
| 27 ianva OP UI 在目前的本质就是数据对视图的映射，所以这就是我说的，大部分的前端欠缺建模的意识的，但不自知，因为缺少尝试，如果走 BFF，GraphQL, 可能会更容易理解 |
| 28 ianva OP @ianva 想了下你的疑惑，我大概可以了解到可能存在的问题， “具体来说是，一个状态改变，可能是在离用到这个状态的代码很远的地方开始，由一条很长的链路触发的” 状态为什么要和前端的 view model 有关系，当前的 view model 应该是从视图着手去描述你的业务，这是和交互无关，和状态无关的东西，这层 model 是要将后端的数据映射过来的，这层决定着项目的业务逻辑和稳定，后端接口的变化也在这一层隔离出来，所有的 container 的数据都应该基于这个模型 |
 | 29 charlie21 2021-05-19 00:54:23 +08:00 via iPhone 要求从数据着手时能从数据着手 要求从功能着手时能从功能着手 前提是把活儿推给一个对当前工程足够熟悉（建立 profile ）的人 ... btw 前端的活儿有多少是要 “接手” 的？ 一次性消费品的气息很重的 对于这种东西，你完全可以自己写个 service 重新组装数据阿 把山堆得方方正正边界感十足就可以了，方便打包。这已经是银弹了阿 |
| 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 |
 | 31 xujinkai 2021-05-19 01:33:05 +08:00 via Android 这个是真的难，既需要丰富的经验，也需要不断的思考。 貌似也没什么书籍会讨论这么具体，前一阵子刚看完 unix 编程艺术，很有收获，但还是很宽泛。 还有什么不错的书目，求楼下推荐 |
| 32 ianva OP @charlie21 前端除了营销页，几乎大部分项目都是有很长的周期的，现在公司的所做的所有项目都是要长期维护的，还包括祖传几代的 AngularJS 项目 |
| 33 ianva OP @xujinkai 相关书还 是很多的，unix 编程艺术其实主要关注的也是设计非常的重要，面向 Unix 命令行的工具的交互方式的探讨和设计。 |
 | 34 windyCity1 2021-05-19 09:13:52 +08:00 现在公司每次提测基本都要 codeReview，我觉得提升很大，大佬手把手教优化，但是有一些深度优化没办法短时间讲清楚的就比较麻烦了。 抽象化的学习，感觉很难。好像一直没找到什么特别好的学习途径。 |
| 35 ianva OP @windyCity1 是的确实需要经验的积累，但这方面的分享其实是最匮乏的，github 虽然能够分享好代码，库，框架，但没办法分享这些设计的方法和抽象的方法 |
 | 36 DiamondYuan 2021-05-19 09:18:26 +08:00 via iPhone 比如去给顶级前端项目提交 MR，大牛会免费帮你 CR，举几个我提交过的 vs code，Ant Design 。 特别推荐 vs code，可以了解超大型跨端项目是如何组织代码的。 |
| 37 ianva OP @DiamondYuan 能给大型的项目提交 MR 也应该有不错的能力了 |
 | 38 yunyuyuan 2021-05-19 09:27:01 +08:00 还是得多思考 |
 | 39 Loserzhu 2021-05-19 09:35:33 +08:00 确实，深感自己抽象能力不够。 手上的项目也蛮大的。每次开发完提 PR，reviewer 总能找到一堆问题。想试着想通过算法练习提高自己，不知道是自己太功利还是刷题太少。400 题下去，感觉提升很小。。 |
 | 40 JoStar 2021-05-19 09:42:27 +08:00 |
| 41 Loserzhu 2021-05-19 09:49:49 +08:00 @JoStar 谢推书。最近在看、仿写一些简单的库如 axios 、koa 这些。 我们项目架构可以说非常好了，一直迭，使用各种新技术。只是我太菜了而已 每次 review 完，深感我是头蠢，为什么想不到这么写？ |
 | 42 magichacker 2021-05-19 10:28:40 +08:00 想要去学习，但是都不知道该看什么样的知识提升最快。很多人还是考虑一个时间成本的问题。有些文章，有些书籍干货很少，而且从没接触过这方面内容的人初次接触，像无头苍蝇一样，最后考虑到时间成本问题，只能是放弃了 |
 | 43 taowen 2021-05-19 11:24:50 +08:00 https://github.com/taowen/modularization-examples 我搞了一个飞书群，主题就是业务逻辑拆分 |
 | 45 Actrace 2021-05-19 11:35:43 +08:00 没有银弹，而且很多东西都没法教，只有实际上手项目才能明白。 事实上，各个级别的项目都有适应的架构（屎山），在未达到顶峰之前，更高级的架构也只是累赘。 所以很多算法出身的人其实他确实就只能去码代码，做不了架构。 |
 | 46 jones2000 2021-05-19 13:19:46 +08:00 首先要劝退， 不适合开发的人直接劝退，不需要浪费大家时间了。 收徒带人， 必须要有真实的项目实战，从项目立项，需求分析，设计，构架，编写单元测试，开发，上线，升级 ，重构 ....... 整一个流程。 脱离整个流程，单独讲一个点是没有意义的。一般都带 1-2 年。 |
 | 47 archxm 2021-05-19 17:46:27 +08:00 盒饭需要吗？炒饭、炒面、烤串。。。需要吗？ |
 | 48 YuanJiwei 2021-07-30 20:31:07 +08:00 和楼主有同样想法的朋友，可以联系我。我们一起尝试建立这样的机制。这是我初步尝试 https://github.com/xueyushu/programmer，先建立一个程序员交流的平台， 可能现在做的还比较 low，会继续努力的。 @ianva @Mithril @xujinkai @windyCity1 @JoStar @DiamondYuan @ |
Select Language