2025 年相比去年，公司的业务做了些扩张，人员也补充了两名，他们的加入产生了 1+1>2 的聚变效应。
自己则是将更多的精力投入到了公司业务和团队建设中。
今年博文写的不多，就十多篇，其中有两篇还是讲小浣熊水浒卡，而不是技术的。
读了几本用户体验和消费心理学的书，在和产品或运营对接需求时，能有更多自己的见解。
基于需求完成和满意度，每个双月会给团队制订几组 OKR，这样也有地方记录工作中的点滴。
还有一点与以往大不同的是，慢慢不再搜索引擎中查询技术问题，而是更多的转移到了各类 AI 中。
今年的关键字包括看书学习、业务研发、团队建设、项目迁移、周边旅行、水浒卡等。
下面的思维图列举出了今年做的一些比较重要的事情。
一、公司业务
今年参与了 12 个版本迭代，大大小小 120 多个需求。
直播需求占比比较大，剩下的有社区、社群小程序和徒步，还有 20 多个主动挖掘的优化需求。
我们团队不仅要写纯前端的业务，有些服务端的逻辑，也是我们在用 Node 维护，所以会涉及到一些接口问题。
1）直播和社区
公司招募到了一个专门搞直播的 5 人外包团队，今年的直播功能比去年有翻天覆地的变化。
比较大的功能增加和改造就有十多个，单独配了个产品跟进需求，我的很多精力也扑到了直播的业务需求开发中。
就是直播团队在外地，所以沟通都需要在线语音，没有面对面的便捷。
今年的年终盛典是我第 6 次参与，但是比往年都要累，因为出了 3 次事故，以往最多是 1 次，但今年爆表。
这就导致，我在这 20 天的活动中，每到一个节点我就需要盯着，每次节点都是 0 点，生物钟都变了。
其中周六有一整天在家里推着各团队去排查活动中发生的问题，到晚上才上线修复完成。
社区业务今年也有专门的产品和服务端团队承接，我们前端组则会承接两个模块的业务。
有一个比较重要的常规活动，每日的营收比较可观，但有几天因为 redis 的问题出现了营收波动。
为此，增加了关键字告警推送，并详细记录了排查过程，该活动已记录了 13 个相关问题，以及好多份相关文档。
还有一次营收又有波动，原来是改动的新代码不支持分布式导致业务异常。
2）社群和徒步
这两者属于一条新的业务线，社群是指去年做的一个小程序，今年继续迭代维护中，而徒步是今年新做的一款 APP。
4 月的时候，为了应付上架，需要临时设计一个官网，当时产品用 Lovart 在线生成一个官网，震惊到了我。
拿到代码后，我整体看了下，基于 React 和 Tailwind.css，代码还是蛮工整的，我和 UI 微调了一下就发到线上了。
顺便一题，我们组经常会接到各类临时的需求，有的时候还比较紧急，有时候版本开发到一定程度才发现需要我们介入。
同月，运营提了个一物一码的需求，就是一个物品对应一个二维码，二维码会印在衣服上，所以我们在对接时会更加谨慎。
但没想到，他们在与工厂对接的时候，还是把二维码搞错了，地址中缺少参数，我们这边都无法适配。
9 月份，在徒步的后台做了一个轨迹预览的功能，就是将徒步的各个位置画在高德地图上，地图的 SDK 比较完善，对接的也比较顺利。
2012 年的时候，自己就做过一个地图的项目，13 年后再做一次，甚是怀念。
3）体验优化
我每个双月都会制订几个体验优化 OKR，受益对象不仅仅是公司用户，还可以是同事，甚至是我们自己。
今年团队大大小小主动处理了 100 多个体验优化，现在大家都会有意识的去发现需要体验优化的点。
虽然很多都是比较微小的调整，但是却能让使用者大大提升幸福指数。
优化点包括放大表格宽度，增加一列字段，加个复制按钮，多几个检索条件，选中当前页菜单，下拉框增加搜索等等。
有一个表格横向滚动条吸底，比较有意思，当列表很长时，比较有用，不用滚动到最后再横向滑动了。
还有个怪异的偶现问题，困扰了我们很久，在拿到用户手机的 UA 后才得以解决。
原来部分华为手机因为 UA 中包含 WEIBO 关键字，命中了微博环境，让误以为是在APP之外，从而出现了异常。
除了代码的体验优化之外，还有文档的体验优化，在 1 月份创建了一份页面接口映射文档。
将常规网页中涉及的接口用思维导图的方式列举出来，在需要查看页面接口时，就不用去翻代码或者在浏览器中访问了。
8 月份又将比较复杂的主播签约流程数据库逻辑整理了出来，配以 SQL 语句和计算代码，不用再去查日志和源码了。
除此之外，今年创建和维护了 100 多份文档，包括业务、代码、规范、周报等。
4）性能优化
今年遇到了好多个性能问题，有些比较简单，有些比较麻烦，这里记录了两个比较有意思的优化过程。
在 9 月份之前，就会陆陆续续收到社群后台上传图异常的反馈，当时比较归咎于网速的原因。
而 9 月份之后，公司网络升级，但是还是会出现上传异常的情况。
去现场实地勘察之后，发现是由于上传的图像数量不仅庞大，并且图像的尺寸也较大，这就出现了性能问题。
后续就是在 URL 增加图像压缩的参数（CDN的功能），img 元素 增加 loading 懒加载属性，用 IndexedDB 缓存上传的文件等。
并且为了更好的体验效果，还增加了上传进度的反馈等，以及各类加载中的特效。
进行了一系列大刀阔斧的改造后，发现一个运营的电脑还是有问题，连上传 20 张图都很慢，并且风扇狂转，非常奇怪。
于是我找行政，让她们走流程换台新一点的 mac 了，用物理的方式解决性能问题。
还有一个是关于 SQL 语句的优化，SQL 执行时间最长将近令人发指的 14 秒，分析后发现没有命中索引导致的。
因为此表的数据量已经 1 亿多了，所以就试着将 SQL 改成能命中已有的索引。
在将条件中的 gold_delta>0 改成 trans_type(2, 7, 13, 98, 99) 后，就成功的将执行时间降到了几百毫秒。
顺便一提，这条语句在一个无人维护的 Node 项目中，服务端排查后，紧急让我们来处理的。
按计划这类服务都是要迁移到 Go 中的，但是因为客观原因只能还搁置着。
其实我从入职到现在，就一直在推动这类服务的迁移，但这些都是不紧急不重要的业务，所以需要有契机才能完成。
5）支付业务
我们团队还维护着 H5 页面内的微信支付业务，5 月份的时候，有用户提现失败。
原来是公司账户余额不够了，马上去充值，此业务已年久失修，2026 年有望将其迁移至服务端。
7 月份的时候，有用户说在网页充值时被限制金额，排查后发现在微信商户中有一个金额限制。
并且申诉内容极其繁杂，于是让出纳一起配合，几天后就解除了限制。
这让我想起了 2021 年的年度活动时也出现过一次金额限制，可能也是这个问题。
9 月份在查一个问题时，发现微信商户的证书明年就要到期了，于是就着手升级了证书，再加几年期限。
多年来，我一直反馈希望将支付相关的业务集中管理，搞个支付中心，有一定地进展，但我们这边还留了些尾巴。
二、工作优化
今年人员增加，我也有更多的时间来思考和优化工作内容，在团队管理方面也进行了更多的实践。
团队内部不仅在普及 AI 辅助提升编程效率，还在不断完善自研的监控系统，以及全链路日志的探索，项目管理优化等。
1）活动标准化
将活动标准化后，就能节省更多的人力去做其他的业务，并且运营也能更快的上线活动，完成既定目标。
5 月份品牌组出了个短剧活动，接口返回 JSON 格式，将图像地址，数据信息等一起返回。
产品在设计之初，就希望未来以动态下发的方式渲染页面。如果此类活动频繁，就会制作管理后台的可视化界面。
同月，还将一个充值奖励的活动标准化，设计好玩法规则和页面结构，然后接口由我们自己提供。
而页面内需要配置的字段，以 JSON 格式，都写在后台的通用配置中，一旦有新活动，就配置个新 JSON。
6 月，直播组提出了一个常规的 PK 活动，在后台中可以配置 PK 人员和相关信息，每月进行一次。
运营也意识到了，一个可以自己配置的活动，可控性更高，并且显而易见地提效。
9 月份，出现了点意外，有个特殊的榜单活动，运营当时想将其做成皮肤模板，可以反复套用。
但是，在产品文档中标注的有歧义，以至于我们技术部所有人都遗漏了此功能。
团队成员还对活动中的 JSBridge 做了插件化、图像加载组件化、Tab切换缓存处理。
2）老旧Node业务
2023 年 9 月，我制订了购买页充值迁移的计划，直到今年的 6 月，才将页面迁移完成。
4 月份运营需要充值页面支持更多的支付平台，以此为契机，就重构了此页面。
核心业务都交给了服务端处理，并且将支付宝的充值逻辑也全部迁移到了服务端。
12 月份，在排查定时任务的错误时，废弃了 6 个冗余和过时的定时任务。
修改了 2 个定时任务的执行周期，原先是每多少分钟执行，现在改成每日执行一次，并且要避开高峰期。
还让运维，关闭了一个已经不需要维护的榜单定时服务，节省资源开销。
今年还发现了两个老旧的 Node 服务需要待迁移，6 月份，发现了个经验加成业务；8 月份，发现了个短信发送的服务。
其中第一个业务本来想移交出去，但服务端说没有时间重构，只得继续维护。
顺带一提，这两个业务的 Node 环境还停留在 8.7（最新的是 24），并且依赖了个私有 npm 包。
2025 年我还跟产品提到了分享页面的重构，并且她们也做了简易的产品文档，希望 2026 年能够实现迁移。
3）飞书机器人
飞书机器人就是以对话的方式实现某个功能，在前几年就已引入。
但主要是做些告警和数据推送的功能，今年我们团队拓展了机器人，赋予了更多功能。
团队内的成员在 6 月份封装了一整套的机器人逻辑，包含了 IP 白名单，代码发布等功能。
IP 白名单是公司所有人都需要的，之前都是让我们团队的人添加或者有权限的人添加，现在通过机器人可以自己添加。
在 8 月份，我也在机器人中添加了查询某个第一名用户的功能。
另一名团队成员增加了管理后台密码更新验证码的功能，帮助同事们可以自主完成密码的更新，而不是找我们。
对于机器人的业务挖掘，我们还在不断探索中。
4）监控系统
自研的前端监控系统在今年排查线上问题时，发挥了很大的作用，累计每日可减少 1.5W 个左右的错误。
帮助我们排查页面白屏问题，对外的活动页面都是基于 Vue3 生成的，即 CSR 的渲染方式。
通过监控系统的行为轨迹，我们发现，白屏基本都是没有读取正确的脚本导致的。
有的是访问到了失效的缓存副本，有的是访问服务器中删除的脚本。
当监控到白屏时，就会在页面中跳出一个弹框，经过 3 轮迭代，弹框中会包含强制刷新的按钮，更换浏览器的提示。
并且用脚本动态的给资源文件增加时间戳，破坏资源缓存。
而在排查问题时，还发现监控系统行为轨迹只存在 7 天，因为原先读的是 MySQL，里面只存储了 7 天数据。
显然太少了，于是就将数据源改成 ElasticSearch，直接增加至 2 月。
在 7 月底，还对监控数量进行了优化，从 200W 降低到了 100W 左右，减少存储成本。
注释掉了通用组件内的打印日志，每日减少监控记录 47W 条；过滤了 4 条不重要的接口，每日记录可减少近 50W 条。
5）全链路监控
其实在 2023 年就尝试了日志全链路追踪，就是在 Node 环境中，能精准的甄别出一个通信的所有相关日志。
在今年的 3 月份，团队成员也尝试了基于 AsyncLocalStorage 的日志追踪。
不过在线上实验时，都出现了问题，日志还是会混淆。7 月份我尝试在 Node 项目内引入了 SkyWalking 全链路监控。
阿里云推荐的一种链路追踪，基于官方文档配置和加载依赖后，就在运行了。
但是有个接口过滤参数，咨询阿里云，提问 AI，都没搞明白怎么用，最后还是看源码才知道了如何使用。
上线运行，的确能看到日志链路，并且还能看到接口调用的来回时间。
值得一提的是，在12 月份，自己也在接口日志中加了来回的响应时间，这样就能知道是自己的逻辑慢还是内部接口慢。
不过在上线后，发生了意想不到的意外，就是原先可以链式调用的 Mongoose 的方法，但现在会报错。
无奈，先将其下线了，不过好在，通过链路日志，我已经知道慢响应的瓶颈何在了。
6）团队建设
3 月份人员补充后，就又重启了团队内部的技术分享，到年底，我们团队内部分享了 40 多场各类的技术分享。
我现在建议大家分享的内容尽量贴合当前的业务需求，这样写起来也能简单些，并且不空洞。
在自己表达思路的同时，也能让自己有更深刻的认识，并且也能帮助团队其他成员开阔认知。
在实际开发中，团队成员有几次都使用了分享中的技术知识点。
新人加入几周后，他们在完成一两个项目后，我们开启了几场 Code Review，主要是看看他们的思路和写法。
抛出各自的问题，并想办法解决，我们不强制代码规范，但写的代码至少别人能看懂。
能写注释的尽量多些注释，能语义化的尽量语义化，不需要太追求极致的性能。
年底的时候，公司管理层在推广 AI 辅助编程，我们团队 AI 的使用也比较广泛，相信 2026 年能有更多突破。
12 月与产品配合，尝试了通过 PRD 生成 H5 页面，虽然其中还不乏各种问题，但这是一种很好的协作尝试。
在团队成员分享 AI 的使用时，发现了些问题，例如后台封装了通用组件，但在用 AI 生成代码后直接弃用了这类组件。
这样就是开倒车了，维护性方面将大打折扣。
国外的 AI 工具不少，不过好多都限制中国区域不可用，有点被围剿的意思。
7）项目管理
公司有两条产品线，而管理后台写在一套代码中，这就导致在构建项目时会比较慢。
那这个时候其实有很多方法可供选择，例如拆分成两个独立的后台，但如此一来，公共代码也要拆分成两份维护。
或者采用微前端技术，剥离一个项目出来，不过有一定的开发成本。
在观察后发现，构建会根据路由文件来，如果路由文件中没有声明，那么就不会将此文件纳入构建流程中。
于是在 7 月份，声明了两份路由文件，大家维护各自的路由。并且让运维创建了两套流水线，和两个域名。
在完成路由构建后，前后的代码发布总时间减少了 3 分钟以上。
经过一个月左右的时间，陆续将测试、预发和生产的三个环境的发布流水线部署完成。
在 12 月份，团队成员提出，对外活动现在分成了两个项目，但是有些组件是共用的。
每次人工的复制黏贴，难免会遗漏或出错。管理后台是分，而这里却是合。
我们想到了 Monorepo 目录管理，将两个项目整合在一个目录内管理，抽象出共用部分。
同样为了实验，让运维部署了两条新的业务线，以及两个新域名，目前还在调试中。
三、日常生活
今年小孩读两年级了，周末还得在家陪着写作业，然后带他去上篮球课、钢琴课等兴趣课。
偶尔周末来个短途自驾游，然后下班后刷刷短剧，小红书等。
去年买了很多卡，今年又不想要了，就出了很大一部分，但大部分都亏本了，好在 30 周年水浒卡回了好多血。
1）旅行
今年总共去了 8 个地方旅行，最远的是过年期间的广州，其他都是在江浙周边，自驾或高铁。
包括嘉兴南湖、南浔古镇、苏州博物馆、无锡拈花湾、绍兴柯岩景区、千岛湖、舟山等。
在无锡的两次都想去太湖边上的三国水浒城，但总是因为种种原因没去成，可惜了。
广州那边我每天都要买一杯鲜榨甘蔗汁，粤菜我也很喜欢，都是现烧的，所以上菜会慢点。
每一家饭店的菠萝古老肉是我必点的，还体验了下当地的早茶，店里几乎都是老人，很少看到年轻人。
广州特别热闹，北京路那边和南京路差不多，过年期间乌泱泱的人。
2）水浒卡
3 月份的时候参与了小浣熊 30 周年水浒卡的众筹，这次众筹特别魔幻。
卡的价值翻了十多倍，一些赠品价格也都直接起飞，例如亲签评级卡最高都达到了 5 位数。
本来以为大家都知道，没想到，大部分人都不知道这个众筹。
很多人为了追忆童年，都入坑买卡，导致卡的价值直线上升。
4 月份，还到处与人换卡，线下碰头，线上快递，多管齐下，为了集齐 30 周年的水浒套卡，也是拼了。
当月，开始将自己不想要的卡都陆陆续续出掉，出的价格很难赚，基本都是亏本出了。
还有些自己当年留的卡，也都出掉了，再加上 30 周年的卡，回了好多血，把账抹平了。
还能多一些卡在手，不过，这么看来，我是不适合做生意的，老老实实打工了。
