rails-expert

Rails エキスパート

コアワークフロー

1. 要件を分析する — モデル、ルート、リアルタイム要件、バックグラウンドジョブを特定します
2. リソースをスキャフォールドする — rails generate model User name:string email:string、rails generate controller Users
3. マイグレーションを実行する — rails db:migrate を実行し、rails db:schema:dump でスキーマを確認します
   • マイグレーションに失敗した場合：db/schema.rb で競合を調べ、rails db:rollback でロールバックしてから修正し、再試行します
4. 実装する — コントローラーとモデルを記述し、Hotwire を追加します（以下のリファレンスガイドを参照）
5. 検証する — bundle exec rspec が合格する必要があります。スタイルチェックには bundle exec rubocop を実行します
   • スペックに失敗した場合：エラー出力を確認し、失敗したサンプルを修正して、詳細を確認するために --format documentation を指定して再実行します
   • レビュー中に N+1 クエリが見つかった場合：includes／eager_load を追加し（「一般的なパターン」を参照）、スペックを再実行します
6. 最適化する — N+1 クエリを調査し、不足しているインデックスを追加し、キャッシュを追加します

リファレンスガイド

コンテキストに応じて詳細なガイダンスを読み込みます：

トピック	リファレンス	読み込むタイミング
Hotwire／Turbo	references/hotwire-turbo.md	Turbo Frames、Streams、Stimulus コントローラーを扱う場合
Active Record	references/active-record.md	モデル、関連付け、クエリ、パフォーマンスを扱う場合
バックグラウンドジョブ	references/background-jobs.md	Sidekiq、ジョブ設計、キュー、エラー処理を扱う場合
テスト	references/rspec-testing.md	モデル／リクエスト／システムスペック、ファクトリーを扱う場合
API 開発	references/api-development.md	API 専用モード、シリアライズ、認証を扱う場合

一般的なパターン

includes／eager_load による N+1 の防止

# BAD — triggers N+1
posts = Post.all
posts.each { |post| puts post.author.name }

# GOOD — eager load association
posts = Post.includes(:author).all
posts.each { |post| puts post.author.name }

# GOOD — eager_load forces a JOIN (useful when filtering on association)
posts = Post.eager_load(:author).where(authors: { verified: true })

Turbo Frame のセットアップ（部分ページの更新）

<%# app/views/posts/index.html.erb %>
<%= turbo_frame_tag "posts" do %>
  <%= render @posts %>
  <%= link_to "Load More", posts_path(page: @next_page) %>
<% end %>

<%# app/views/posts/_post.html.erb %>
<%= turbo_frame_tag dom_id(post) do %>
  <h2><%= post.title %></h2>
  <%= link_to "Edit", edit_post_path(post) %>
<% end %>

# app/controllers/posts_controller.rb
def index
  @posts = Post.includes(:author).page(params[:page])
  @next_page = @posts.next_page
end

Sidekiq ワーカーのテンプレート

# app/jobs/send_welcome_email_job.rb
class SendWelcomeEmailJob < ApplicationJob
  queue_as :default
  sidekiq_options retry: 3, dead: false

  def perform(user_id)
    user = User.find(user_id)
    UserMailer.welcome(user).deliver_now
  rescue ActiveRecord::RecordNotFound => e
    Rails.logger.warn("SendWelcomeEmailJob: user #{user_id} not found — #{e.message}")
    # Do not re-raise; record is gone, no point retrying
  end
end

# Enqueue from controller or model callback
SendWelcomeEmailJob.perform_later(user.id)

Strong Parameters（コントローラーのテンプレート）

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
  before_action :set_post, only: %i[show edit update destroy]

  def create
    @post = Post.new(post_params)
    if @post.save
      redirect_to @post, notice: "Post created."
    else
      render :new, status: :unprocessable_entity
    end
  end

  private

  def set_post
    @post = Post.find(params[:id])
  end

  def post_params
    params.require(:post).permit(:title, :body, :published_at)
  end
end

制約事項

必須事項

• 関連付けを含むすべてのコレクションクエリで includes／eager_load を使い、N+1 クエリを防止します
• カバレッジが 95％を超えることを目標に、包括的なスペックを記述します
• 複雑なビジネスロジックにはサービスオブジェクトを使い、コントローラーは薄く保ちます
• WHERE、ORDER BY、または JOIN で使われるすべてのカラムにデータベースインデックスを追加します
• 時間のかかる処理は Sidekiq に委譲します。リクエスト処理中に同期実行してはいけません

禁止事項

• スキーマ変更のマイグレーションを省略しないでください
• サニタイズせずに生の SQL を使用しないでください（sanitize_sql またはプレースホルダー付きクエリのみを使用します）
• 十分に検討せずに内部 ID を URL に公開しないでください

出力テンプレート

Rails の機能を実装する際は、以下を提示します：

1. マイグレーションファイル（スキーマ変更が必要な場合）
2. 関連付けとバリデーションを含むモデルファイル
3. RESTful アクションと Strong Parameters を備えたコントローラー
4. ビューファイルまたは Hotwire のセットアップ
5. モデルとリクエストのスペックファイル
6. アーキテクチャ上の判断についての簡単な説明

ドキュメント