2022 年年初做了一份年度计划，给自己列了 13 条今年完成的事情，除了 1 条完全没有启动之外，其余 12 条或完成，或还在进行中。
给自己还定了 5 个核心目标，除了个别需要与其他组协调的任务进度缓慢之外，大部分完成的还是蛮顺利的。
下面的思维图列举出了今年做的一些比较重要的事情。
与 2021 年从 0-1 时的年终总结略有不同，今年就是在干 4 件事：知识沉淀、提效保质、体验优化和研发标准。
一、知识沉淀
知识沉淀就是将有效信息记录在案，这个在去年就已经提出了，今年是持续精进。
今年不仅自己在维护文档，而且还让组内的成员也一起参与，让他们也能自觉地补充更多的文档。
最近还学到了个新名词：活文档，就是将记录写在事物本身中，例如代码中的注释、版本提交时的 message 等。
我们组今年也在进一步规范这类活文档，减少信息障碍。
5月中旬，公司将之前存放在 wiki 中的文档整体迁移至飞书文档中，我对整体的目录也做了一次细致的归类，便于查看。
改成飞书后，有个很大的好处，就是可以直接用手机浏览文档了，文档格式也比之前的 confluence 美观。
1）工作文档
工作文档包括项目文档、周会记录等。
项目文档，是在去年的基础上，持续补充各类信息，例如项目中遇到的难点，新项目的文档说明等。
还有对之前写的比较模糊的资料，做了一次详细的补充，使文档更有用。
周会之前只是简单的罗列工作记录，今年制作了几张较为完整的表格，分门别类的记录各种工作内容，并且会附上状态和风险等内容。
2）计划规范
今年补充了几个比较大的计划，例如北极星指标、项目迁移、性能优化、年度计划等。
北极星指标会在后文中详细说明，项目迁移就是 Node 服务迁移至 Go，jQuery 迁移至 Vue 等。
性能优化记录了今年的一些优化手段，例如操作日志表优化、导出优化、缓存图像资源等。
今年一个比较重要的规范是通用组件的默认功能和交互，公司的大部分活动都是基于这些组件研发的。
在规范之后，就能大大 QA 在测试时的返工，很多时候一些细节就会纠缠很久。
例如点击封禁账号后，有时候表现会与之前 QA 所想的不同，那么此时她就要与产品和开发核对。
3）技术分享
技术分享在去年也提出过，并且还制订了相应的规范，但是由于是针对技术部所有人的，所以组织一次的周期会比较久。
并且参与积极度也不是很高，所以今年 2 月份的时候就调整成全公司的人都可参与，但是参与度仍旧低迷。
再加上三月到六月，整体居家办公，更不能举报全公司的分享会了。所以 3 月份再做一次调整，改成团队内的分享。
每个人都会轮到，一周一个，技术范围不限制，这次大家都能参与进来，已经进行了 34 场，每场结束后，都会将内容留档。
大家对此类技术分享并不排斥，都会积极准备，大部分是源码分析和案例分享。
4）Code Review
5 月份的时候发生了几场事故，问题虽然低级，但造成的危害却不小，如何有效的进行规避，在当时我进行了思考。
我想到的一点就是 Code Review，大家坐下来，一起检查下代码的写法，一起判断业务逻辑是否合理，很容易就能发现那几个事故中的问题。
今年不定期的举办了 15 场 Code Review，发现了很多问题，例如逻辑错误、理解误差、写法优化等。
还有很重要的一个举措就是推广代码注释，成员们普遍对注释比较吝啬，你自己显而易见的写法，别人可能难以理解。
况且好记性不如烂笔头，注释也能帮助自己理解比较复杂的代码。
二、提效保质
在提升效率的同时，保障项目质量，鱼和熊掌不可兼得，是我今年重点在推进的事情。
在补充人手后，我能有更多的时间抓工具化和流程化的事情。
1）工具化
要想提效，就需要有趁手的工具，今年在去年的基础上，又增加和优化了多种工具。
BFF 平台在去年就研发完成了，不过在组内并没有马上推广开来，直到今年年初，才陆陆续续开始使用。
目前新的业务接口基本都会走此平台，线上已有 70 多个接口在稳定运行着。
榜单活动配置化是将常用的活动做成可视化配置的形式，目的是减少开发和测试人力，将 2 天的研发时间压缩至 2 小时。
这个配置协调了 UI 组、产品组、测试组、前端组、数据组一起，制订出了相关规范，已成功运营了 5 场活动。
为了提升管理后台的开发效率，先后研发了后台编辑器第一版和第二版，第一版组员接受度并不理想，第二版已经上线了两个菜单。
组内成员配合运维组，研发了IP白名单管理，帮助在家办公的同事，可以访问公司内网，降低了进内网的门槛。
为了规范代码编辑，引入了 ESLint，对冗余代码和会存在隐患的代码进行标注，帮助我们写出更健壮的代码。
开发了一款 VSCode 智能索引插件，因为框架写法的原因，使得路由层的代码不能自动跳转到服务层，因此写了插件扩展功能。
2）流程优化
管理后台静态页面的项目发布一直被诟病，因为发布速度太慢了，今年和运维联手，从 12 分钟降低到 5 分 30 秒。
解决了我们组的心腹大患，终于可以愉快的发布项目了，再也不用干等了。
组内的另一个成员让测试环境可以自动被发布，只要将代码合并到测试分支，就能进行发布流程，非常方便。
在发布流水线中，增加核心服务的单元测试，避免线上再出现服务不能访问的重大问题。
3）前端监控
前端监控系统在去年完成了 0 到 1 的第一步，今年每个月其实都在做维护和优化，目标是让此系统更好用，而不是一个花瓶，具体优化可参考此处。
今年帮助我们解决了不少线上问题，有的是主动发现，有的是用户上报后，借助该系统将问题定位。
不定期的维护包括查询条件增加时间快捷键，过滤第三方库的通信，活动页面的通信中增加userId，优化LCP的采样时机，白屏的计算，监控静态资源的请求错误等。
前端的监控日志为了能与服务端日志相关联，特地在通信时增加全链路日志唯一标识，不再让两端割裂。
Node 服务中有很多因 console.log() 打印出的无效日志，今年也一并清理，清理后的日志更加整洁清晰，查询日志时少了很多干扰，日志量也骤降几百万。
为了能及时的收到线上错误，让运维帮忙配置了接口状态码异常（500以上）的飞书告警，规则是同一个接口 1 分钟内连续 5 次状态异常就会发消息告警。
8 月再次联合运维，将 一套 Node 在线监控系统部署到服务器上，实时查看服务器的性能参数了，例如内存、QPS、CPU 等。
4）招聘
招聘我觉得是个老大难的问题，从去年 11 月就开始了，陆陆续续也面了十几个人，没有找到合适的。
期间也将招聘信息投稿到大流量公众号、科技周刊，还在 V 站发布了招聘帖子。
最终转化率最高的是 V 站的帖子，在那边收到了几份简历，最后录用了一名，3 月份正式入职，目前也已经过了试用期。
今年要招聘两个人，另一个人选也招了好久，远程办公期间发了 3 次 offer，结果有两人来了没几天就走了。
另一人做了两个多月，自己觉得没有融入主动离职了。我们这边不仅仅要做页面工作，还会涉及些服务端的工作，把工作门槛提高了。
本来就是小公司，职责范围还广，就更加难招了。最后一个同事举荐了他的一个同事，聊的不错就发 offer 了，熟人好办事。
8 月底入职，到现在也 3 个多月了，适应能力很强，干活也利索，靠谱的很。
人员配齐后，无论是工作效率，还是工作质量，都比之前高很多，并且还能承接更多的业务需求。
三、体验优化
体验优化也是我今年的一个重点，不仅在易用性上下功夫，还量化了一系列的指标。
更容易让大家看到努力优化后的成果，提供更稳定更流畅的服务给用户，包括对外的会员和对内的员工。
大到一个模块，小到一个按钮，都是我们优化的对象。
1）项目改造
管理后台是公司内大部分员工每天办公的系统，为了便于在手机上使用，特地对其做了响应式改造。
对项目进行 TypeScript 改造，是为了更好的保障代码质量，目前仅在管理后台中小范围的进行推广。
为了提升活动页面的加载速度，对其静态资源进行了 CDN 加速，但是在监控系统中发现，有些旧的资源还在被访问，可能是手机缓存或 CDN 没有刷新到。
对活动页面的脚本也做了针对性的瘦身，分离页面中不需要的第三方库。并且对页面的卡顿、白屏等问题，也都陆续进行了有效优化。
2）北极星指标
北极星指标，也叫第一关键指标，是指在产品的当前阶段与业务/战略相关的核心指标，一旦确立就像北极星一样指引团队向同一个方向前进。
因为我们组维护着大量的 Node 服务，所以指标中就会包含多个服务端数据。其中慢响应（请求时间大于2秒）作为我们组的北极星指标。
在量化日常工作指标后，我们组做了大量的优化工作，将对外业务的慢响应占比控制在万分之二以内。
在过滤掉不影响用户体验和正常优化后的慢响应，数量从 1.307W 降至 1100 个左右。
还有一个指标是 SLA（服务水平协议）占比（例如 99.999%），这是对网站可用性的一个保证，百分比中的 9 越多代表服务可用时间越长，越可靠，停机时间越短。
我们组也持续优化了很多报 500 的接口，基本都是因为 null 或 undefined 引起的，例如 null.map()、undefined.toString() 等。
500 的接口在修复和过滤不影响用户体验的接口之后，从 2159 降至个位数，目前每天的指标数据都比较稳定。
除此之外，每个双月还会给协作方提供一份问卷调查，给我们的表现打分，满分 5 分，并且给予我们一定的改进建议。
3）性能监控
去年的性能监控只有几张折线图，使用率也比较低，今年附加了很多新功能，并且与前端监控可以更好的联动，具体优化可参考此处。
新增的资源瀑布图可以在出现页面问题时，准确的了解到静态资源的加载情况。
LCP、FID 和 FCP 是三个今年新增的性能指标，从更多的角度了解页面性能情况。
分别统计白屏和首屏 1 秒内的数量、1-2 秒内、2-3 秒内、3-4 秒内、4+秒的数量，再用堆叠柱状图呈现。
在将统计的参数全部计算出来后，为了能更直观的发现性能瓶颈，设计了一张阶段时序图。
描绘出 TTFB、responseDocumentTime、initDomTreeTime、parseDomTime 和 loadEventTime 所占用的时间。
四、研发标准
在去年也推进过技术的升级、统一技术栈和前后端分离，今年完成方面比去年好很多。
主要就是各个组的人员都补充后，有了更多的资源去支持这类基础工作，不像以前都铺在业务上。
1）技术升级
去年将 UmiJS 升级到 2.0，今年 3 月成功升级到了 3.0，不过官方今年已经推出了 4.0 的稳定版本。
服务器的 Node 环境，五年来一直是 8.7 版本，去年曾经短暂的升级到 12，但是发现了时区问题，马上就还原了。
后面人员都铺在业务上，也没时间做升级，一直拖到今年 8 月，才有机会推进升级，一举升到 16.15。
终于可以使用一些新的 Node 功能和第三方库了，虽然这次升级也遇到了时区问题，但是顺利解决了。
2）技术栈统一
Node 的那些边角料服务今年也没有时间迁移至 Go，ROI（投资回报率）太低，没人重视，一直搁置着。
6 月制订了前端技术栈统一计划，由我们自己组操控，之前因为历史原因和赶进度，将一些活动页面通过 jQuery 实现。
现在就要将那些页面改成 Vue，试着先迁移了 3 张常用的活动页面，当前已经迁移完成。
3）前后端分离
前后端分离其实从我进公司就一直挂在嘴巴，但因为客观原因，一直无法推进。
今年 10 月初终于迎来了正式改造，先在管理后台试点，我们提供权限和操作日志的接口，这样就能适配之前的验签和日志逻辑。
10 月底顺利上线，目前已经在服务器中稳定运行。
活动页面的分离，也在稳步进行中，接下来就是我们出页面，服务端出接口，首次先在常用的榜单中试点。
posted on
