auditing-rails-tech-debt

Rails 技術的負債の監査

報告のみとし、ユーザーから依頼があった場合に限りコードを編集します。確認済みの問題を簡潔に報告するほうが、可能性の話を長々と報告するより適切です。

各指摘事項

1. コードを引用します。 読んだコードの file:line を記載します。読んでいないコードの問題を報告してはいけません。
2. 出典名を明記します。 引用リソースまたは PoEAA のパターンページから、少なくとも1つの出典にリンクします。できるだけ具体的な出典を優先してください。違反している原則とその出典を明示できない場合、それは意見にすぎないため、指摘から除外します。
3. 変更前と変更後を示します。 このコードベースの命名規則とスタイルを使ってください。
4. 最もシンプルな変更後の形にします。 モデルメソッド、モジュール関数、またはクエリスコープを使います。新しいクラスを導入するのは、状態を保持する場合、または複数のモデルを調整する場合に限ります。simplifying-ruby-code を指定して Skill ツールを呼び出し、そのパターン番号を記載してください。Skill ツールがない場合は、このルールをそのまま適用してください。 Skill ツールがない場合は、スキル呼び出しルールに従ってください。
5. 独立した検証を行います。 発見者とは別のエージェントが、コードから候補を1件ずつ確認します（実際に呼び出されているか、concern やほかの構造ですでに対処されていないか、スキーマやテストが設計を裏付けているか）。確認できないものは除外します。

参照ファイル

調査するカテゴリまたは引用するパターンの参照資料を読みます。 PoEAA のドメインロジック、 データソース、 オブジェクトリレーショナル、 ウェブプレゼンテーション、 分散・並行処理・セッション、 基本パターン； Rails のアンチパターン（コールバックの乱用、 N+1、default_scope、スコープ内の SQL 補間）； SOLID と慣用的な Ruby。

調査の手掛かり

• node <skill-dir>/scripts/find-leads.mjs <app> を実行します。終了コードが 1 または 2 の場合は、stderr に示された問題を修正して再実行します。終了コードが 3 の場合は、db/structure.sql を読んでスキーマのルールを適用します。
• Gemfile、config/routes.rb、db/schema.rb、および sizes にある最大のファイルから着手します。レイヤーが肥大化していることと同様に、レイヤーが欠けていることも診断の手掛かりになります。
• 手掛かりは読むべき場所であり、指摘事項ではありません。各手掛かりを、指摘事項のルールに照らして確認し、schema.unresolved の各項目について、モデルまたはマイグレーションを読んで解決します。

重大度

• CRITICAL： データを破損させる、セキュリティ上の穴を生む、または正確性を損なうもの（スコープ内の SQL インジェクション、金銭処理におけるロックの欠如、レコードをまたぐ副作用を持つコールバック）。
• HIGH： 該当領域の変更すべてに負担をかけるもの（巨大なモデル、コントローラー内のビジネスロジック、高頻度処理経路での N+1）。
• MEDIUM： 限定的な範囲の負債（Value Object の欠如、スコープの重複、ビュー内のロジック）。
• LOW： スタイルや慣用表現からの逸脱。

レポート

• 各指摘事項の既定の形式は、状況に応じて調整します。### [SEVERITY] <title> の見出しに続けて、Where（file:line の範囲）、Smell、Violates（原則名とリンク）、Evidence（引用コード）、Before と After、Why a class（After でクラスを追加する場合のみ）、Effort（S、M、L。一度に行うか、段階的に行うか）を記載します。
• 指摘事項は重大度順に並べ、最後に概要表を付けます。
• 修正は、重大度が高く、コストが低いものから着手します。また、ほかの修正を可能にするリファクタリングを先に行います（たとえば、Query Object より先に Service Layer を抽出します）。