背景#
這是從 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 邊撸邊學，感覺太重。不過好在需求不複雜，沒讓我的這些不足體暴露太明顯。