一、日常问题

 1）JSBridge

　　最近周会的时候，组员抛出了一个问题。

　　就是有时候一个活动过来，需要客户端支持，这个时候不仅需要客户端开发，还得覆盖版本。

　　我们在想有没有办法提早完成这些客户端功能，避免等待覆盖。

　　当场没有讨论出结果，然后我又把问题抛给产品和客户端人员。

　　他们也给不出很好的方案，产品说无法预料到底要加啥。

　　客户端说等时间长了，APP 支持性完善度高了，这个概率会减小。

　　让我们也可以提出前端性的设计，未雨绸缪。

　　我还找运营要了一份 2026 年，全年的活动计划，不过里面只有标题，并没有活动规则。

　　所以目前也无法评估，需要加什么功能。

2）积压需求

　　在某端资源有限的情况下，优先级不高的需求，很容易被积压。

　　实际工作中，遇到过产品、研发、测试资源受限导致需求延期，有的跨度甚至 1 年之久。

　　公司有个双月需求管理机制，会将需要开发的需求丢进来，就会看到积压的需求一直出现，但一直没有推进。

　　这类需求都以公司的内部功能为主，不会影响营收和外部用户。

　　若因为开发资源而延期，那么会由产品或运营在双月会议上提出是否有资源推进。

　　若因为测试资源而延期，那么测试有人后就会推进跟测，大部分情况下开发都能配合。

　　不过，当需求跨度太长时，再重启的话，就会出现很多问题。

　　例如忘记需求细节了，提测功能和测试没有同步，跟测时发现遗漏了功能点等等。

　　目前，还没太好的解决方案，只能是遇到现场解决。

3）与运营的沟通

　　4月份，团队里的一名成员主动向我提出，给公司的所有运营都发了一份问卷。

　　内容包括最花时间的工作、后台优化点、活动玩法够不够、用飞书机器人提效的场景、重复性工作等。

　　我很支持这项工作，马上将运营的两个leader拉到一个群里，正式交涉，他们对这份问卷也很积极。

　　迅速推给各自的组员，收到了8份问卷，提炼了3大部分，10个BUG、9个优化和13个新需求，完成率 51.5%。

　　大部分已上线，少部分等待测试验收。需要协调多端资源的需求，已经反馈给产品，让他们插入到相关版本迭代中。

　　而对于那些不需要代码修改的反馈，我们也会逐个解答，替他们找到相关人员，拉群沟通。

　　首次尝试问卷，问卷后还特地拉了个群，让他们可以实时反馈，建立团队之间的信任。

　　这波操作下来，收获了运营们一致好评，也让我们发现了许多没有注意到的优化点。

　　对于活动玩法太少，我思考了良久，直接引入第三方的搭建系统不仅成本高，并且大部分功能并不需要，玩法也少。

　　于是针对他们提的最多的玩法，我们用AI将另外一条业务线的代码相关玩法代码抽象成组件。

　　做成demo，给运营参考，眼见为实，在下次活动时，前端能快速引入到页面中，当然，服务端还需要些改造。

二、工作优化

1）Monorepo

　　公司有两条业务线，目前活动业务各开了一个 Vue3 的项目。

　　框架都相同，并且有些通用组件是共用的，如果各自维护，那么需要来回的复制黏贴。

　　那么就需要有一种更高效的维护方式，避免多余的操作。首先想到的是 npm 包。

　　就是将共用代码集合在一起，上传到 npm 平台，但每次的维护成本不低，并且还会暴露公司业务。

　　公司之前的团队，部署过一套私有的 npm，但自从人员换了一波后，就无人在维护了，没有传承性。

　　我们这种小团队，把代码放置在一起，将维护成本降到最低才是良策，于是想到了 Monorepo。

　　Monorepo 是一种代码管理策略，将多个项目集合在一个目录内，在我看来比较轻量。

monorepo
├─-- vue1
├─-- vue2
├─-- package
├─----- components
└─----- utils

　　vue1 和 vue2 两个目录内就是之前的项目代码，各自都有 package.json，可以说是独立的。

　　最后找运维，新开两条代码发布流水线，部署花了点时间，发布后的代码会覆盖原来项目发布的代码。

　　这样就不需要用新的域名了，同一个仓库后，Git中的test、pre、master分支也能共用。

　　改造过程从 12 月 23 号开始。

2）直播组件化

　　公司计划将直播的业务剥离出来，重新封装架构部署。

　　得到的效果就是该服务可以快速移植到公司的其他 APP 中，代码包括客户端、服务端和管理后台。

　　但时间非常紧张，并且正好遇到春节长假，开发时间满打满算也就半个多月，所以决定不动数据库表。

　　由于改动巨大，所以我们也花了些时间准备。首先是将相关接口拉取出来，形成思维导图。

　　此图会给服务端核对，他们会生成总的接口文档，但没想到，他们没看我们的文档，结果就少了些接口。

　　还好发现的早，马上让他们去补了。然后测试为了写用例，也列出了一份管理后台的菜单文档，与我们和运营核对。

　　对于将要改造的页面，我都会标注一下，至此，我们产品线的准备工作大致完成了。

　　接着我与另一条产品线的人核对，这条产品线原先也有直播业务，但现在会全部废弃掉，启用新的服务。

　　他们服务端与我们的服务端共用一套代码，但会部署两个命名空间，并且两套数据库，这样就能互不影响。

　　但像用户系统，无法复用，所以他们的服务端会有单独的分支来管理，并且他们不会将逻辑合并到我们这边的分支中。

　　我们前端有个后台管理系统，另一条产品线的业务要复用直播相关的页面。

　　我们的前端界面和 Node 服务都是一套代码，我们会根据启动命令中，自定义的环境变量来区分当前环境。

　　对于用户信息，同样也要做适配，会有一个统一的入口，处理完适配信息后，数据再从一个统一的出口返回。

　　在大框架和协作内容明确后，各自就开始完善逻辑了。