给未来的自己——我的2023年终总结

1、前言

临近年末了,最近的需求比较少,因此有时间撰文与大家分享我的2023。

先说一下我的个人情况,我是94年的一枚前端程序员,我目前已经29岁了,本科,末流211,大学自学的计算机,非科班出身,所以大家就当我是个普通本科就行。目前在一家不大不小的知名创业公司任职,现在公司的技术栈老的项目是Vue2,新的项目用的是Vue3,至于公司名就不告诉大家了,当一个小秘密吧。

我是去年8月份的时候来到现在的这家公司的,真心感谢公司收留。在去年我经历了两次裁员,大家有兴趣的话,可以看一下我去年写的那篇文章:分享一个一年经历两次裁员的程序员的一些感触 - 掘金 (juejin.cn)

因为目前公司的业务还算稳定,今年没有裁员方面的担忧,所以能安稳的踏实做技术。

2、我在的2023年的收获

因为今年年初的技术规划基本上已经达成了,所以整体来说,今年的收获我还是比较满意的,哈哈哈,以下大概是今年大方向上的收获,与大家逐一分享。

在2023年刚开始的时候,我也不是专门负责公司的基建工作的角色,平时也有和大家一样的业务开发量。但是随着我的一些设想和自己的一些实践得到了公司领导的认可,我逐渐的侧重了前端团队的基础能力建设。

收获1:使用NestJS实现BFF

在今年年初,公司的后端小伙伴们就制定了一些现有项目的重构计划,年初的时候技术经理在纠结使用GO语言来做BFF还是使用Nodejs,在我们组的小伙伴不断的跟后端同事吹嘘Nodejs好,什么异步I/O,什么弱语言,编写代码自由,开发效率高之类的洗脑词之后,公司决定使用Nodejs来做BFF服务。

因为我作为前端组里面少数的接触过后端(在大学的时候写了2年的ASP.NET MVC,毕业之后做外包,帮别人写过几个月Spring MVC)的成员,有幸全程负责了那个BFF服务的开发。

在做技术选型的时候只考虑了2个框架,其中一个是NestJS,另外一个是MidwayJS,因为考虑到稳定性的因素嘛,我倒不是贬低Midway的意思哈,就单纯的觉得MidwayJS问世的时间比NestJS短了很多,于是就采用了NestJS构建。

因为我们的这个NestJS的项目定位是BFF,所以它并不像传统的后端服务那样,业务后端给我们限制了很多权限,我们最多就只能使用Redis存储一些数据,至于像MySQL这种数据库的操作,那就完全不给开放了。

然后我们与业务后端的通信方式全部采用的是gRPC方式,如果不知道gRPC的同学,可以Google一下了解一下它是什么。

在集成gRPC的时候,还是爬了很多坑的,像NestJS官方文档给的例子还是有点儿坑的,有点儿揠苗助长的感觉,对于没有接触过的新手来说的话,会把人带偏。NestJS的官方文档给的例子是动态的解析proto文件,并且最重要的一点是,它的Demo是NestJS自己启动一个gRPC服务给外界消费,而我的诉求是我需要使用gRPC的方式,消费业务后端给我的gPRC服务,这个区别还是挺大的。

另外,还有一个坑,官网给的Demo的那种动态加载proto文件的方式,真的实在太太太简单了,简单的让人无力吐槽,哈哈哈,而实际项目,后端给我扔过来的直接是一个文件夹,这堆文件中的proto文件相互引用,在尝试了很多次之后无法正常运行之后,我们采用了静态加载的方式,即先用工具将proto文件解析成JS,然后再代码中引用。

我为后端编写了一个脚手架,每次他们修改完proto文件的时候,CI去执行我写的脚手架,然后将产物组合成一个npm包,发布到公司的内网npm源,我们在NestJS项目中更新一下即可。

目前我正在更新NestJS相关的文章,有兴趣的同学可以关注一下,哈哈哈。

收获2:前端组件库搭建

站在如今的时间点来看的话,今年做这件事儿算是全年收获最大的一件事儿了,其实在没有做这件事儿之前呢,我是对前端的很多基础知识都属于略知一二,但是真的让我去编程写代码可能就脑瓜子疼了,于是我选择了站在巨人的肩膀上,看一下目前开源的库的做法。

因为是移动端的组件库,并且要支持Vue2,可能你会觉得我们很sb,都Vue3的年代了,还去做什么Vue2的组件,其实不是,主要是因为这个组件库服务的对象都是一些基于Vue2已经写好了的项目,如果用Vue3写的话,那就都得全部重构,人力有限,完全不可能的。

