每份工作都有正负两面，选择它是因为被正面蒙蔽了双眼，离开是因为戴上了眼镜。
—尼古拉斯·树人·周

其实没有预想会这么早离开搜狗，但跟预期的时间也没差多少。17年初加入搜狗的计划是三年，目标是把webgl地图引擎完成上线。截止到今年5月份，进度虽然略迟于预期但还好没有到达deadline，稳步推进的话会在3季度完成第一版，4季度完成pc地图的引擎迁移，明年1季度完成开发者API，然后“功成身退”。不过现实总是喜欢用它长满肉刺和茧子的大巴掌糊人一脸QNMD理想，“意外”这个词在生活里压根不叫事儿。

虽然年前走了一人正赶上公司招聘冻结，地图前端组仅剩我和一40岁老将，但好在春节后到5月上旬的业务需求超乎意料的少，一季度几乎把所有精力都投入到了webgl地图引擎上。

首先是数据制备，地图App的二进制数据不能直接照搬到web应用中，而且有很大一部分数据web地图用不到，比如只应用于三维导航视角的市街图数据。所以第一步工作就是精简数据只留下需要的部分；第二步是制定规范并且把二进制数据转成JSON；第三步是坐标加密和体积压缩。这些工作当然最好是交给数据组去做，一方面是因为他们是数据的源头；另一方面数据转换的所有逻辑都是用Java实现。不过最终这些活还是落到了我自个身上，客观地说数据组应该是地图最忙的了，反而应用层开发的人相对清闲。并且webgl地图引擎终究是前端组推动的，也没有权利要求别的同事支持。好在数据管理的Java代码比较简单，脑子里尚存的Java知识足以应付。

数据制备完成之后开始上手写代码逻辑，然后立马遇到的从传统前端过渡到webgl开发的第一道也是最难的坎：数学和图形学。矩阵、向量、图元、三角剖分，一个个都搅得脑子变成了浆糊，头发也争先恐后噌噌往下掉。

第二道坎是性能。webgl或者说图形编程面临大数据渲染时对性能要求的苛刻程度远不是常规web项目能比的，当数据量上升到5位数甚至更高后，要实现50FPS以上的动画并不是一件很容易的事。一方面要熟知一些webgl领域专有的性能优化方式，比如尽量批量调用渲染API、少用normal多用attribute、避免或减少fragment shader计算量等等；另一方面是优化JavaScript的内存管理，比如尽量使用TypedArray、避免大容量数组重赋值等等。在这期间确实收获了很多常规前端项目中被忽略甚至用不到的经验，比如一个容量为5位数的数组的GC过程竟然能消耗掉17ms甚至更多时间，直接造成了动画掉帧和操作延迟。

第三道坎是抗锯齿。我想可能只有极少数的前端开发者会好奇为什么HTML和CSS搭配出的UI那么“圆润”，起码在我前2年多的工作中从没有想过这个问题。但用webgl画出平滑的斜线和曲线并不是一件很容易的事。以前写过SVG和Canvas，这哥俩画个圆简直不要太容易，可webgl不行。能用的只有点线(段)面，怎么才能“拼”成一个圆呢？当脱离了高层渲染技术聚焦于接近计算机图形学的底层渲染后，解决这些问题的背后都是算法。一种实现抗锯齿和绘制圆形最常用且简单的算法是distance based algorithm，基本原理是根据两点的距离算出一个透明度然后跟原始颜色混合，细节我就不说了，感兴趣的同行可以自己找找资料。

第四道坎是三维，透视矩阵简直是大自然赐予人类的艺术品。第一步是抽象相机模型，第二步是掌握Depth Test和Face Culling，最后是光照。不过地图引擎不是3D游戏，所以做到前两步和简易光照模型就可以了，泛光、环境贴图、Gamma矫正等接近物理的高级光照知识基本用不上。

现在回想起那段时间真的是辛苦但非常有成就感。不到四个月的时间，一个人从数据制备到引擎开发，从零做到三维，我都有点佩服自己。如果这个项目能如期完成应该是工作以来最有成就感的一件事。

不过很可惜，5月份这个项目被大老板一句话叫停了，我被强制拉入了另一个项目中。在此之前没有任何讨论、会议和通知，甚至我的直属领导也丝毫不知情的前提下，我们俩一脸茫然地参加了AR导航的第一次项目会议，然后被要求第二周立即产出可见的模拟仿真方案。

