背景#
这是从 21 年 11 月开始的故事，那个时候 Stepn 开始受到很多用户的青睐。回到老东家后临危受命的第一个紧要需求，就是团队计划在 discord 社区来发展用户，为了提高社区的活跃度，希望做一个 discord 机器人脚本来做一些事情。大概需要的功能有：
- 每当用户邀请的人数达到 m，就赋予这个用户一个 n 角色
- 抢答以获取奖励角色
- 进入社区的身份验证
等等...
invite-tracker 虽然可以做到邀请计数再赋予角色的功能。但是它有一个明显的缺陷，就是会重复统计。
困难#
在这个业务方向公司并没有任何经验积累，需要自行探索，而且想招对口的人也招不到。好在 bot 开发本身的逻辑并不复杂，特别是在有了经验之后。但是最大的难点还是在于不能写测试代码，另外自己在服务端的开发经验又极度欠缺，不知道有哪些事情是需要注意的。
discord bot 的上线过程很简单，就是把脚本跑起来就行了，各种 id 的配置全换成线上的就行，由于没有自动化测试支持，只能在脚本写好后，自己创建一个私有的 server，然后把机器人邀请进去人为测试。
测试方案可以用 Cypress 之类的 e2e 框架来模拟。但是 discord 对登录限制得很严格，如果多次登录导致需要做 google recaptcha 验证，那测试代码就废了。
Discord 自身的缺陷#
有几个问题都是在线上才发现的，主要原因在于当时缺少文档说明：
- 在真实环境里运行才知道，discord 提供的可交互按钮，有 debouce 限制，这是好事，但糟糕的是这个按钮在多次点击后会显示报错，对用户来说那就是我们的问题了。
- 在用户量暴涨的几天里经用户反馈才知道，discord 提供的邀请链接只有 1 千个。
关于控制交互控件 debouce 的问题， 官方最后单方面关闭了，参考 issues 链接。如果你的机器人用到了它的控件，并且你的用户可能疯狂的点击，最好别用。
邀请链接数量受限，也就意味着用户量涨幅被限制了。为了应急，写了一个脚本。每分钟去检查邀请链接的数量是否达到了上限。可是即便用脚本来清，也只能解燃眉之急。
重新设计#
为了解决邀请链接受限的问题，只好放弃基于 Discord 自身的邀请逻辑，自己重新设计：
- 为了确保唯一性，提供了一个频道和一个指令，让用户自己去认领自己的邀请链接。
- 只有通过定制化的邀请链接进来的用户，才会统计邀请次数，达标时以获得奖励角色。
这样做的好处首先是摆脱了 Discord 自身的限制，同时数据方面可以完全自理。落地后经观察发现，用户量的涨幅从每天几千到了每天几万。
运营#
有了大量的用户群体，就有了更多反馈问题的人，公司运营也会非常受限。顾虑到这个问题，我为运营同事提供了一些快捷指令：
- 查某个人是被谁邀请进来的
- 查某个人邀请了哪些人
等等...
当时还做了一个有趣的功能。社区一直有一个抢答送奖励角色的活动，每当有人获胜时我们会在指定的频道来为这个人庆祝。庆祝的时候会携带一张有趣的图片；Jerry 希望图片可以在庆祝的时候出现，并且从 MEME 频道获取。我想了想，直接从大量的消息数据里面爬取不太合适，因为要是有人发了一些敏感的图片就不好了，加之上传到频道里的图片链接，是 discord 自己维护的，所以我提出：
- 监听管理员的 reaction 行为
- 只要是管理员添加了 😍 表情的消息，就把这个消息里携带的图片链接缓存下来
- 每次庆祝的时候，就随机抽取一个图片链接嵌入过去
落地后的社区氛围其乐融融。
总结#
Stepn 不再像去年那样火爆了，机器人还在跑的功能也没几个了。一年多过去虽然统计到的用户量有 190 万 +，但目前还在的用户不多了。于我个人来说，服务端开发的经验肯定是见长了，但我还是更倾向于深耕前端。对于服务端学到的东西并不多，个人浅见：
- 日志大于功能代码
- 运行内存的 CRUD 比数据库的 CRUD 快很多，更可靠
不足的也很明显：
- 工程化上自己没能探索出最佳实践，整体缺乏架构组织
- 没有考虑解决内存占用的问题（幸好领导阔绰单独给我一台机器跑程序）
不想直接硬着头皮上 nestjs 边撸边学，感觉太重。不过好在需求不复杂，没让我的这些不足体暴露太明显。