「回忆2022，展望2023，我正在参加2022年终总结征文大赛活动」
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 月底顺畅上线，现在现已在服务器中安稳运转。
活动页面的别离，也在稳步进行中，接下来便是咱们出页面，服务端出接口，初次先在常用的榜单中试点。