2016
年加入,2021
年离开,五年有余。
有过美好,也有过无奈,告别数云之前整理一下,留点文字忆往昔。
人力问了我两个问题
提出离职后,人力问我为什么会选择离开。
我顿了下,很平静的说道:“以前早晨醒来,会想着今天要去做什么事情,而且是那种特别想要去完成的事情。”
“可是,现在的早晨却在懒床。”
人力笑出了一个我懂的表情,然后问了另外一个问题:“五年多的时间里,你最大的收获是什么?”
思考了半分左右的时间,直视着人力说道:“忍耐”。
在人力惊讶的眼神中,我想起了许多。
技术不进则死
在2015年开始维护博客的时候,就在博客管理端中写着一段22px
的自勉:技术不进则死,即然选择,请坚持!
遥想2016,只写过jQuery
和react demo
的我在面试时,更多展现的还是基于jQuery
的各种手段。
直到有一天,刚把angular1.x
脏检查搞明白的我,猛然间发现各大社区都在欢庆angular2
的横空出世。
本着技术不进则死的自我勉励,赶紧照着示例写了一个demo。
看着这个angular2
的demo
,内心满是MMP:“这特么就不是同一个框架好吗?”
稍微一犹豫,时间就过去了几个月。在上海团队再次扔过来一个项目的时候,框架居然是React
+angular1.x
的混搭。
只有React字母编写
及React demo开发经验
的我,不得已开启了React
的学习之路。
又是一套不同的前端语法糖,又是一套不同的前端思想。期间在翻阅各大社区时,偶尔间发现了前端框架的占有率折线图:看上去vue 2.0
势头也很猛哎?
脑袋只有一个,压哪个?
学哪个框架
2016年下旬,老夫jQuery
一把梭的时代已经成为了过去式(假装这里有张图.jpg),angular1.x
也渐显颓废。看着那本九成新的精通angularjs
,开启了自问模式:[Angular2, React, Vue2]
,先学哪个?
摸着自已略微后移的发际线,告诉自已这个问题很重要。不仅要在网上搜罗万相,也要在同行里发起讨论。
一翻折腾之后,惊的一身冷汗:在2016年的某一天,Angular4.0
发布了。
一念之间,想到了java ssh
框架之一的struts
。彼时的我还是一名java粘贴工程师
,懵懂之间经历了某个项目从struts1
升级到struts2
的悲惨历程。
那一次,struts
给我留下了闭包式的回忆。许久未能痊愈的我,便投身到据说相当美好的前端行业。
此时此刻,恰如彼时彼刻。
如业界多位大佬所言及的论调:前端可以摸着后端过河。
方法有了,就开始摸吧。
要说摸后端过河,那肯定首选后端架构师。巧如拍戏,那次年会我和架构被分到了一个标间。
于是,我问了几个问题:
- 当年的
struts2
现在还有项目在用没? - 现在的后端用的什么框架,这套框架后续变化如何?
- 当年的后端框架是否也出现过百花齐鸣?
-
angular
这种断崖式版本,还值不值得学习?
架构的回答,汇总下只有六个字: 万变不离其宗。
以实现业务逻辑为目的,针对性的学习框架;以原生JS为基线,全面提升技术能力。
原生JS才是核心
上面有提到在2016年面试的时候,展示了基于jQuery
的各种手段。在这些手段中,最主要的便是一款表格组件: GridManager。
2016年初,立了个Flag
: 移除GridManager
对jQuery
的依赖,改造为纯原生JS实现。
这是一个大胆的尝试,也是一次瓶颈期的自我突破。后续在学习各个框架的API时,总能很快的理解其背后的实现逻辑。
然后,我做了另外一件事:将GridManager
中的基础方法抽取为js类库,命名为jTool,以此向经典的jQuery
致敬。
jTool
是一个类似于jQuery
的js类库
,包含了常用的jQuery
的方法,如:Event,Ajax。
做为泥腿子出身的程序员,jTool的编码过程并不顺利,回想起来有以下几个原因:
- 技术思维固化,在前端框架异军突起的2016,
jQuery
的DOM思维尚未改变。 - 编码过程中涉及到很多原生API,需要经常查找文档;磕磕绊绊的编码岁月里,MDN全程陪伴。
- 由于定位为类库,所以会对代码反复雕琢;然而反复雕琢有个更加通俗的名词:需求变更。
期间也有过退却的想法,特别是在周末的凌晨:解决不掉睡不着的BUG,跳动的时间和家人不断的催促,身体的困顿和第二还要去公司打罐头的生活压力。烦躁感上来了,把电脑一扣。上个厕所吸根烟,又翻开了电脑。
当2017后的某一天,将jTool
引入GridManager
,随着npm run start
顺利展现的那一刻,激动的把成果四处展示,以至于忘记了有些人不是同行。
jTool, 个人编码路上的里程碑。
也许这种有目标的学习方式,才是适合我的方式。
今天在整理这个文章的时候,有了一个感悟: 让jQuery走向没落的原因可能并不是那些框架,原生的javascript才是jQuery的掘墓者。
随着ECMA
的每次提案,javascript
都在不断的吸收着jQuery
的价值。其它框架,又何尝可以逃脱这个魔咒?
岁月催人老,一觉醒来Angular12
了。
工程化思维
来数云之前,只使用过gulp
,仅是那种字面意义上的使用。接手的项目以gulp
为主,虽然当时不太明白这些task
的甬道思维,但同行者众,相互学习。
2016年的6月,我和个陕西妹子结对编程,写了第一个基于webpack1 + angular1.x + es5
的项目。
虽然不久后公司取消了结对编程,但革命友谊长存,革命者尚众,前端人员相互分享着经验:
- es5 -> es6
hi, babel
- eslint
代码校验
- jenkins
前端发布工具
- jasmine+karma
单元测试
- mock
写个假接口自已调
- node
写个真接口自已调
- linux
边写边忘
- ……
至于webpack
, 一众人等从1升到2,再升4,最升5。然后,各奔前程。
关于工程化,我现在的理解: 用于服务核心代码的工具及代码即为工程化,包含但不限于构建、校验、单元测试、发布、服务器接收。
对于工程化,同一个团队应该保持统一。
印像最深的一件事
到公司不久后,接手了一个项目的重构工作。初次看到这个jsp项目时,立刻就提升了我对麻雀虽小五脏俱全的认知。
遥想当年,正在配置jdk
和idea
的切图仔一转头与项目经理四目相对,项目经理意味深长的说了句:“这项目每年双11都会崩溃,已经5年了……”。躲闪过项目经理关爱的眼神,冒出来一个想法:我现在跑路还来的急不?
一闪而过的想法之后,是改变这个现状以证明自已的机会。
将项目跑起来后,发现性能问题有点罄竹难书的意思,较大的几项如下:
-
jsp
未实现前后端分离 - 无模块化概念
- 接口调用频繁,且这些淘宝接口的调用需要收费
- 超多的setInterVal
- ……
对这种拥有一定年龄的项目,渐性优化的步骤如下:
- 搭建一个新的前端项目,当时采用的
webpack2 + angular1.x + es6
- 将原项目通过
iframe
嵌套入新项目,此时项目可以完整的运行 - 以一级菜单为单位,进行渐性重构
- 清除历史遗留代码,保证核心功能清晰
- 提供静态数据缓存方案,对非必要性接口只在初次加载时调用
- 搭建
CDN
,将公共资源替换为CDN
资源 -
iconfont
整理,尽量不使用图片 - 解决
index.html
缓存问题 - 常用数据的加载机制调整为预加载
- 查看火焰图,查找
js
性能瓶颈并优化 - 寻求产品、后端、测试配合,期间要学会忍耐
五年前认为对研发人员来讲技术能力最重要,五年后认为团队协作更重要。
我眼中的管理
刚到数云不久,在项目经理.张
和前端经理.郑
的提携下,从来没有管理经验的我被安排到了前端组长的位置,管理一个4个人的小团队。
那是一段浑浑噩噩的摸索期,项目经理.张
告诉我: “少写一些业务把精力放到其他的事情上,比如说人员成长,公共组件”。
然而,在除了业务代码以外的事情,我其实是找不到头绪的。
直到后来大领导.蔡
亲自下场指导(批评),才多少找到些方向。随着时间的推移,五段年华成为往事。
在这些往事里,有几个想法值得记录:
- 领导经常会说:“我希望你能把问题提前抛出,而不是等到了截止日期再让我知道”。然而,当你在提前抛出问题前,最好想想是否真的没有了任何的解决方案。
- 下属的工作安排应当相互交叉、松弛有度,相互交叉是为公司负责,松弛有度是人员成长的前提。但若你选择松弛有度,那么来自上面的压力需要你独自承担。
- 协调人员时,部门内可以完全依仗职位,部门外却必定需要一些人缘。所以少做亏心事,是自已的锅就请站直了背好。
- 管理很难做到一碗水端平,因为人是有感情的。
忆往昔,往往意犹未尽。
收拾行囊,向着明天出发。
个人简介: 只要坚持,蚂蚁也能移走愚公门前的那座山。
传送门
-
GridManager
请不要吝啬star
- jTool
- 个人博客