这不是第一次遇到一言堂，但在相对空闲且没有重要项目的情况下被拉入另一个项目其实心理上还能接受，不过这次确实有点恼火。目前看来，大老板是把AR导航当成战略性项目长期发展，这么重要的项目理论上应该提前进行功能评审以及评估是否有高度的可行性和充足的技术储备，但现实是我的直属领导身为技术总监竟然在此之前毫不知情。我俩还屁颠屁颠地推进webgl地图引擎，畅想着上线后的美好前景呢。

一开始以为AR导航仿真系统也只不过是个短期项目，顶多一个月就完成了，这样的项目在2年多的时间里做过好几个，不足为奇。不过这回碰上了硬茬，截止到今天还在迭代，而且是每周都改，上周讨论的方案刚做完这周就被否决重新做。我不是说这种事情不好，客观地说处于探索期的项目需求变动频繁很正常，开发者也理所当然地要接受。这个项目之所以成为离开搜狗的导火索是因为我看不到尽头，这个项目最起码今年剩余的时间都会是核心，根本没有时间投入到webgl地图引擎上。一个进行了80%的项目如果间隔一年再拾起来的话几乎等同于重新开始，况且这个项目不论是从技术储备还是实践都是接近从零开始的状态，我不知道一年后留在我脑子里的知识是否能够立即兑现。原定三年的计划从第一次AR导航项目会议开始便等于被判告吹了。

判断一份工作是否合适最主要的是看它是否能够提供你现阶段最需要的东西，这一向是我个人认为换工作的根本出发点。当时选择搜狗地图不是因为搜狗，不是因为地图，也不是因为钱，而是因为webgl。说实话我对webgis一点兴趣都没有，我知道搜狗地图能够提供给我从零开始做一款webgl引擎的机会，这才是这份工作最大的吸引力。我对自己的职业规划是前五年用来完善技能栈，5年之后选择一个垂直技术领域深耕，幸运的话还可能遇上一个有前景的行业方向。所以加入搜狗地图才制定了三年规划。有了目标做支撑，其他的事情都相对不那么重要了。从17年初到现在的2年多时间内，小到只有一张图片的运营活动，大到SVG地铁图的彻底重构，只要能够有助于技术成长都可接受。2019年之前的2年，用碎片时间做webgl技术储备，最长的连续投入到webgl上的时间不超过2周。这些行为的背后都是因为内心有目标支撑。然而当三年规划被判死刑之后心里的这股劲立马就没了。5月份的时候也尝试过跟老板争取恢复组内空缺岗位的招聘，无果，直到6月底Android组走了一人之后才被告知招聘早已解冻，具体为啥不主动通知我也不知道。

离开之前回顾这2年半的经历，这份工作除了不加班以外从各个角度上都很难称得上一个好字。尤其是想有一番作为的人来说，前端组的前途更加无望。在搜狗属于倒数第一第二的地图部门，地图业务的重心在于手机app和车机，前端的定位本身就处于边缘。只做支撑没有重点项目意味着很难拿到绩效高分，晋升更不用提，所以组里40岁的老哥在地图呆了15年仍然是3.2丝毫都不意外。虽然加入搜狗是为了技术成长，但人心肉长难免也会为工作以外的事情揪心。所以也是尽可能地不放过任何可能做出成绩的机会。2018年中，搜狗地铁图最初的需求只是美化UI和优化动画，后来经推动把搜索、求路、切换城市等除了导航以外的所有功能都迁移到web，从原本的一张svg图片变成了一个功能全面的webapp。上线6个月用户的负面反馈减少了90%，pv/uv增长了近20%，与之成反差的是搜狗地图的用户总量在2018年下降了近5个点。但由于地铁图体量太小，不足以参选牛奖（搜狗内部的精英项目奖）。后来在此基础上又推动了PC地铁图的重构，是搜狗地图PC端业务5年以来最大的一次更新。除此以外，借详情页重构的机会抽离Vue组件库、借地铁图重构搭建地铁数据制备和离线包版本管理平台等等，无一不是技术推动的案例。然而这样的机会能有多少呢？跟核心业务的客户端和数据组比起来简直不值一提。晋升的难易度在核心与非核心业务部门之间的差距我相信工作时间久的朋友都深有感受，所以在搜狗见到不懂cookie子域名跨域的T6“前端架构师”一点都不奇怪。

倒了一肚子苦水，总的来说在搜狗的2年半虽不完美但基本得到了我想要的技术成长，只不过没有可见的上线项目确实很遗憾。幸运的是，下一份工作既能够在某个垂直技术方向深耕，又是一个非常有前景的行业方向，希望下个5年有所作为。