本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或重新修改使用，但需要注明来源。 [署名 4.0 国际 (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/deed.zh) 本文作者: 苏洋 创建时间: 2018年08月15日 统计字数: 2773字 阅读时间: 6分钟阅读 本文链接: https://soulteary.com/2018/08/15/career-journey-summary.html ----- # 一年以来的职业历程总结 之前的总结多数是以年度分割，但是其实如果按照阶段来进行划分会更加合理，加之从阿里云到小赢都没有做过正式的总结，所以就有了这篇跨越一年的总结。 从17年初到现在，对于我来说是很折腾的一年，也是我辩证的去思考验证“到底要什么，到底不要什么，要成为什么样的人”的重要时光。 五月的时候在[职业上的思考](https://soulteary.com/2018/05/23/professional-thinking.html)一文中，我记录了一些观点，经过再三考虑，决定离开小赢，并拒绝了老板加入风头正火的链方向子公司的好意，寻找更合适的土壤去生长。 在休息了一个月后，回顾这一大段职业历程，感觉其实还是收益良多，从纯粹的前端技术专家转向技术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板子。 简单来说，一个互联网团队的技术基础设施差不多都能顺利搭建并维护起来了。 除此之外呢： - 基于前几年折腾的[家用高速网络](https://github.com/soulteary/Home-Network-Note)，在家里的“试验田”中基本上完成了我对于“理想开发环境”的雏形的搭建。 - 成为一个养猫好手兼优秀的铲屎官。 ## 其他 收拾工位的时候看到了之前定制的手托刻字，希望依旧能够“砥砺前行，不忘初心”。 --EOF