五年有余,离开前留点文字忆往昔

1,636

2016年加入,2021年离开,五年有余。
有过美好,也有过无奈,告别数云之前整理一下,留点文字忆往昔

image.png

人力问了我两个问题

提出离职后,人力问我为什么会选择离开。
我顿了下,很平静的说道:“以前早晨醒来,会想着今天要去做什么事情,而且是那种特别想要去完成的事情。”
可是,现在的早晨却在懒床。

人力笑出了一个我懂的表情,然后问了另外一个问题:“五年多的时间里,你最大的收获是什么?” 思考了半分左右的时间,直视着人力说道:“忍耐”。

在人力惊讶的眼神中,我想起了许多。

技术不进则死

image.png

在2015年开始维护博客的时候,就在博客管理端中写着一段22px的自勉:技术不进则死,即然选择,请坚持!

遥想2016,只写过jQueryreact demo的我在面试时,更多展现的还是基于jQuery的各种手段。
直到有一天,刚把angular1.x脏检查搞明白的我,猛然间发现各大社区都在欢庆angular2的横空出世。

本着技术不进则死的自我勉励,赶紧照着示例写了一个demo。
看着这个angular2demo,内心满是MMP:“这特么就不是同一个框架好吗?
稍微一犹豫,时间就过去了几个月。在上海团队再次扔过来一个项目的时候,框架居然是React+angular1.x的混搭。

只有React字母编写React demo开发经验的我,不得已开启了React的学习之路。
又是一套不同的前端语法糖,又是一套不同的前端思想。期间在翻阅各大社区时,偶尔间发现了前端框架的占有率折线图:看上去vue 2.0势头也很猛哎?

脑袋只有一个,压哪个?

学哪个框架

image.png

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: 移除GridManagerjQuery的依赖,改造为纯原生JS实现。

这是一个大胆的尝试,也是一次瓶颈期的自我突破。后续在学习各个框架的API时,总能很快的理解其背后的实现逻辑。

然后,我做了另外一件事:将GridManager中的基础方法抽取为js类库,命名为jTool,以此向经典的jQuery致敬。

jTool是一个类似于jQueryjs类库,包含了常用的jQuery的方法,如:EventAjax

做为泥腿子出身的程序员,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项目时,立刻就提升了我对麻雀虽小五脏俱全的认知。

遥想当年,正在配置jdkidea的切图仔一转头与项目经理四目相对,项目经理意味深长的说了句:“这项目每年双11都会崩溃,已经5年了……”。躲闪过项目经理关爱的眼神,冒出来一个想法:我现在跑路还来的急不?

一闪而过的想法之后,是改变这个现状以证明自已的机会。 将项目跑起来后,发现性能问题有点罄竹难书的意思,较大的几项如下:

  • jsp未实现前后端分离
  • 无模块化概念
  • 接口调用频繁,且这些淘宝接口的调用需要收费
  • 超多的setInterVal
  • ……

对这种拥有一定年龄的项目,渐性优化的步骤如下:

  • 搭建一个新的前端项目,当时采用的webpack2 + angular1.x + es6
  • 将原项目通过iframe嵌套入新项目,此时项目可以完整的运行
  • 以一级菜单为单位,进行渐性重构
  • 清除历史遗留代码,保证核心功能清晰
  • 提供静态数据缓存方案,对非必要性接口只在初次加载时调用
  • 搭建CDN,将公共资源替换为CDN资源
  • iconfont整理,尽量不使用图片
  • 解决index.html缓存问题
  • 常用数据的加载机制调整为预加载
  • 查看火焰图,查找js性能瓶颈并优化
  • 寻求产品、后端、测试配合,期间要学会忍耐

得益于之前的罄竹难书,优化后的性能提升肉眼可见。在刚转正的某一天,突然被大领导.蔡拉到一边说:“你最近做的事情很有意义,公司决定给你涨薪xxxx,本月生效”。
本月生效的意思就是在这个月的工资中就会有所体现,而那天是27号。

我眼中的管理

五年前认为对研发人员来讲技术能力最重要,五年后认为团队协作更重要。

刚到数云不久,在项目经理.张前端经理.郑的提携下,从来没有管理经验的我被安排到了前端组长的位置,管理一个4个人的小团队。
那是一段浑浑噩噩的摸索期,项目经理.张告诉我: “少写一些业务把精力放到其他的事情上,比如说人员成长,公共组件”。

然而,在除了业务代码以外的事情,我其实是找不到头绪的。

直到后来大领导.蔡亲自下场指导(批评),才多少找到些方向。随着时间的推移,五段年华成为往事。

在这些往事里,有几个想法值得记录:

  • 领导经常会说:“我希望你能把问题提前抛出,而不是等到了截止日期再让我知道”。然而,当你在提前抛出问题前,最好想想是否真的没有了任何的解决方案。
  • 下属的工作安排应当相互交叉、松弛有度,相互交叉是为公司负责,松弛有度是人员成长的前提。但若你选择松弛有度,那么来自上面的压力需要你独自承担。
  • 协调人员时,部门内可以完全依仗职位,部门外却必定需要一些人缘。所以少做亏心事,是自已的锅就请站直了背好。
  • 管理很难做到一碗水端平,因为人是有感情的。

忆往昔,往往意犹未尽。

收拾行囊,向着明天出发。
个人简介: 只要坚持,蚂蚁也能移走愚公门前的那座山。

image.png

传送门