之前的总结多数是以年度分割,但是其实如果按照阶段来进行划分会更加合理,加之从阿里云到小赢都没有做过正式的总结,所以就有了这篇跨越一年的总结。

从17年初到现在,对于我来说是很折腾的一年,也是我辩证的去思考验证“到底要什么,到底不要什么,要成为什么样的人”的重要时光。

五月的时候在职业上的思考一文中,我记录了一些观点,经过再三考虑,决定离开小赢,并拒绝了老板加入风头正火的链方向子公司的好意,寻找更合适的土壤去生长。

在休息了一个月后,回顾这一大段职业历程,感觉其实还是收益良多,从纯粹的前端技术专家转向技术TL、团队负责人,不单单是职责上的变化,更多的还有性格上的磨砺和做事方法的改变。

离职根本问题出现在哪里

相比离开阿里云更多是因为 “Work-Life Balance”。在小赢签完期权,内部频繁传来“利好”消息、团队人员扩充顺利的时刻离开,是为什么呢:是因为今年年初的团队合并;是因为简化技术栈;还是因为要被迫剥离掉一些业务类型。

我认为这些只是表面问题。

更深一层的体现是多数人(包括核心)对于前端职能的看法依旧是几年前的只处理页面相关事务的岗位,并且教育成本很高,甚至几乎不可能进行改变。

技术部门整体在成长过程中忽略了对体验的标准化建设,对于组件建设的认识有很大分歧,限定了前端跨端的发展、也限制了对用户体验界面部分的技术投入,所以某个角度来看,UED部门的存在是合理且必要的,这点阿里做的很好。

前端、后端、客户端三端合并,前端基本基本失去了提供 Node 接入层的可能性(同样缺乏支持良好的API Gateway),Node 的使用基本只能在日常构建、持续集成中的胶水工具中使用。在大量使用 SPA 架构的产品状况下,提供同构 SSR 基本成为不可能的事情,页面性能严重受限于 CDN 质量,交付效率严重受制于 API Provider。

从管理成本来讲,看似简化了团队架构,减少了心智负担,但是长期来看,却损失了难以弥补的用户体验,及其改进和创新的可能性:

  • 如果考虑异构 SSR ,维护异构引擎有大量额外成本,不提供 SSR ,则要做大量兼容处理。
  • 如果考虑 API Gateway(提供类似GraphQL的能力)会更好,因为多数情况只有具体客户端的开发者明白他要的是什么数据。但是从成本和可行性考虑,异构跨团队的 API Provider 方式,或采用既熟悉前端又熟悉Java的人去进行API实现,明显不如使用 Node 进行同构服务:好招聘、也好进行项目管理,还能提升团队整体业务水平。
  • Web前端产品几乎没有任何分发限制,可以在任何平台进行快速分发和更新,所以被广泛应用在各种平台中,近几年也出现了越来越多的 “小程序/PWA” 的前端 PaaS 平台,但是若团队职能依旧只是耕作于传统页面,将会是对前端创新能力的一种严重浪费。

对于我个人而言,这也是再一次经历大量零到一的基础改造搭建,却受限于环境无法经历一到十的过程,十到百的困境。

正如之前五月网志中提到的一些看法,我个人需要的是:

  • 能给自己带来归属感、成就感的产品和领域。
  • 和技术相关性更大的产品:
    • 长期看会随着技术变化而产生产品形态的改变。
    • 存在相对复杂的技术挑战。
    • 可以做0-1,建设团队和技术设施,但是不能止步于0-1、1-60,要能够去做60-100。
  • 有技术品牌建设、技术文化营造的环境。

在业务里选择合适的技术,然后用发展的技术去挑战已有设计,改善体验,才能做到不断挑战和更新自己,让工作中总是充满激情。

聊完了问题,回顾一下这段时间的成长。

团队方面的成长

个人觉得做的还不错有:

  • 标准建设
    • 通过技术工具来保证最基本的交付质量、使用结对来进行代码实现的纠正,而非简单的风格上的纠结。
    • 持续集成在开发和交付过程中落地,使用稳定、可维护的环境来进行一致准确的构建发布,避免人工接入。
    • 改善流程的同时,尽可能避免“乱忙”、无用的加班,必须的加班做到尽可能的高效,不打加班持久战。
    • 应用标准的分支模型,减少代码资产管理的负担,提供代码历史的可读性。
    • 废弃陈旧可维护性低的构建系统、升级并统一开发技术栈,建设必要的前端基础技术设施。
  • 人员建设
    • 进行持续招聘疯狂打call,完成团队的组建,找到气味相投的人才。
    • 挖掘每个人擅长和喜欢的方面,给予适合的业务去成长发挥。
    • 利用之前的规划和产出的技术成果,在激烈竞争中为小伙伴们争取到两次公司季度奖励。
    • 做了一些创新性质的产品,部分转化为后续的业务方向,诸如:小程序。
    • 背锅挡锅,祸不及小伙伴,有一种回到十年前大学时代魔兽世界里当Tank的感触。
  • 文化建设
    • 进行了公司范围的技术小报的尝试、进行了Docker容器技术的多次分享、进行了Node.js的工具化、持续集成的分享。

不足的地方:

  • 出于心底还是不认同 P2P 这类产品,所以没有在产品上进行思考和创新,没有着重的去把控产品开发节奏,只是着力于:稳定高效交付、多渠道快速迭代两点上。
  • Office politics, 这个话题就不展开了,再次选择团队时,除了了解机会本身之外,需要了解的内容应该还要更多一些。
  • 在团队几次合并中,没有坚持几个正确的前端技术选型,导致后面一直在进行补救。
  • 很遗憾离开的时间点,没有机会将公司技术博客落地并进行推广了,不过把之前刘江老师搭建学院的一些经验全数传递,希望后面有人能够开花结果吧。

技术方面的成长

不得不说,纯前端方向成长并不多,屈指可数的几点吧:

  • 对 ES6、Vue 更加熟悉了,算上阿里云时用的 Angular & React、美团时用的 React、淘宝时用的 Kissy,基本把前端领域知名偏浏览器前端框架都踩了一遍坑。

但是泛前端和服务端领域就多了:

  • Node 越来越顺手,现在不管是写分析脚本还是cli工具,如果简单的shell不能满足,顺手写一个脚本解决问题,还是挺惬意的。
  • 容器玩的越来越称手,针对不同类型的应用,折腾了各种各样的容器使用配置。
  • 代码仓库、软件包管理仓库、CI/CD系统、监控设施、代码性能工具的定制、搭建和维护。
  • 前端脚手架的定制开发,高度模块化,各模块可拔插。
  • 玩了一阵数据分析和整理,还折腾了一些IOT设备,米家、ESP板子。

简单来说,一个互联网团队的技术基础设施差不多都能顺利搭建并维护起来了。

除此之外呢:

  • 基于前几年折腾的家用高速网络,在家里的“试验田”中基本上完成了我对于“理想开发环境”的雏形的搭建。
  • 成为一个养猫好手兼优秀的铲屎官。

其他

收拾工位的时候看到了之前定制的手托刻字,希望依旧能够“砥砺前行,不忘初心”。

–EOF