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 月底顺利上线,目前已经在服务器中稳定运行。
活动页面的分离,也在稳步进行中,接下来就是我们出页面,服务端出接口,首次先在常用的榜单中试点。
标签:Node,稳中求进,今年,文档,2022,日志,优化,页面 From: https://www.cnblogs.com/strick/p/16969761.html