当时找了一圈,像vant,cube都觉得太老了,经过一番努力,找到了推出没有多久的varlet,从这个时候基本上就算是打开了我知识的大门了。

Varlet本来是一个只支持Less的组件库,但是我们之前的项目的css是用Scss写的,完全把Scss改写成Less也不是说不行,但是我是觉得Scss写起来比Less更舒服,所以我必须要去搞懂怎么样集成Scss

在这个过程中,怎么编译.vue文件的,怎么处理其中的样式,怎么编译JS,对于完全没有接触过的我来说,可是吃了相当的苦头的,而且我当时还面临着一个问题,如果使用Varlet改造这个方案行不通,到时候会影响项目的正常上线的,我已经没有退路了,我必须全力以赴将这些问题搞定,用李云龙的话说就是,都是两个肩膀扛一个脑袋,凭什么别人行,你不行啊。正是凭借着这种不服输的精神,我克服了这些问题,通过阅读它的源码,不断的打断点调试,完全掌握了从Vue组件编译到最终打包的这整套流程。

Varlet是基于pnpm管理的,我顺便就掌握了Monorepo的开发方式,而且当时恰好在刷算法,还使用拓扑排序算法来改进了一下Monoropo仓库中各个子项目的依赖构建顺序。

如果我不去做这个事儿的话,我可能就只能永远的停留在人云亦云的去背诵vue-loader所完成的任务了,但是我做了这个事儿,把别人的东西迁到自己的项目并不是一蹴而就的,你肯定会遇到坑,这个解决问题的过程中,就把底层的那些包的关系几乎都能理解了。

收获3:前端自动化

因为在组件库的搭建上,阅读开源项目的源码尝到了甜头,于是在前端自动化这块就更加的顺利了,很大程度上,varlet的作者像是给我打开了思维的大门(在此对Varlet的作者最诚挚的敬意),剩下的就完全是我自我发挥的空间了。

曾经在某知名互联网公司的时候,我觉得他们的基建还是做的挺好,对于当时的我来说,真的好佩服这些大佬啊(能够自己编程调用Webpack的API去构建各种代码,能够自己写各种各样的脚手架,满眼都是写着羡慕)。

我自己都没有想到,不到2年的时间,这些东西竟然大部分都被我掌握了,我们公司的营销活动和之前在某知名互联网公司的时候所面临的场景几乎相似,而我们的活动甚至比他们的节奏还要快。

对于一个开发几天,运行几天就下线的活动怎么用自动化的上线方式来管理,这是困扰了我们团队很长时间问题,在之前的团队基本上就是属于放弃治疗的态度,所以给我们的就是一个烂摊子,项目手动构建发布,就好像是停留在刀耕火种的时代。

但是在看了Vartlet作者处理组件库的官方网站思路之后,我有点儿豁然开朗的感觉了。

我参考了vartlet的部分代码,通过手动调用vite的API的方式,让每个项目都单独成为一个子项目,这个子项目托管在大的项目中,大的项目上配置了CI/CD,当每次合并到测试环境的时候,我编写了一个脚手架,通过GIT的日志找到相应的项目变更,然后决定对哪个子项目进行构建。构建的过程中,把其中的资源全部传到公司的CDN上,我可以通过配置publicPath的方式,甚至都不需要再编写插件去处理源代码了。构建完成之后,把最后的那个index.html作为一个静态文件的形式,托管给Nginx,那测试环境就可以按照目录的规范访问了。对于上线,把这个自动发布的过程变成手动的即可。这样就实现了全自动化的上线,而且,对于我们公司的项目来说,之前还不可避免的存在文件膨胀的问题,现在成了一个一个的子项目,连文件膨胀的问题都解决了,反正每个都是一个子项目,只不过它还存在于仓库内而已,有些看着碍眼,但是却不会参与构建,不会影响构建的速度。

在这个过程中,我通过阅读一些开源项目的源代码,了解到了一些常见的对Node某些API封装的库的用法,在后续的文章中,我会出一个系列专门为大家分享。

收获4:算法,依然在路上

我是那类很敬重算法的人,我算是在21年的时候开始专门花时间来研究数据结构与算法,我是明显感觉到这两年脑袋瓜子明显变聪明了。

我在当年刚去某知名互联网公司的时候,我经常写bug,也算坑了同事不少,我会经常的感觉到不好意思。但是在这经历两年的算法训练之后,我明显的感觉到自己的能力提高了,因为刷题总会想怎么用更少的次数通过题目,而日复一日的训练,也就形成了习惯性的去思考边界case,代码就越写越好了。

