自我介绍下,四年工作经验,头两年全栈开发,后两年专职做前端,目前已达到高级前端工程师水平,经历过三家公司。第一家公司,电商行业,做阿里 ISV
供应商,为淘宝卖家服务,也是我第一次接触百万 UV
级别的产品,在第一家公司呆了两年,由于达到技术瓶颈期,遂跳槽,第二家公司,航运物流行业,呆了六个月(工作强度对我来说,是真的高),身体不适,没有同意转正。目前这家,担任项目管理和前端组长,两个角色,目前呆了两年,做了很多东西,把自己的一些想法跟大家聊一聊。
这是一家做保险和金融行业的公司,属于传统行业的科技公司,有点外包的性质,当然,也有自己的 SaaS
产品,由于是传统行业的公司,技术栈相对互联网公司来说,稍微落后一点。我刚来的时候,上一个前端要辞职了,然后做对接工作(告诉我,有啥问题,直接搜代码),我算是接盘侠,前任留下的屎山,其他的,大概有以下几点:
其中一个归 CTO (做后端) 管,另外两个在广东,我入职的时候,也没有确认,到底要不要带人。我来的时候,就已经在了,后面我领导跟我说,要带下他们,我当时压根就没有带人的想法,也是个坑。
没有前端工程化体系,开发周期长,开发质量差,维护困难
前后端混合项目,剥离前端代码没有剥离干净,后端很多文件都在,不知道重不重要,前端代码运行在服务端,每次修改一行代码,看效果,需要拖到服务器上进行编译,编译大概 1-2 分钟左右,非常痛苦。
完全熟悉该项目的人员已离职(技术和产品),项目交接没有处理好。
业务逻辑非常混乱,没有相关的产品流程图,全凭记忆。
服务器上运行的 Node
版本非常低,到现在还是 8.x
,各种低版本的库都在,比如 Ant Design
用的 3.6.2
,在项目开发中遇到穿梭框无法进行树状显示(代码一摸一样,在高版本 3.19.2
,可以显示)。又比如还有这种 "translate.js": "git+https://github.com/MichelSimonot/translate.js.git”
尝试过升级库和卸载其他库,各种报错。
代码缺乏注释,一个文件几千行,对 React
,Redux
使用,欠缺理解。
有过一次”爆炸”,此项目如果再继续迭代下去,随时可能继续”爆炸”,现在已经是在踩雷开发阶段。
在 2019 年 10 月 18 号,24:00 发生生产事故,事故表现为,操作特定页面,浏览器崩溃,卡死。
脚本执行时间非常长,后面经查,是由以下代码引起
actions.getAgentListByPage({
companyId: currentAgent.companyId,
pageIndex: 1,
pageSize: 20000,
searchProvince: currentAgent.province,
searchCity: currentAgent.city
})
页面很多地方存在请求 pageSize:20000 的情况,该代码是由前任前端编写,具体为何写出这样的代码,原因未知,处理方案给到后端解决,前端配合加入 workbench
字段,凌晨 1 点左右得到解决。
一套项目上,运行着两套系统。
打包出来的项目代码体积有 49.5MB,页面首次加载耗时 11.4 min
基于以上的原因,向领导提出过重构,没有同意,我认为可能有两个方面的顾虑,
列举了以上的这些点,烂摊子太多了,好在有一个点,领导的支持力度还不错,看我是如何突围的。
前端技术建设的核心目的,是为了提高开发效率,保证开发质量,为保障项目高质量按时交付,同时兼顾考虑中长期研发实际情况,结合团队实际能力,为未来做技术储备,为业务发展提供更多的可能性,大概将自己的分为以下四类
首先,要对现有的问题进行梳理归纳,按照问题的优先级进行排序,然后,分阶段性目标进行实现,对于上面的问题,我大概整理了一张表格
问题 | 优先级 | 成本 | 目标 |
---|---|---|---|
如何打造前端工程化体系 | p0 | 高 | 提升整个前端团队的开发效率、按时交付、保证交付质量。 |
如何进行团队管理 | p0 | 中 | 进行人才储备,提高团队人员技术能力 |
如何进行项目管理 | p1 | 中 | 掌控全局,知道项目下的人都在做什么,资源协调 |
初来乍到,首先就是跟大家一起聊聊天,了解他 /她的想法,以及个人情况、技术能力、兴趣爱好、性格特点等。
团建聚餐,经常请大家喝奶茶 /咖啡,不定时的组织活动,通常是聚餐(个人出钱),为下面的工作,好开展。
导师帮带,新人进来后,安排一个人带着他,答复常见问题,由简单的需求再到核心模块的负责,一点一点施展压力。
新人适应,负责安排新成员的发展方向,并在新人入职的前几周,了解项目框架和开发模式,再安排其做基于现有页面的优化,帮助其了解不同人负责的业务。
责任划分,明确团队里人员定位,并使其知晓,根据成员能力不同,态度不同,安排适合其的任务。
前端周会,每周一次,组织大家开前端周会,在这个会上,过下大家目前手头上的事情,有没有遇到什么问题,需要协调的一些资源,进度把控等。
技术分享,不定时的前端技术分享,主题不限,并把相关分享后的资料,上传到前端文档管理,方便日后的人员进行查看。
主要是指代码权限控制,目的是确保代码安全,问题可控可避免可追溯
具体管理举措有以下几条:
公司仓库,代码属于公司财产,对代码进行权限隔离,启用内网 GitLab
,默认关闭所有外网访问权限,针对每个项目,按实际需要给开发赋予指定权限。
提交权限,允许开发在自己仓库下提交,但涉及到公司仓库的合并,需要发起 PR
,然后在组长进行 CR
后,才能提交到主仓库。
发布权限,对于将要发布到生产环境,权限给到组长,只允许组长进行发布。
前后端开发联调有一个严重问题,就是后端接口变动或者字段改动时,没有在事前事后通知相应前端开发,测试人员,导致效率底下,并且会出现各种异常情况。
因此,通过梳理开发流程,出接口文档,作为对接标准。
我们使用 apiDoc
来作为前后端联调标准。
但在实际情况中,还是会有一些接口文档和实际接口不符的情况发生,导致一些问题产生,这个我们也在思考。
刚入职的时候,由于上面的项目框架问题太多,之前也尝试过解决,但,解决不了,领导也意识到了这点,而且也有新项目进来,就让我重新搞一套项目框架。所以,我自研了一套基于 Webpack
的项目框架和工程化体系,做这件事的目的,就如我上面提到过的一样,提升整个前端团队的开发效率、按时交付、保证交付质量。
我们使用的是 Git Flow
分支管理策略
Git Flow
最开始是由 Vincent Driessen
发行并广受欢迎,这个模型是在 2010 年构思出来的,而现在距今已有 10 多年了,而 Git
本身才诞生不久。在过去的十年中,Git Flow
在许多软件团队中非常流行
master 分支:master 分支只有一个,名称即为 master 。GitHub 现在叫 main
develop 分支:develop 分支只有一个,名称即为 develop
feature 分支:feature/<功能名>,例如:feature/login,以便其他人可以看到你的工作
hotfix 分支:hotfix/日期,例如:hotfix/0104
master || main 分支:存储正式发布的产品,master || main
分支上的产品要求随时处于可部署状态。master || main
分支只能通过与其他分支合并来更新内容,禁止直接在 master || main
分支进行修改。
develop 分支:汇总开发者完成的工作成果,develop
分支上的产品可以是缺失功能模块的半成品,但是已有的功能模块不能是半成品。develop
分支只能通过与其他分支合并来更新内容,禁止直接在 develop
分支进行修改。
feature 分支:当要开发新功能时,从 master 分支创建一个新的 feature
分支,并在 feature
分支上进行开发。开发完成后,需要将该 feature
分支合并到 develop
分支,最后删除该 feature
分支。
release 分支:当 develop
分支上的项目准备发布时,从 develop
分支上创建一个新的 release
分支,新建的 release
分支只能进行质量测试、bug 修复、文档生成等面向发布的任务,不能再添加功能。这一系列发布任务完成后,需要将 release
分支合并到 master
分支上,并根据版本号为 master
分支添加 tag
,然后将 release
分支创建以来的修改合并回 develop
分支,最后删除 release
分支。
hotfix 分支:当 master
分支中的产品出现需要立即修复的 bug 时,从 master
分支上创建一个新的 hotfix
分支,并在 hotfix
分支上进行 BUG 修复。修复完成后,需要将 hotfix
分支合并到 master
分支和 develop
分支,并为 master
分支添加新的版本号 tag
,最后删除 hotfix
分支。
提交信息应该描述“做了什么”和“这么做的原因”,必要时还可以加上“造成的影响”,主要由 3 个部分组成:Header
、Body
和 Footer
。
Header
Header 部分只有 1 行,格式为<type>(<scope>): <subject>
。
type 用于说明提交的类型,共有 8 个候选值:
feat:新功能( feature )
fix:问题修复
docs:文档
style:调整格式(不影响代码运行)
refactor:重构
test:增加测试
chore:构建过程或辅助工具的变动
revert:撤销以前的提交
scope 用于说明提交的影响范围,内容根据具体项目而定。
subject 用于概括提交内容。
Body 省略
Footer 省略
这样做起来的好处,这个项目下:
Tag
都上线了什么内容。总之,一目了然。
在这个流程中,开发人员只对个人仓库拥有可控权,无法直接改变公司仓库代码,当需要提交到公司仓库下时,需要发起 PR
请求,经过组长 CR
后,将其代码合并到公司仓库下。
主分支代码和线上代码进行隔离,由组长将指定版本的 Tag
发布到生产环境,再通过运营人员直接从 GitLab
上拉取指定的 Tag
,然后打包发布。
通过以上流程,前端代码能保证高质量,高稳定性的状态,运行在服务器端。
要根据实际业务情况和团队规模,技术水平来做,关键是要形成一个闭环,所谓闭环就是从零开始到上线再到迭代的全链路,有很多节点,这些节点需要根据实际情况进行设计,避免过度设计。
为何不是 create-react-app
create-react-app 是基于 webpack
的打包层方案,包含 build 、dev 、lint
等,他在打包层把体验做到了极致,但是不包含路由,不是框架,也不支持配置。所以,如果大家想基于他修改部分配置,或者希望在打包层之外也做技术收敛时,就会遇到困难。
为何不是 umi
umi 提供的功能很多,这也导致它太过于臃肿。而且你还要去学它的封装化配置,而不是学原生第三方库的配置,如果你只想要一些简单的功能,追求更高的可玩性,哪 umi 不太适合。
所以,我自己定制了一套脚手架,实现了以下功能:
解决了以下的问题:
完成整个编码过程的一个闭环:
这些节点要视实际情况,以最小成本去做,然后逐步升级。比如编码规范,我们是采用业界比较著名的 Airbnb JavaScript
代码规范,搭配eslint 、pre-commit 、lint-staged 、prettier 、stylelint
去进行约束。
这套项目框架,目前开发体验非常爽,在我司多个产品线上,投入使用,并已开源,**框架地址**,演示页面比较少,大佬们觉得不错的话,可以给个 Star 🌟,也欢迎给项目提 issues ~
我们是做 ToB
业务,存在页面上大量使用表单的场景,所以,把我们的表单页面做成可配置化,实现了大部分页面表单配置化,减少前端人力资源投入。
针对公司的实际业务场景,其他子系统不会特别复杂,页面也不会多,共享一套账号体系,这里采用的思路是只有一个项目,不分主从系统,通过 Webpack
配置多页面,不同的子系统进入的首页内容不一样,加载内容不一样,菜单导航,则通过后端对每个租户进行区分,来做到租户看到的菜单系统不一样。
如果子系统特别复杂,有主从系统概念,可以考虑使用微服务设计,这里不做过多介绍。
除了业务代码以外,前端还会有一些公共静态资源,例如 React
资源,Ant Design
资源,BizCharts
资源,以及一些图片文件等。
对于这些文件,是所有项目所共享的,假如这些文件分散在各个项目里,既没必要,也容易导致不同项目依赖文件不统一。
我们是放在 S3
上,做 CDN
静态资源加速,然后前端项目通过引入url
来使用这些资源,这样可以减轻自己的服务器网络带宽消耗。
任务分配,产品把相关的需求,经过讨论,可行性分析,通过项目管理工具,放到迭代计划中,录入开发工时,测试工时。
文档管理,采用项目管理工具自带的文档,要求做到文档可以团队编辑,可以查看到编辑历史。
项目周会,过大家手上目前的迭代进度,遇到的问题,需要协调的资源,风险控制等。
项目复盘,复盘首先是要做的是事实陈述,开始诊断、分析存在差异的原因,找出导致成功或失败的根本原因后进行规律总结。明白为什么会成功、哪些关键行为起了作用,这些行为有没有适用条件,对于提高后续行动的成功率有没有价值。
所谓技术服务业务,找产品了解现有的业务流程以及痛点,甚至未来要做的一些产品规划,好的技术架构,要考虑各种各样的业务场景,怎样才能结合业务的复杂度,设计出颗粒度更加细化的组件。
画出产品架构图
需求频繁且混乱,决策摇摆不定、动辄推倒重来。市面上一个好的产品经理是很贵的,没个三四万是拿不下一个真正靠谱的能抗住复杂产品线的产品经理,但是很多公司老板是不愿意花这个钱,一般就会招个工作一两年的产品经理先过来,顶个位置把这个工具给做出来就行了。恰恰因为这样一个认知导致产品经理这一层他既没话语权,又不能让自己闲着,所以层出不穷的需求全堆上来了,而对于公司长久型的产品架构就把控不住,如果一个产品经理无法起到,上对客户负责,下对开发负责,不会对所有需求进行筛选,把需求只会丢给开发,不会进行工时把控和质量把控。甚至对现有产品有什么功能,都不了解,那么就不是一个合格的产品。
所以对产品经理的要求非常严格,因为一个公司,如果战略方向把握住了,那么核心是要看产品,能否把握住市场方向,非常关键。这样才能决定你是否能占有市场,由于我司是做一个 ToB SaaS
化的平台,所以,必须要求产品经理清楚的了解客户实际需求,需求背后的实际场景,提炼出来哪些是共性的需求,哪些是客户定制化的需求,然后再讨论,再进行落地实际的开发。
对测试人员,尽量覆盖全所有场景,保证核心流程畅通,要求能找到复现步骤,提高开发解决 BUG 的效率。
由于我司采用的是 Ant Design
UI 库,所以设计标准,尽量都是按照 Ant Design
现成组件和样式来做,避免开发二次修改,参考这个链接 Ant Design 设计原则
某个列表页
普通的列表,和设计,产品都约定好,上面是筛选,下面是按钮,底部是表格展示。
某个详情页
详情页大量会使用到表单,所以直接使用 Ant Design
的 From
表单组件。
表单每行放多少个,都是以 Ant Design
组件来的。
这样带来的好处就是尽量避免定制化的开发,所有列表和详情都是按照这种风格来进行开发。
上面这些,包含其他的,大概花了一年多的时间,建设完成,我们目前的基建状况如下表所示
前端人员的开发效率较之前,提升了一倍左右的开发效率,前提是完全熟悉我这套项目框架的开发模式。
项目管理,人员工时占比,资源协调,目前下来都还不错,平稳进行。
如果你觉得对你有帮助或启发,欢迎点赞留言。
组内人员开发效率,较之前提升了一倍左右,普通的列表页面(搜索、展示、弹窗 ),包含接口联调 + 自测,大概 1 天左右完成,详情页面,复杂一点的表单交互,表单组件联动,大概在 2 天左右完成,包含接口联调 + 自测,目前我们也在探索 Vite
,Snowpack
,极大的提升开发体验。
SaaS
系统,首次无缓存加载耗时 3.22s ,三个系统( 30 多个页面,14 个公用组件)打包出来的体积在 9.3MB
当然还有优化空间
目前大部分页面不需要设计资源投入,尽量按照 Ant Design
设计标准和我们自定的 UI 标准风格来做,减少设计人员的工作投入。
目前所有的产品文档,技术文档都非常规范,可以溯源,以及当时在什么样的场景下,为什么要做出这样的解决方案。
1
DT37 2021-05-07 09:39:02 +08:00
学习到了
|
2
kop1989 2021-05-07 09:41:19 +08:00
写的挺好的,有借鉴意义。对你的成长速度感到很震惊。
|
3
jamsfox 2021-05-07 09:41:42 +08:00
挺有想法的,很棒
|
4
k9982874 2021-05-07 09:46:24 +08:00
四年经验可以哒
|
5
Tinu 2021-05-07 09:47:24 +08:00
学习了 感谢分享
|
6
coolxll 2021-05-07 09:52:56 +08:00
思路清晰
|
7
wzzzx 2021-05-07 09:53:45 +08:00
学习了,感谢分享
|
8
0x19A 2021-05-07 09:58:21 +08:00
学到了很多东西
|
9
server 2021-05-07 09:58:22 +08:00
马
|
10
GeorgeGalway 2021-05-07 10:02:50 +08:00
谢谢,对我很有用。
|
11
polaa 2021-05-07 10:13:52 +08:00 6
很棒 (尤其拉到最后 没看到推广
|
12
la2la 2021-05-07 10:14:06 +08:00 1
厉害呀,很多人骂屎山,但是自己上手整理的我见的还是第一个
|
13
luosch 2021-05-07 10:16:36 +08:00 via iPhone 4
公司太小,没什么参考意义
|
14
hafuhafu 2021-05-07 10:18:52 +08:00
梳理归纳能力好强
|
15
duduaba 2021-05-07 10:20:12 +08:00
很详细受用!
|
16
chenqh 2021-05-07 10:21:57 +08:00
NB
|
17
kidult 2021-05-07 10:22:01 +08:00
感谢分享,非常实用,并不是“人均”都在大厂
|
18
terrytang1 2021-05-07 10:28:59 +08:00
大佬,厉害,很多点要去细细读下
|
19
fengxianqi 2021-05-07 10:37:09 +08:00
规划和执行力,点赞
|
20
wtfdsy 2021-05-07 10:40:45 +08:00
学习了,特别是管理这块
|
21
eiheioffical 2021-05-07 10:46:10 +08:00
学习了,给大佬递茶
|
22
nekoneko 2021-05-07 10:51:22 +08:00
学习到了
|
23
Maxbee 2021-05-07 11:07:41 +08:00
点赞
|
24
xxxy 2021-05-07 11:18:15 +08:00
学习了,楼主前途不可限量
|
25
sakura1 2021-05-07 11:23:03 +08:00
优秀
|
26
NeroKamin 2021-05-07 11:24:26 +08:00
学习了,大佬的思路清晰执行力强,值得学习
|
27
shenlanAZ 2021-05-07 11:30:45 +08:00
非常干货 感谢分享!
|
28
eric1202 2021-05-07 11:57:08 +08:00
由浅入深,好文!
感谢分享~ |
29
lostSoul 2021-05-07 11:59:22 +08:00
这才叫干货,全文背诵,太强了,逻辑思路表达清晰
|
30
masterDu 2021-05-07 11:59:26 +08:00
学习到了
|
31
dany813 2021-05-07 12:02:02 +08:00
有点意思
|
32
chenshun00 2021-05-07 12:06:41 +08:00
干货
|
33
vToExer 2021-05-07 12:25:44 +08:00
很接地气的内容, Mark 一下
|
34
tmaller 2021-05-07 12:51:35 +08:00 via Android
mark 并反思自己
|
35
danhua 2021-05-07 12:52:55 +08:00
系统都在一个项目,最后是通过 webpack 进行分模块打包么。一起打包的话会不会体积比较大。
|
36
ericgui 2021-05-07 13:05:03 +08:00 via iPhone
最重要的东西没写: 折腾这么多以后,你们的各项性能指标咋样?打包体积小了吗?加载时间变短了吗?等等
还有,什么是{技术收敛}?你们又在发明新的黑话了。 |
37
drinke9 2021-05-07 13:21:48 +08:00
很棒的分享
|
38
GGGG430 2021-05-07 13:25:56 +08:00
干货满满
|
39
fantastM 2021-05-07 13:27:02 +08:00
相当受用
|
40
imnpc 2021-05-07 13:37:13 +08:00
全看完了 居然不是广告 已经感谢 非常棒的文章
|
41
hntangbohu 2021-05-07 13:51:04 +08:00
mark 一下,感觉可以落地
|
42
wildnode 2021-05-07 13:54:58 +08:00
这个崔丝塔娜是我想的那个崔丝塔娜吗?
|
43
hcen1997 2021-05-07 13:59:22 +08:00
> 但在实际情况中,还是会有一些接口文档和实际接口不符的情况发生,导致一些问题产生,这个我们也在思考。
可以要求开发自己写单元测试 直接使用 http 文件 |
44
a4854857 2021-05-07 13:59:41 +08:00
我草.好棒的分享.收藏了.
|
45
wwwarriorrr 2021-05-07 14:04:22 +08:00
厉害厉害,可以作为晋升 PPT 了
|
46
yoke123 2021-05-07 14:07:24 +08:00
感谢分享,向你学习。
|
47
lazyyz 2021-05-07 14:11:02 +08:00 via Android
感谢分享!
|
48
cnzjl 2021-05-07 14:11:34 +08:00
收藏了,以后学习
|
49
EvilDevilJin 2021-05-07 14:14:57 +08:00
学习 mark,感谢分享。
|
51
LiuJiang OP @ericgui 各项指标这个我忘记写了,今晚可能补上,目前来看,SaaS 系统,首次无缓存加载耗时 3.55s ,三个系统( 30 多个页面,14 个公用组件)打包出来的体积在 9.3MB ,组内人员开发速度,普通的列表页面(搜索、展示、弹窗 ),包含接口联调 + 自测,大概 1 天左右完成,详情页面,复杂一点的表单交互,表单组件联动,大概在 2 天左右完成,包含接口联调 + 自测。
|
53
codeforyou 2021-05-07 15:31:50 +08:00
牛逼
|
54
go522000 2021-05-07 15:44:38 +08:00
赞,非常好,喜欢这种真实实用的分享经验。
|
55
tcfenix 2021-05-07 15:52:45 +08:00
厉害了, 楼主你这套路相当厉害啊......
|
56
Salticey 2021-05-07 16:04:26 +08:00 via Android
可以可以,先 Mark 一下
|
57
yngzij 2021-05-07 16:07:37 +08:00 via iPhone
问下,出现多个 hotfix 分支怎么处理。
|
58
cnrting 2021-05-07 16:07:58 +08:00 via iPhone
那啥,楼主是不是忘了放公众号了🙃
|
60
justin2018 2021-05-07 16:15:55 +08:00
记得有次跟某公司对接 API 文档 是 Word 文档 哭~
|
63
aofel 2021-05-07 16:26:14 +08:00
发现问题,并解决问题,非常赞。
|
64
LiuJiang OP @justin2018 我们也经常遇到,这种在于事先约定好。
|
65
superBearL 2021-05-07 16:37:31 +08:00
干货满满,马
|
66
lskjdfgl 2021-05-07 16:38:42 +08:00
差评 我专门拉倒最后看推广居然没有 /狗头
|
67
ZeroV 2021-05-07 16:53:41 +08:00
条理清晰,学习了
|
68
tfdetang 2021-05-07 16:54:10 +08:00
非常棒的分享,很有启发性
|
69
ljkWeb 2021-05-07 16:59:51 +08:00
好文章,学到了
|
70
chendy 2021-05-07 17:04:16 +08:00
好文~
|
71
magichacker 2021-05-07 17:37:11 +08:00
我目前在公司也是这么干的,整个部门也是比较混乱。刚开始干,目前已经上线了代码规范的相关内容了,也上线了几个简化一些操作流程的 npm 包。剩下的内容还在稳步进行中
|
72
wqhui 2021-05-07 17:42:42 +08:00
感谢,写的很认真,从中也学到了很多东西。很多小公司在技术管理这方面都比较随意,各方面都需要从零开始弄,一时间也不知道从哪下手,像楼主有这么清晰的思路很难得
|
73
zzlatan 2021-05-07 17:43:14 +08:00
写得真好。学习了
|
74
ThinkPad93 2021-05-07 18:01:43 +08:00
git 工作流那里,合并 dev 分支有冲突的时候咋解决啊?
|
75
jeffxjh 2021-05-07 18:23:56 +08:00
文章条理清晰,有理有据。成长速度惊人!
|
76
RLinux 2021-05-07 18:35:22 +08:00
学习了
|
77
erwin985211 2021-05-07 18:59:16 +08:00
上一份工作跟楼主差不多,不过我们都是选择摆烂,这就是差距呀。
|
78
sanchez0623 2021-05-07 19:33:18 +08:00
好文,可以授权转载吗~
|
79
cxsz 2021-05-07 19:43:05 +08:00
楼主介绍的开始时的代码环境和我司现在差不多,我司现在就是 无逻辑、无流程、无文档、这种,而且为了配合甲方有时候会有紧急需求,临时需求这些,赶工实现了以后直接往生产环境部署......
|
80
LiuJiang OP |
81
NewExist 2021-05-07 20:33:47 +08:00
给大佬点赞
|
82
evilStart 2021-05-07 20:50:54 +08:00 via Android
为何选用 mobx 而不是 redux ?
另,你这不就是重构了原先的项目了么? |
84
callmemax 2021-05-07 21:25:32 +08:00
好文👍
|
85
python0707 2021-05-07 21:31:41 +08:00
向大佬学习了
|
86
amibug 2021-05-07 21:45:10 +08:00
优秀,给你点状!
关于提高中后台效能,最佳实践收敛除了统一脚手架还可以参考业界的做法比如类似飞冰组件、区块、代码片段沉淀。 关于动态表单配置方案,可以参考社区方案 formily |
88
xuanbg 2021-05-07 23:04:42 +08:00
pagesize 20000 应该是把所有数据拉到前端,然后实现搜索功能。
|
89
yifeng33 2021-05-07 23:11:37 +08:00
v 站
是怎么才能收藏帖子的 想自己入职以后再看看啊 |
90
Manley 2021-05-08 08:44:15 +08:00
牛皮,给大佬递 Java
|
91
netconf 2021-05-08 09:07:18 +08:00 via Android
给大佬递茶
|
92
Kaier 2021-05-08 09:11:48 +08:00
赞
|
93
tyrad 2021-05-08 09:28:29 +08:00
很强
|
94
ghwolf007 2021-05-08 09:42:14 +08:00
厉害了 学习一下
|
95
anzu 2021-05-08 09:51:30 +08:00
开头看着都痛苦
|
96
sanchez0623 2021-05-08 10:07:19 +08:00
@LiuJiang #80 好,谢谢,怎么注明你的出处?
|
97
Ballmer 2021-05-08 10:10:34 +08:00
大佬是干大事的人
|
98
cat9life 2021-05-08 10:34:20 +08:00
抱着看广告的心来的 一直看到后面 居然都没出现 有点失望?
|
99
jtchris 2021-05-08 10:51:37 +08:00
干得不错。另外看文章讲到痛点:主要是烂糟历史产品 + 没有前端工程化体系,文章讲了改造后:新项目新框架以及前端各种工程化实践。想了解下另一个痛点烂糟的历史产品是如何改进的。
|