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

从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