一个 32 岁「老」码农的复盘：崭露头角
欧雷 发表于
在本系列上篇文章《一个 32 岁「老」码农的复盘：初出茅庐》中讲述了我通过两段共计三年左右的工作经历入了行，大致了解了「前端工程师」这个职业以及软件开发行业的大概面貌。虽然我自身的问题占了一部分原因，但我认为它们在一定程度上限制了我的成长速度——
选择到什么样的公司去工作是一件需要万分谨慎的事情。进错公司毁一生，我不是在开玩笑！不要小看人性的弱点和环境的作用。
在本文所述说的工作经历中，随着工作环境的改善，我也开始有所转变——
刺暮软件
2013 年 3 月下旬，我入职了一家「做软件」的公司。之所以用「做软件」这个词，是因为这家公司的构成和关系略微复杂，且听我慢慢道来——
我签合同的公司是「刺暮软件」，公司的业务是做一些外包性质的移动端应用。然而它并不是外包公司，应该是为了存活的临时业务。这家公司的创始团队皆来自 2K 中国，即 2K 的中国分公司。
在发展的过程中，又成立了两个「子公司」，分别是做在线教育的「有渔教育」和做游戏的「黑火游戏」。虽然我的合同是签在「刺暮软件」，但做的事情由始至终都是一个叫「有渔」的在线教育平台。黑火游戏的代表作有《符石守护者》和《元能失控》（这个游戏的制作者变成了「火花工作室」，但人是同一拨人）。
另外，不知为何，刺暮与杉果游戏也有所关联……
我所参与的在线教育项目，起初是面向中、小学的翻转课堂，以「贴牌」的形式给杭州本地的学校定制系统，如：杭州市采荷实验学校、杭州第十四中学；后来以 SaaS 形式走平台化路线，就变成了「有渔」，它的功能是围绕着「课程」来展开的，除了课程，有任务、习题、问答、组织和社交等功能模块——
「有渔」是以国际化视野打造的翻转式学校，提供英语、创意计算、机器人等国际先进课程的翻转课堂教学服务，以及「翻转课堂」、「黑板报」等云端软件服务。
作为最新一代网络教学系统，「有渔・翻转课堂」融合了 MOOC（大规模在线公开课平台）、SNS（社交网络）、游戏化教学、数据化分析、百科等先进教育理念，通过 SaaS（软件服务）模式构建，旨在打造中国「翻转课堂」第一平台，为学校、企业、名师、个人等提供人性化、信息化和定制化的教学云服务。「有渔・翻转课堂」始终本着「让教者乐其教，让学者乐其学」的服务宗旨，从教、学、监三个方面综合设计，着意教学管理与学习交流相结合，立足三大角色，开创五大功能，兼摄四大优势，主张开放思维、自主教学、互促互进，最终实现和衷共济、教学相长的数字化创新教育。
平台的用户分为「学员」和「教师」两种身份，前台页面都能访问且没有差别，后台页面根据身份的不同会有所区别：学员是查看自己在学习的课程、在做的任务、错题集、参与的问答、加入的组织和好友列表等；而老师则是进行课程、习题、任务等的管理。该平台除了 PC 端 web 页面，还有 iPad 客户端。
由于这里采用的 web 框架是 Ruby on Rails（下文简称「rails」），所以前端方面的技术选型也是以与其结合较好的为优先，如：CoffeeScript、Sass、Compass。rails 不了解倒无所谓，但无论是 CoffeeScript 还是 Sass、Compass，都是之前听都没听过的，需要从头学起……
虽然产品线相对单一，功能没有十分复杂，但毕竟算是个互联网产品。并且当时 AngularJS、React、Vue 在国内还没火起来（我刚到这家公司时 React 和 Vue 还没问世），复杂应用框架主要是 Backbone 比较有名，jQuery 依然占有很重要的地位。
在这期间，结合工作实践，我造了好几个轮子（玩具），基本是用 CoffeeScript 和 Sass 写的：
| 名称 | 说明 |
|---|---|
| Painter（现在叫「Trick」） | 工具类 Sass mixin 库 |
| Tangram | 布局类 Sass mixin 库 |
| Ronin | DOM 无关的 JavaScript 解决方案、增强库 |
| Miso | 用于对 JavaScript Plain Object 的每个成员函数的实参（arguments）进行合法性校验以及统一返回值（return value）的「批处理器」 |
| Tatami | JavaScript 工具库（乞丐版框架？） |
| Matcha | 一个 UI 库，包含了 Painter、Tangram 和 Miso |
| Video.js Progress | 基于 Video.js 的进度条增强插件 |
| Video.js Track | 基于 Video.js 的文本轨增强插件 |
| jQuery Cascading Tabs | 基于 jQuery 和 Matcha 的级联选项卡组件 |
| jQuery Pagination | 基于 jQuery 和 Matcha 的翻页组件 |
| jQuery Double-list | 基于 jQuery 的双列表（穿梭框）组件 |
| H5Fx | 基于 jQuery 和 HTML Forms 规范的表单校验插件 |
虽然这些库绝大部分已经不再维护了，但它们的变体和还在维护的库在之后乃至未来的我所参与的项目中继续产生价值。
随着业务需求的不断增加，页面变得越来越多，资源文件也变得越来越大，导致页面加载速度不断下降，加速页面呈现成为刻不容缓的事情。于是，决定通过 Turbolinks 将网站变成单页面应用来减少资源文件的请求。
需要说明的是，用 Turbolinks 实现的单页面应用与现在大家所熟知的方案有所不同，它完全是运行时的方案：在点击下一个页面的链接时，会先判断那个页面有没有已经在内存中进行缓存，如果有就直接拿来替换掉当前页面 <body> 中的内容，没有就会通过 AJAX 拿到页面内容缓存后替换；在请求页面内容阶段，页面顶部会有一个很细的加载进度条；默认最多只能缓存 10 张页面的内容。
项目的运行是基于我写的 Tatami，各种初始化逻辑是依赖于原生的页面生命周期事件，在引入 Turbolinks 之后破坏了原有的「生态平衡」，它改变了页面的生命周期，因而引起了一些较为棘手的问题： UI 初始化异常、事件绑定及触发异常等。
经过几天的调查研究，最后写了个适配器通过修改 Node.prototype 的方法（method）解决了 <script> 加载依赖问题；通过在脚本中记录页面初始化函数所对应的页面标识及顺序，解决了初始化异常和事件异常的问题。
为了提高协作效率，降低沟通成本，与交互设计师和 UI 设计师合作整理制定出一份交流用的 UI 文档，使用 Jekyll 在 GitHub 上搭建了在线浏览的页面。这个文档的作用主要有两个：像 Google 的 Material Design 那样是一套设计规范，设计师在设计新页面及做标注时要参考；像 API 文档那样，告诉开发人员如何去使用。
由于应用的复杂度渐渐提高了，又引入了 Backbone 及其周边的 Marionette、Backgrid 和 ModelBinder 等。不过，与此相关的事情主要是另外一个同事（ヘンタイ）在做，我没太参与。
在我刚去这家公司时，开发相关人员总共 10 个人左右，做在线教育和做游戏的人数基本对半，当时专职做前端的就我一个。大概一年之后，做在线教育的开发人员多了起来：一个可做前端可做 rails 开发的（ヘンタイ）、一个专职前端、一个质量保障（QA）、两个 iOS 开发。原本只有一个 UI 设计师，后来又来了一个，并且又多了一个交互设计师（目前为止的职业生涯中接触的唯一一个）。
在这里，记忆中任务管理工具换了两次：从 Trello 换到 Tower，再换到 Teambition；代码管理是基于 Git Flow 使用 Sourcetree 与 GitLab 相结合。每天早上会围在团队总负责人身后站会，按照任务看板的顺序需要相应的负责人阐述任务相关情况，完成了则更新任务状态并分配新的任务。培训与分享虽然不多，但有时也有。
总体来说，这家公司的福利，除了「玛尼」相关的没啥缺点，与我服务过的其他公司相比反而有亮点：没有加班；带薪年假 10 天起，每满一年加一天！即使它如此让人自由，如此 work-life balance，最终我还是因为它的发展前景和「玛尼」的问题选择了离开……
为什么这家公司在「玛尼」上有比较严重的问题？我想可能是因为老板很理想主义，很有情怀，想慢慢打磨产品，不愿去找投资人进行融资。也许正因如此，才会给员工提供 work-life balance 的工作环境，让员工倍感自由。
在我离开之后，陆陆续续有其他人因为同样的问题而离开，做游戏的那些人「打包」换了个地方，以「火花工作室」的名义继续做游戏。
回过头来看，我很感谢在这里的工作经历，不仅提供了很有亮点的福利，在这里所养成的工作习惯对我之后的职业生涯很有影响。更为重要的是，在这里遇到并交到了女朋友，在后来成为了我的妻子。
买/卖好车
2015 年 9 月中旬，我入职了一家汽车领域的公司。在我任职期间它发生过转型——从自己卖车的「买好车」变成帮别人卖车的「卖好车」，因此会以「买/卖好车」来指代它。
刚入职时，我给自己在这家公司中的定位是担当团队中一个重要的角色，不是 leader，而是帮助团队提高生产力，引领并提高整体水平的存在。事实证明我在一定程度上做到了，自己还算满意。
在这家公司所取得的工作成果在《在「MHC」我都做了什么？》中已经较为全面地阐述了，这里就不再赘述。不过，正如文中所说——
本文着重介绍了在「MHC」时，除了日常的业务开发之外我都做了哪些事情。所列举的都是些对前端团队、对技术部、对公司业务或多或少有影响的事例，做到一半或做失败的事情也不太好意思拿出来说。
即便如此，有一个「做到一半」的项目还是要提一下的，那就是「开发资源中心」，内部代号「JCW」（MINI 顶配车型的名字）！在我心中，它是很有分量很有意义的一个项目，没做完是因为我离职了。下面就来说说它的分量和意义体现在哪——
很明显，这是一个内部的管理系统。正如它的名字「开发资源中心」所示，是对开发相关资源进行管理的，以提高协作及开发效率。其所包含的功能大概有（有的是当时规划中的）：编辑与查看数据接口文档（有点类似 Swagger 生成的 API 文档），并可根据 API 描述 mock 数据；查看与管理（上传、删除等）已上传到 OSS 的静态资源文件；前台应用（单页面应用）的发布与版本管理；后台应用（传统多页面应用）前端数据的发布与版本管理。
其他的就不展开说了，但后台应用前端数据的发布与版本管理这个要特意说下，因为它是一个根据当时的规划会做成可视化搭建的功能——
后台系统页面的常见模式就是供数据 CRUD 的列表页、表单页和详情页，当把支撑这些场景的交互和数据处理的核心逻辑都已经抽象了之后，你发现再怎么完善 UI 框架也不会有像之前那样比较明显的效率提升，顶多是优化了交互和开发体验，使功能更稳定而已。
你陷入了思考：「该做些什么才能继续为开发提效呢？」
之前做的 UI 框架，是对交互逻辑和数据逻辑进行了高度封装，并提供了大量的 CSS class 和工具方法。虽然使在做页面时可以少写很多 CSS 和 JS 代码，但对于 HTML 代码来说并没有减少。
貌似找到了该突破的点，但要怎么去做呢？
左思右想，你突然灵光乍现，想起了自己曾经用过的基于「世界上最好的语言」开发的博客系统——WordPress。既然后台系统页面如此模式化，何不效仿 WordPress 将不易变的部分作为「主题」，易变的部分作为「文章」？
这样做会带来另外一个好处，就是将页面代码数据化了，有什么纯前端的问题修改就只是数据修正，而不用走冗长繁杂的运维发布流程。日后如果公司有了自己的设计语言，再加入可视化搭建的特性，业务后台系统的开发和维护前端就不太用参与了！
理想情况下，产品经理用已有物料拖拖拽拽生成「原型」，该「原型」就是最终界面；业务功能确定后，后端开发定模型、写接口，然后配置界面的数据展示。这样一来，业务系统迭代的整个过程中，基本可以忽略前端这个角色了。
那么前端干什么呢？在这样的协作模式下，前端的主要工作就是完善物料库，并且让产品经理和后端开发使用起来更方便。这种提效方式所带来的收益，与开发 UI 框架相比，根本不是一个层次的，想想都觉得兴奋！
上面说的是「开发资源中心」在业务与协作层面的意义，在开发层面它也有着重大意义！
它是一个基于 Node.js 的前、后端一体的项目，虽然在此之前也有用 Node.js 开发的前、后端一体的项目，但它们都是基于 Express 用 JavaScript 写的；而这个项目为了成为公司内这类基于 Node.js 的前、后端一体的项目的标杆，选择了 Nest 作为 web 框架，并用 TypeScript 进行编写。
当时还正与设计团队合作弄公司的设计语言，并计划接下来一起搞图标库，最终皆因离职了而没见到结果……
下面就大概介绍下在《在「MHC」我都做了什么？》中基本没说的我在职期间买/卖好车的业务以及我的一些体验——
正如上面所说，在我任职期间公司经历过转型。然而，据我所知，在我入职之前，公司成立初期还做过另外一个业务，好像是跟车有关的像百度贴吧那样可以发帖子的社交产品。由于对那段历史不怎么了解，还是说说我所了解的「买/卖好车」吧。
2015 年，创业圈子中诞生了一个 to C 的平行进口车电商平台——「买好车」。所要做的事情很简单，就是「只要你有钱，只要车的方向盘在左边，要啥车都能想办法给你弄到」。
这时的业务很单一，所需要的应用也很少，基本就是一个面向用户的主站，一个内部管理用的后台系统，还有 iOS 和 Android 客户端。其中，客户端从架构上来看可以说是很简陋了，就是移动端 web 页面套了原生客户端的外壳。
主站页面的设计还是不错的，毕竟无论是当时还是现在，都有好几个在设计上进行山寨的网站，有的也是卖车的，有的是卖表的。 然而前端技术如何，相信看过《在「MHC」我都做了什么？》之后心中已经有数。
在这期间，基本每周都有一、两个活动，写活动页面成了我主要的工作，偶尔会被分配到主站或后台系统功能修改的任务。
印象最为深刻的是那年「双十一」，做一个秒杀进口车的活动。这个项目的整个生命周期并没多长时间，甚至让我觉得有些仓促。活动前一天加班工作到第二天凌晨 4 点多，回去才睡没多久，就又起来赶在上午 9 点前到公司，直到活动开始前一刻还在修 bug……
在这一时期，公司还做了一个 P2P 产品，是移动端 web 页面，这只是一个尝试性的小项目，并没有太做宣传。记得在这个产品上投资的内部员工还不少，我穷逼一个，就没为公司的金融事业做出啥贡献。
大概是 2016 年年初，随着据说是从「汽车之家」出来的阿贵的到来，公司逐渐进入转型期。
一开始，我被「抓」到还没正式成为办公区的三楼的小屋里，成为「Project X」的一员。这名字听着挺有神秘感，也给人一种「被选中」了的感觉……这个小组的任务就是快速完成创新项目并快速试错。貌似当时只做了一个项目，是个叫「寻好车」的车源线索工具。
后来，公司正式转型为帮助中小汽车经销商卖车的 to B 的「卖好车」，并先后发展出交易、金融、仓储、物流等几条业务线。
起初「卖好车」只是一个让商家发布车源信息的工具，跟「寻好车」有所相似。产品形态上分为移动客户端和 PC 端 web 应用两部分。这回客户端是实打实的原生开发，基本只有营销类页面是内嵌网页，而不像「买好车」和「寻好车」客户端那么虚。
针对商家在销售时没有一个很好的方式对客户进行管理，推出了 DMS 工具来帮助商家的销售人员管理及回访客户。
发布车源是商家告诉别人自己有什么车，想要找自己需要的车得搜索，然后挨个结果去看去筛选，这样显然会效率比较低。为了提高找车的效率，加入了寻车功能。别看见「寻车」这俩字就以为和「寻好车」有什么关系，think too much！这个功能就像是「寻人启事」一样，发布信息后分享到微信群或朋友圈，有相关车源的人看到后会主动联系寻找车源的人，在一定程度上提高了商家找车的效率。
至此，「卖好车」所具备的功能都是些与撮合商家交易相关的。无论是车源的发布和查找还是客户关系的维护，除了口碑，没看出公司在金钱上有什么收益。不过，也许先积累口碑从而吸引更多的商家来使用「卖好车」，再提供其他产品服务来赢取收益正是公司的策略。
之后，正如我所猜想，公司在汽车流通的各个环节布局，并推出相应的收费服务——
商家在采购一批新车时，很有可能手里钱不够，怎么办？找银行？需要一大堆材料，填完提交了还未必能审批下来；就算审批通过了，额度可能又不够。在这个环节，公司提供了一个可以用更少材料、更短流程申请下更多额度钱款的金融服务，通过收取手续费、利息等费用作为收益。
等车采购回来了，可店小，没地方停车，怎么办？不用愁！公司通过自建和合作等方式建立了一些仓库提供仓储服务，只要找个附近的仓库付场地费、看管费等费用，想停多久就停多久。
就连车辆的运输都进行了管控，尽可能做到能够在线查询车到哪了，运输路线是什么样的。就好像运普通货物的顺丰等快递公司一样。
对于用户来说，产品只有「卖好车」这个客户端，但在背后，有十多个后台系统和几个钉钉微应用对其产生的订单、运单等信息进行处理。研发团队的大部分人的日常工作就是开发并维护这些后台系统和钉钉微应用的功能。
我是这家公司的第 148 号员工，在将近三年的时间里，我的成长还是挺多的，各方面有了较大的转变：第一次有了时常交流的团队，做过几次分享，也培训过新人；有很多挑战，有很多想法，有的实现了，有的没来得及实现；基于实践做了几个开源项目，写了好几篇文章；不仅 push 自己做事，也开始 push 别人做事，并且尝试承担一些规划、管理工作。
开始的一年半左右时间，我主要在一线做业务，就是常规的产品经理提需求，然后各种评审，开发后测试并上线。后来我逐渐转去做基建，当时将近 20 人的大前端团队就我一个人是专门做这个，其他人还是主要做业务，有的人在兼顾业务的同时做些基建方面的事情。
为什么我会被「特殊对待」？我想可能是因为平时主要是我在推进基建、提效方面的工作，这是大家有目共睹的，我表现出强烈的想在这方面出力的意愿；另外应该是，公司业务在快速发展，有点意识到光堆人力是不够的，需要有人在提效方面有所作为。虽然是专门做基建了，但有些「老板需求」与做业务的人手不够时，我还是得去支持。
在 2016 年夏天的某次前端团队周会上我提议用 Teambition，一是方便管理和分配任务，让团队管理更高效些；二是每个人都可以知道其他人在做些什么，使相互之间信息透明。虽然当时大家都觉得可以试下，但实际用起来后任务状态更新并不积极。甚至有段时间我常常早、晚在群里提醒大家更新任务状态，只可惜收效甚微，渐渐不了了之。
大概一、两年后，技术部对项目管理开始重视起来，不知为啥引入了 Worktile……如果我事先知道的话，肯定会推荐一波 Teambition！用过 Worktile 后，我觉得没有 Teambition 好用。
在任职期间，跟产品经理撕过逼，主要是因为交互或者布局要求不合理甚至反人类；也会怼后端开发，主要是由于他们的能力问题影响到了协作关系；与前端团队中的一个人有过争执，主要是因为他太缺乏常识，对大家都认可的团队规范有很多疑问；带过一个师妹，有段时间因为她问题太多，总是打断我的正常工作而显得不耐烦。
一个巴掌拍不响。说了那么多他人的原因，我就没问题吗？当然不是。我最大的问题就是——因为对自己要求高，所以对别人要求也有些苛刻；因为以往基本都是靠自己去解决问题，尽可能少地去麻烦别人，所以也希望别人能够尽量独立解决问题，尤其是协作需要尽可能高效。总而言之，就是要求别人像要求自己一样，但是往往他们做不到。另外就是，我耐心不够，容易急躁。
这家公司的福利与安恒差不多，加班没那么狠，就是互联网公司比较常规的状态——进入测试阶段之后，特别是快到上线前的那段时间，需要加班。并且，很可能在发布成功时，已经凌晨两、三点了。
总结
这个阶段，是我作为一名「前端工程师」与「作家」开始「觉醒」的阶段。不像上个阶段中的公司，本阶段的都可以说是互联网企业，并且做的事情更有挑战，可做的事情更多。
也许是因为我已经过了入门的阶段，再加上我本身就是一个喜欢「挑刺儿」并各种「瞎想」的人，总是能从日常工作中发现问题并想办法去解决它们；所以才会造了那么多轮子（玩具），做了那些基础设施建设方面的事情。
在刺暮时，由于业余时间很多，并且那会儿比较浪，总是会在杭州市内或江浙沪地区之内游荡。那时还做了一个名为「暴走杭州」的计划：
这期间也参加了几次技术类线下活动，如：第八届 D2 论坛、在百姓网与一号店举办的交流活动。其中，在百姓网的那次是小鱼（sofish）组织的，见到了简书的创始人和张鑫旭。张鑫旭在分享时的语言风格就跟他的文章一样。
去了买/卖好车之后，我不太浪了，就连很喜欢的动漫和游戏都不怎么碰了……平时下班后基本都是在住处继续「加班」，去完善并优化我所维护的基础设施。思考人生神马的，西奈吧！
在买/卖好车的中、后期，因工作中遇到的各种问题而相继产生了两个较大的靠一己之力无法完成的计划，它们分别是「前端知识与技能考核评价体系（Front-end Knowledge & Skill Evaluating System）」和「反混沌（Anti-chaos）」。
