[設計改善] borrowerInfoのグローバル状態管理を複数サーバー対応可能な設計に変更

[SmiSANN]

📋 概要

現在、src/services/reminderService.tsのborrowerInfoがグローバル変数として実装されているため、複数のDiscordサーバーや複数ユーザーの同時使用に対応できません。

🔍 現状の問題点

該当コード

https://github.com/SmiSANN/Club-Key-Manager-Bot2/blob/dev/src/services/reminderService.ts#L10

// 現在鍵を借りているユーザーの情報（借りていない場合はnull）

export let borrowerInfo: BorrowerInfo | null = null;

問題

シングルトン状態: 1つのボットインスタンスで1つの借用者情報しか保持できない

競合の可能性: 複数サーバーに導入した場合、サーバー間で状態が競合する

拡張性の欠如: 将来的な複数サーバー対応が困難

💡 提案する改善策

1. Map管理への移行

// ギルドIDまたはチャンネルIDをキーとして管理

const borrowerInfoMap = new Map<string, BorrowerInfo>();



export const getBorrowerInfo = (guildId: string): BorrowerInfo | null => {

  return borrowerInfoMap.get(guildId) ?? null;

};



export const setBorrowerInfo = (guildId: string, info: BorrowerInfo | null) => {

  if (info === null) {

    borrowerInfoMap.delete(guildId);

  } else {

    borrowerInfoMap.set(guildId, info);

  }

};

2. 影響範囲

以下のファイルでborrowerInfoを参照しているため、全て修正が必要:

reminderService.ts (定義元)

scheduledCheck.ts

buttonHandlers.ts

commandHandlers.ts

📌 優先度

現在の設計: 単一サーバー専用として明記されている (README参照)

優先度: Low (将来の拡張に備えた改善)

緊急性: なし (現状で問題なく動作している)

✅ 受け入れ基準

borrowerInfoをMap管理に変更

全ての参照箇所を修正

既存機能が正常に動作することを確認

複数サーバーでの動作テスト

ドキュメント更新 (README.mdに複数サーバー対応を明記)

🏷️ ラベル提案

• enhancement (機能改善)
• refactoring (リファクタリング)
• good first issue (初心者向けタスク)
• help wanted (協力者募集)

📝 備考

この改善により、以下のメリットがあります:

複数のDiscordサーバーで同じボットインスタンスを使用可能

テストが容易になる (モック化しやすい)

コードの保守性向上

[SmiSANN]

他サーバーに対応させようとすると他にもいろいろなファイルも変更する必要性が出てくる

[SmiSANN]

🔍 追加の影響範囲

マルチサーバー対応にあたり、borrowerInfo以外にも以下のグローバル状態が問題になります:

1. スケジュールタイマーのグローバル管理

該当コード: src/services/scheduledCheck.ts

// 定時チェックのタイマーID
let scheduledCheckTimerId: ReturnType<typeof setTimeout> | null = null;

問題点:

• 複数サーバーで異なる定時チェック時刻を設定できない
• 1つのタイマーしか保持できず、サーバーごとの独立したスケジュールが不可能

改善案:

// サーバーごとにタイマーを管理
const scheduledCheckTimerMap = new Map<string, ReturnType<typeof setTimeout>>();

export const setScheduledCheckTimer = (guildId: string, timerId: ReturnType<typeof setTimeout>) => {
  // 既存のタイマーがあればクリア
  const existingTimer = scheduledCheckTimerMap.get(guildId);
  if (existingTimer) {
    clearTimeout(existingTimer);
  }
  scheduledCheckTimerMap.set(guildId, timerId);
};

export const clearScheduledCheckTimer = (guildId: string) => {
  const timerId = scheduledCheckTimerMap.get(guildId);
  if (timerId) {
    clearTimeout(timerId);
    scheduledCheckTimerMap.delete(guildId);
  }
};

2. 設定値のグローバル共有

該当コード: config.ts

export const config = {
  reminderTimeMinutes: settings.ReminderTimeMinutes || 60,
  checkHour: settings.checkHour || 20,
  checkMinute: settings.checkMinute || 0,
  isReminderEnabled: true,
  isScheduledCheckEnabled: true,
};

問題点:

• 全サーバーで同じ設定を共有してしまう
• サーバーAで定時チェック時刻を変更すると、サーバーBにも影響

改善案:

// サーバーごとの設定を管理
const configMap = new Map<string, ServerConfig>();

export const getConfig = (guildId: string): ServerConfig => {
  if (!configMap.has(guildId)) {
    // デフォルト設定で初期化
    configMap.set(guildId, {
      reminderTimeMinutes: settings.ReminderTimeMinutes || 60,
      checkHour: settings.checkHour || 20,
      checkMinute: settings.checkMinute || 0,
      isReminderEnabled: true,
      isScheduledCheckEnabled: true,
    });
  }
  return configMap.get(guildId)!;
};

3. 鍵の状態管理

該当コード: main.ts

// 現在の鍵の状態（初期状態は「返却済み」）
let keyStatus: Key = "RETURN";

問題点:

• 全サーバーで1つの鍵状態しか管理できない
• サーバーAで鍵を借りると、サーバーBでも「借りている」状態になる

改善案:

const keyStatusMap = new Map<string, Key>();

export const getKeyStatus = (guildId: string): Key => {
  return keyStatusMap.get(guildId) ?? "RETURN";
};

export const setKeyStatus = (guildId: string, status: Key) => {
  keyStatusMap.set(guildId, status);
};

📊 完全な修正範囲まとめ

マルチサーバー対応には以下の全てをMap管理に移行する必要があります:

グローバル変数ファイル用途borrowerInforeminderService.ts借用者情報scheduledCheckTimerIdscheduledCheck.ts定時チェックタイマーconfigconfig.tsサーバー設定keyStatusmain.ts鍵の状態

💭 設計上の考慮点

キーの選択: guildIdを使用することで、サーバーごとに独立した状態管理が可能

メモリ管理: サーバーから退出した際にMapからエントリを削除する仕組みが必要

永続化: 再起動時に状態を復元する場合はデータベースやファイル保存が必要

🎯 段階的な移行プラン

Phase 1: borrowerInfoのMap化

Phase 2: keyStatusのMap化

Phase 3: configのMap化（サーバーごとの設定保存）

Phase 4: タイマー管理のMap化

Phase 5: テストと検証