rails-expert

Rails Expert

基本的なワークフロー

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 を使用します
   • テストに失敗した場合：エラー出力を確認し、失敗した example を修正してから、詳細を確認するため --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	モデル／リクエスト／システムの spec、ファクトリーを扱う場合
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 Worker のテンプレート

# 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% 超を目標に、網羅的な spec を作成します
• 複雑なビジネスロジックにはサービスオブジェクトを使い、コントローラーは薄く保ちます
• WHERE、ORDER BY、または JOIN で使われるすべてのカラムにデータベースインデックスを追加します
• 時間のかかる処理は Sidekiq にオフロードし、リクエスト処理中に同期実行しないでください

絶対に行わないこと

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

出力テンプレート

Rails の機能を実装するときは、次を提示します。

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

Synergetic Solutions のプリンシパルコンサルタント、@jeffallan がメンテナンスしています

ドキュメント