下面是我在23年一年时间刷的题,还算勉强吧,我基本上会在某段感到迷茫的时间内就会刷力扣,对于我来说,不知道干什么,就当开卷有益了吧。

我想通过我的个人经历告诉大家,前端至少应该要完全掌握大学课本上所讲到的数据结构和算法的知识点,有的同学觉得算法不重要,前端没有什么实际应用场景,其实这个观点是错误的。

以下就是我在实际开发中看到的算法的应用场景:(仅仅是我发布在掘金上的文章)

因为你不知道怎么样用更优秀的办法去解决某些问题,在设计的时候就是完全两个维度。(以并查集为例,如果不知道并查集这个知识点,在求图的连通分量的时候思路复杂的令人发指,就算写出来,运行还是可能超时,用并查集是降维打击。)

在新的一年里,我还会继续。

3、明年的规划

在23年的年末,我已经开始研究NestJS的源码了,并且有一定的成果。

在24年,我将继续阅读开源项目的源码,我给自己24年定的最大的目标就是吃透vite,这是一个宏伟的目标,相对于阅读NestJS的源码来说的话,这个的难度还是不小的,因为现在的前端之所以复杂就复杂在基建所处理的内容,因为我们不知道这些过程中所经历的流程,可能一个简单的报错,就把整个人都搞的懵逼了。我目前也开始在看vite的源码了,我是很清楚的感受到,如果把vite吃透的话,那基本上就差不多可以把现代前端的前世今生搞个明白了。(babel,AST,脚手架,rollup,browserlist,scss等css预处理工具)

对于明年来说,我将会把更多的精力将会活跃在论坛上,希望编写出更多有价值的文章与大家分享我的开发经验。

最后,再给自己的Leetcode定一个小目标,希望在2024年结束的时候,刷题量达到800。

4、给大家的一些建议

我是明显的感觉掘金现在的文章的质量大不如从前了,我是从18年就开始使用掘金了,如果你还在使用掘金学习的话,我希望大家可以避免一些标题党的文章。

举个例子:就像我经常给大家吐槽的,都已经2023年了,大家还在热衷于Vue父子组件的通信方式,哈哈,是什么让你们坚持下来的,我也不得而知了。

最后再说一些招喷的话,我比较认同抖音上一个叫九剑前端的博主说的话:"高处空气好"。本来前端就不是一个技术含量高的工种,如果大家都去重复做一些简单的事儿,那肯定就会导致这个行业的整体待遇的下降,因为在目前在时代来说,我们还有人口红利。只要你能做成别人不能做的事儿,那你就一定能行,裁员你肯定不是第一个人选,如果全部门裁员肯定还会有别的团队接纳你,因为你有掌握着某些不太容易替代的技能。

最后,给大家一些建议,多看一些有用的书籍,如果有余力的话,最好自己亲自看源码,这样能够避免人云亦云,掌握核心科技才是硬道理,看源码也不用太功利的就是为了面试而看,我觉得以解决问题的视角去看源代码是一个绝佳的实践(至少我是这样的,哈哈哈),因为我们对这个事儿印象深刻,反而过了很久都不会忘。

最后,祝愿大家在2024年都能取得长足的进步,加油,向各位奋斗中的同行们致敬!。

相关推荐
dream_ready1 小时前
linux安装nginx+前端部署vue项目(实际测试react项目也可以)
前端·javascript·vue.js·nginx·react·html5
编写美好前程1 小时前
ruoyi-vue若依前端是如何防止接口重复请求
前端·javascript·vue.js
flytam1 小时前
ES5 在 Web 上的现状
前端·javascript
喵喵酱仔__1 小时前
阻止冒泡事件
前端·javascript·vue.js
GISer_Jing1 小时前
前端面试CSS常见题目
前端·css·面试
八了个戒1 小时前
【TypeScript入坑】什么是TypeScript?
开发语言·前端·javascript·面试·typescript
不悔哥1 小时前
vue 案例使用
前端·javascript·vue.js
anyup_前端梦工厂2 小时前
Vuex 入门与实战
前端·javascript·vue.js
你挚爱的强哥3 小时前
【sgCreateCallAPIFunctionParam】自定义小工具:敏捷开发→调用接口方法参数生成工具
前端·javascript·vue.js
米老鼠的摩托车日记3 小时前
【vue element-ui】关于删除按钮的提示框,可一键复制
前端·javascript·vue.js