一
我在大四的时候就进入上家公司实习，毕业后和整个团队都比较契合就顺理成章地转正安心做个打工仔了。但毕竟靠公司内部的晋升和薪资调整很难赶上市场的薪资水平，加上公司业务没起色年终奖一年比一年少，因此呆了三年到20年就决定跳槽了。
二
正如大家知道的，20年开年就不太顺利。
因为疫情的影响许多公司都延迟开工，我们也是开启了远程办公。那确实是职业生涯中非常难忘的一段时间，远程办公既能打工赚钱，又能陪伴着家人。加之做了跳槽的打算，就正好借着下班之后时间比较多开始系统地回顾前端的知识。
3年经验肯定会定级到高级开发。高级开发就不仅仅需要前端的基础知识、能胜任业务需求，对技术原理和项目的思考都会有考察。为了应对面试就免不了刷题背八股文，我采取的方法是技术社区找几篇面经，把面经中的考察点整理出来，再在技术社区中搜索相应考察点的文章，这样就可以比较深入地学习该考察点的内容。
疫情时的就业环境确实非常差，岗位少，好的岗位更少，比较知名的公司都在冻结甚至缩减HC，和今年(21年)的招聘情况比起来完全是天壤之别——今年各个公司包括我们都开启了内推激励政策，人员需求非常大。那种情况下我投出的简历就比较少，收到的面试就更少了，整个跳槽过程中就收到了6个面试。但我感觉那套学习方法用来应试是比较有效的，因为从面试结果来看6个面试中有5家公司发出了offer了，剩下那家也是最后面试的一家也没被卡在技术面试上。
站在现在的时间结点来看去年的那次跳槽，确实是太艰难也太勉强了：就业环境差，大家都在一个缩量的市场中竞争，用人单位也是各种压工资；这种情况下甚至碰到了用人单位对我非常满意，把我作为第一候选人但就是不乐意给到期望的薪资(当时期望的薪资还是比较低的，用人单位完全给得出来的那种)，实在没有更优的候选人给我调了两次薪资。
最终我在仅有的几个offer中权衡了一下选择了现在的公司，一方面因为公司规模和知名度确实是相对最高的，另一方面是薪资给到了超出期望(后来才发现是定级比我预计的高了一小档，哪怕超出期望也只是那一档的最低薪资标准🙄)。
无论如何20年的那次跳槽都得到了一个不错的结果，继续前行也更有动力了。
三
刚入职时压力确实还比较大的，毕竟拿到了期望的薪资得干出相应的活。
这个阶段可以说是在问题排查方面成长最快的一段时间：领导有时候会给过来一些比较怪异的生产问题，自己在开发过程中也会碰到各种奇奇怪怪的问题，刚入职又害怕解决不了问题被质疑能力有问题，只能硬着头皮去啃这些问题。偶尔就代码看着看着眼眶一红——钱实在是太难赚了点。
这些工作内容和我之前的工作差别还是比较大的，之前都是只顾着接业务需求写业务代码，出了疑难问题都会有经验更深的开发去排查，自己碰到问题更多的也是直接去问大佬而不是自己排查。其实之前的领导就有说过希望能有独立排查问题的能力，但当时一直没法理解什么叫“独立排查问题的能力”：业务代码都有固定的范式，少数的疑难问题都有大佬去解决，自己不用怎么动脑子就能做好需求支撑。想来这也算是自己在那时碰到的一个瓶颈吧，很幸运地在跳槽之后机缘巧合一般突破了它。
3~5年开发经验的工程师在大部分团队都是中坚力量了，资历稍浅的可能还在和业务需求斗争，更资深的可能转向了团队管理岗。因此工作中出现的难题都会流到这个阶段的开发人员手中，具备一定的问题排查能力也是保持开发能力、向上继续突破的一个基础。
四
随着工作的进行，工作内容也不仅仅局限在支撑常规业务需求和问题排查上。
我们每个双月都会制定一定的技术目标去达成。本身技术目标的制定就不是一件容易的事：这个目标需要能对业务产生一定价值，同时对开发人员又有一定的挑战，通过完成技术目标能达到技术上的提升。对业务能直接产生价值的事项一般都会通过产品需求的方式来完成，所以我们的技术目标大体都是围绕着各项优化提效来进行的，比如性能优化、工程优化、工具搭建等。
基于这么一个制定目标的套路，在过去一年完成了日PV百万级的落地页的首屏加载优化，规范了集团内部使用的埋点规范并开发了一套简洁易用的工具库用于快速完成业务埋点的发送，对日PV千万级的前置页中使用到的弹层SDK进行拓展，使之支持更多业务场景。
五
因为处在广告行业的原因，我们的一些页面动辄就是百万甚至千万级的访问量。正如之前文章提到的，在一次系统优化中，我们针对特定品类创建的落地页丢失了一个表单字段，导致两个小时产生了两万多的资损。加之最近事故频发，让我开始思考工作中另一块非常重要的事项：风险控制。
在今年之前我从没花这么多精力去考虑风险控制的事，一方面因为上一家公司业务量不大，出了问题也没啥影响，等有人发现了修复就可以；另一方面则是之前一直狗屎运比较好，没整出什么线上故障——在没有刻意去做风险控制之前没出事故确实只能说运气好没踩到雷。而当面对着百万级的流量时，代码中留下的任何一个坑都可能被大量的用户触发导致资损，比如之前做首屏优化时后端报空指针错误，比如做页面数据合并时新老数据合并逻辑，比如页面样式兼容性导致表单项展示不完全等。这些都是非常低级的错误，并不是超出技术能力导致的问题，更多地是在出技术方案和开发阶段能否意识到风险的存在并进行规避。
能有风险意识本身就是不是件容易的事，常见的比如在访问对象属性做保护或者调用方法时做判断避免代码报错，更麻烦的是在进行系统层面优化或重构时完整地评估代码的风险点并提供准确的影响面给测试进行回归，而不是做完一次大的重构之后和测试说整个页面都需要回归一遍/把系统功能回归一遍就可以。在实际开发中面对系统层面改动时我往往是做不到这一步的，因此会采用更为保守的方案：尽可能使用增量的功能来替代对老逻辑的改动。
六
除了编码方面工作，在工作中我们还需要为业务方提供各种奇奇怪怪的技术方案。这些方案虽然最后还是会反应在编码工作上，但它在编码上其实没什么困难，难度更多地体现在如何出技术/对接方案来为业务的推进提供最快速、方便的支持以及为后续可能的业务开展提供一定拓展性。
我们作为广告平台，经常需要把自己落地页和广告媒体、广告主进行对接。在这个对接过程中出了各种骚操作来达到既能将自己的页面投放出去拿到业务数据，又能完成媒体、广告主本身页面需要进行投放的目的；用的最多的便是各种iframe嵌套——我们的落地页嵌广告主的表单；媒体落地页嵌我们的落地页；媒体落地页嵌我们落地页作为背景，在背景上盖自己的业务逻辑，在自己的业务逻辑上又盖一层iframe加载我们的弹层等等各种千奇百怪的对接方案。
再比如为了达到快速开发动效的目的，我们在现有的建站系统上又增加了SVGA支持，只要设计导出一份SVGA文件，设定好特定的几个事件帧便能完成复杂动效的开发。
我把这块工作归类为“业务支撑”，它是体现在编码工作中、超出技术与编码的工作。这部分的工作虽然不如技术任务那样能直接提升技术水平，但却是对工作所处行业的一个积累。
七
回到主题，业务需求之外可以做哪些更多的事？
- 问题排查：解决已经出现的疑难杂症
- 风险控制：避免可能出现的线上问题
- 性能优化：提供更优质的代码和更好的页面体验
- 团队基建：提升团队的开发效率
- 业务支撑：从技术侧推动业务的进行
我归纳了这5点，之后的文章也会围绕这5点进行。