complexity-optimizer

複雑度の最適化

基本ルール

現在の動作を理解し、維持できる場合にのみ最適化してください。正しさが不明確な大規模な書き換えより、テストで裏付けられた小さな改善を優先してください。

デフォルトの動作

ユーザーからコードベースの分析、スキャン、監査、レビュー、または「レポートを作成して」と依頼された場合は、複雑度レポート全体を自動的に作成してください。レポートの項目をユーザーに指定させないでください。

レポートには、デフォルトで次の内容を含めます。

• 分析対象の範囲と、検出したスタック／テストコマンド。
• 影響が大きいと考えられる順に並べた主な所見。
• 各所見に該当するファイルと行。
• 現在のパターンと、コストが高くなる可能性がある理由。
• 現在の複雑度の推定値。
• 推奨する変更。
• 変更後の複雑度の推定値。
• リスクレベル。
• 必要なテスト、ベンチマーク、または手動確認。
• ユーザーが実装を明示的に依頼していない限り、ファイルを変更していないことを明確に記載します。

ユーザーが実装、修正、最適化、適用、変更、リファクタリング、またはその他の明確なコード変更を依頼した場合にのみ、ファイルを編集してください。分析またはレポートだけを依頼された場合は、ファイルを変更しないでください。

ワークフロー

1. ベースラインを確認します。

   • 言語、フレームワーク、テストコマンド、ビルドコマンド、パフォーマンスが重要な処理経路を特定します。
   • コードに手を加える前に、既存のテストを確認します。
   • リポジトリをスキャンする場合は、最初に scripts/analyze_complexity.py <repo> を実行し、ボトルネック候補の一覧を取得します。

2. 改善候補を優先順位付けします。

   • ホットパス、大きな入力を処理する経路、レンダリングループ、データベース／APIのループ、共通ユーティリティのコードを優先します。
   • アルゴリズム上の複雑度と、定数倍の改善を区別します。
   • 警告をすべて修正しようとしないでください。スキャナーの出力は手掛かりであり、証拠ではありません。
   • レポートのみの依頼では、現在と変更後の複雑度を推定できるだけの周辺コードを確認します。スキャナーの生の出力だけで終わらせないでください。

3. 動作を証明します。

   • 変更対象の関数／コンポーネントに対する、的を絞ったテストを探すか追加します。
   • 空の入力、重複、順序の安定性、null／値の欠落、エラー、権限、ページネーション、タイムゾーン、副作用を伴う変更といったエッジケースを確認します。
   • テストがなく、動作が曖昧な場合は、意味を変える前に最小限のリファクタリングを行うか、期待される動作をユーザーに確認します。

4. 慎重に最適化します。

   • キーの等価性が安定している場合は、繰り返し行われる線形検索をマップ／セットに置き換えます。
   • データの形状が適している場合に限り、入れ子になったスキャンを、インデックス化、グループ化、二ポインター走査、スイープライン処理、二分探索、メモ化、バッチ処理、事前計算などに置き換えます。
   • UIコードでは、安定したプロップス、メモ化した派生データ、仮想化、デバウンス処理、レンダリング経路外への高コスト処理の移動により、不要な再レンダリングを減らします。
   • データアクセスコードでは、認可とフィルタリングを維持しながら、一括取得、結合、事前読み込み、キャッシュ、バッチ処理によってN+1の問題を解消します。

5. 検証します。

   • 関連するテストと、型チェック／リンティング／ビルドのコマンドを実行します。
   • 複雑度の改善が明らかでない場合や、パフォーマンスが重要な場合は、マイクロベンチマークまたは測定結果を追加します。
   • 元の複雑度、新しい複雑度、変更したファイル、実行したテスト、残るリスクを報告します。

初回スキャナー

スキルディレクトリに同梱されているスキャナーを使用します。

python3 scripts/analyze_complexity.py /path/to/repo --format markdown
python3 scripts/analyze_complexity.py /path/to/repo --format json

このスキャナーは、Python、JavaScript、TypeScript、JSX/TSX、Java、Go、C、C++、C#、Ruby、PHP、Swiftのファイルで、よくあるパターンを検出します。完璧な静的解析よりも、読みやすい手掛かりを提示することを意図しています。

スキャナーが何も検出しない場合でも、既知のホットパスを手動で確認してください。レンダリングの過剰な発生、データベースクエリのパターン、フレームワークのライフサイクルに関する問題には、リポジトリ固有のコンテキストが必要になることがよくあります。

最適化の安全性チェックリスト

編集する前に：

• 計算量が問題になるほどデータ量が大きいことを確認します。
• 呼び出し側が順序に依存する可能性がある場合、最適化によって出力順序が維持されることを確認します。
• オブジェクトの同一性、可変性、参照の共有が公開動作の一部ではないことを確認します。
• キャッシュに有効な無効化戦略があることを確認します。
• 重複排除によって、表示ラベルが同じ異なるレコードが統合されないことを確認します。
• データベースのバッチ処理によって、テナント、権限、論理削除、ページネーション、ソートの制約が維持されることを確認します。

編集した後：

• まず対象を絞ったテストを実行し、その後、関連する最も広範なテスト／ビルドコマンドを実行します。
• ベンチマークがある場合、または追加した場合は、変更前後の数値を比較します。
• パッチの範囲を限定します。無関係なファイルのフォーマット変更は避けます。

参考資料

• よくある O(n^2) から O(n log n)／O(n) への変換や、フレームワーク固有のパターンについては、references/optimization-playbook.md をお読みください。
• 最終分析または監査結果を作成する際は、references/report-template.md をお読みください。