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

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

image.png

人力问了我两个问题

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

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

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

技术不进则死

image.png

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

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

本着技术不进则死的自我勉励，赶紧照着示例写了一个demo。
看着这个angular2的demo，内心满是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: 移除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个人的小团队。
那是一段浑浑噩噩的摸索期，项目经理.张告诉我: “少写一些业务把精力放到其他的事情上，比如说人员成长，公共组件”。

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

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

在这些往事里，有几个想法值得记录：

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

忆往昔，往往意犹未尽。

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

image.png

传送门

• GridManager 请不要吝啬star
• jTool
• 个人博客