Zenn
🪄

【DRY原則】RailsのDRY原則について学ぼう！ 【Ruby on Rails】

2024/08/20に公開
Ruby
Rails
coding
MVC
dry
tech

こんにちは！

今日は、Ruby on Rails でアプリケーションを開発する際にとっても大事な 「DRY(ドライ)原則」 についてお話しします。
DRY原則を理解することで、あなたのコードがもっとスッキリ、読みやすくなりますよ。
これから一緒に、DRY原則の基本から実践的な改善方法まで見ていきましょう！

DRY原則とは？

まず、DRY原則についておさらいしましょう。
DRYは 「Don't Repeat Yourself」 の略で、「自分を繰り返さないで」 という意味です。
この原則は、同じコードを何度も書かないようにしようという考え方です。
どうしてそんなことをするのでしょうか？

DRY原則の重要性

  • コードの保守性 : コードを一か所で修正すれば、アプリ全体がその変更に対応できます。
    これにより、バグの修正が楽になります。

  • コードの再利用 : 同じロジックや処理を何度も書かずに済むので、開発の効率が上がります。

  • 可読性の向上 : 同じコードが一か所にまとめられているので、他の人（または未来の自分）が理解しやすくなります。

RailsでのDRY原則の適用

Railsは、DRY原則を実践しやすいフレームワークです。
以下に、RailsアプリケーションでDRY原則を活用する方法をご紹介します。

1. コントローラの共通処理をまとめる

コントローラの中で似たような処理が繰り返されていることがあります。
このような場合、共通処理をメソッドにまとめることでコードをスッキリさせることができます。

例

class ProductsController < ApplicationController
+  before_action :set_product, only: [:show, :edit, :update, :destroy]

  def show
-    @product = Product.find(params[:id])
  end

  def edit
-    @product = Product.find(params[:id])
  end

  def update
-    @product = Product.find(params[:id])
    if @product.update(product_params)
      redirect_to @product
    else
      render :edit
    end
  end

  def destroy
-    @product = Product.find(params[:id])
    @product.destroy
    redirect_to products_url
  end

  private

+  def set_product
+    @product = Product.find(params[:id])
+  end

  def product_params
    params.require(:product).permit(:name, :price, :description)
  end
end

この例では、set_product メソッドが show, edit, update, destroy アクションで共通して使われています。
これにより、コードがDRYに保たれています。

2. ビューの部分テンプレート（Partial）を活用する

ビューで同じコードが繰り返し使われる場合は、部分テンプレート（Partial）を使うと便利です。
部分テンプレートを使うことで、重複したHTMLコードを一か所にまとめることができます。

例

_form.html.erb という部分テンプレートを作成し、フォームの共通部分をまとめます。

_form.html.erb
<%= form_with(model: product) do |form| %>
  <% if product.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(product.errors.count, "error") %> prohibited this product from being saved:</h2>
      <ul>
        <% product.errors.full_messages.each do |message| %>
          <li><%= message %></li>
        <% end %>
      </ul>
    </div>
  <% end %>

  <div class="field">
    <%= form.label :name %>
    <%= form.text_field :name %>
  </div>

  <div class="field">
    <%= form.label :price %>
    <%= form.number_field :price %>
  </div>

  <div class="field">
    <%= form.label :description %>
    <%= form.text_area :description %>
  </div>

  <div class="actions">
    <%= form.submit %>
  </div>
<% end %>

そして、new.html.erb と edit.html.erb でこの部分テンプレートを呼び出します。

<%= render 'form' %>

3. モデルでの共通ロジックの抽象化

モデル内で同じロジックが繰り返される場合、共通のメソッドやモジュールを使って抽象化することができます。
これにより、モデルのコードがよりシンプルになります。

例

例えば、商品がセール中かどうかを判定するロジックをモデルに追加します。

class Product < ApplicationRecord
  def on_sale?
    discount.present? && discount > 0
  end
end

このメソッドを使って、ビューやコントローラで商品のセール状態を簡単にチェックできます。

4. モジュールの利用

共通の機能やロジックをモジュールにまとめることで、複数のクラスで再利用することができます。

例

以下のような PriceCalculator モジュールを作成し、商品の価格計算をまとめます。

module PriceCalculator
  def calculate_discounted_price(price, discount)
    price - (price * discount / 100)
  end
end

このモジュールをモデルやサービスオブジェクトで利用します。

class Product < ApplicationRecord
  include PriceCalculator

  def discounted_price
    calculate_discounted_price(price, discount)
  end
end

DRY原則を実践するためのツールとライブラリ

Railsには、DRY原則をサポートするための便利なツールやライブラリがいくつかあります。

  1. ActiveRecord
    ActiveRecordは、RailsのORM（Object-Relational Mapping）であり、データベースとのやり取りを簡単にします。
    ActiveRecordを使うことで、データベースクエリの重複を避け、クリーンなコードを書くことができます。

  2. Concerns
    RailsのConcernsは、モデルやコントローラで共通の機能をモジュールとしてまとめるための仕組みです。
    これにより、コードの重複を減らし、よりDRYな設計が可能になります。

  3. Service Objects
    Service Objectsは、ビジネスロジックをモデルやコントローラから分離し、専用のオブジェクトで管理する方法です。
    これにより、コードの責任が明確になり、再利用性が高まります。

DRY原則の限界と実践

DRY原則は非常に有用ですが、すべての場合に適用するのが最善というわけではありません。
以下に、DRY原則の限界と実践方法を紹介します。

  1. 過度の抽象化に注意
    DRY原則を追い求めすぎると、コードが過度に抽象化され、理解しづらくなることがあります。
    適切なレベルでの抽象化を心がけましょう。

  2. 開発の初期段階での柔軟性
    開発の初期段階では、頻繁に仕様が変わることがあります。
    この場合、DRY原則を厳密に適用するよりも、柔軟なコードを書くことが重要です。

  3. テストの重要性
    DRY原則を適用する際には、コードのテストも忘れずに行いましょう。
    テストがないと、リファクタリング後に新しいバグが発生することがあります。

DRY原則を意識したRailsアプリケーションの設計

DRY原則を実践するためには、アプリケーションの設計段階から意識しておくことが重要です。
以下のポイントを参考に、DRYなRailsアプリケーションを作成しましょう。

  1. モデルの設計
    モデルはアプリケーションの中心であり、データとそのロジックを管理します。
    モデルの設計時に、以下の点を意識するとDRY原則を保ちやすくなります。

    • 責任の分離 : モデルは単一の責任を持つべきです。
      複数の責任を持つモデルは、複雑化しがちです。
      責任が分かれている場合は、モデルを分割することを検討しましょう。

    • バリデーションとコールバック : バリデーションやコールバックはモデルの中にまとめ、共通のロジックをシンプルに保つようにします。

  2. コントローラの設計
    コントローラはリクエストを処理し、ビューにデータを渡します。
    コントローラの設計では、以下の点に注意します。

    • RESTfulなアプローチ : Railsでは、RESTfulな設計が推奨されます。
      リソースごとにコントローラを分け、アクションを適切に管理します。

    • DRYなアクション : コントローラのアクションで同じコードが繰り返される場合は、共通のメソッドやコールバックで処理をまとめます。

  3. ビューの設計
    ビューはユーザーに表示する部分で、コードの重複を防ぐために以下のポイントに注意します。

    • 部分テンプレートの活用 : ビューで同じコードが繰り返される場合は、部分テンプレートを使ってコードを整理します。

    • ヘルパーの利用 : ビューで共通するロジックやメソッドは、ヘルパーを使ってまとめます。

  4. テスト
    テストコードもDRY原則を適用できます。
    重複するテストコードやセットアップコードは、共有のメソッドやモジュールにまとめることで、テストコードを整理します。

例

テストのセットアップコードを test_helper.rb にまとめます。

test_helper.rb
class ActiveSupport::TestCase
  setup do
    @user = users(:one)
    @product = products(:one)
  end
end

これにより、各テストケースで重複したセットアップコードを省略できます。

DRY原則を守るためのヒント

DRY原則を実践するためのヒントをいくつかご紹介します。
これらのヒントを参考に、あなたのRailsアプリケーションをさらにDRYに保ちましょう。

  1. コードの重複に気づく
    コードの重複を見つけるためには、アプリケーション全体を通じてよく目を通し、似たようなコードが複数箇所に存在するかを確認します。
    重複に気づいたら、そのコードをリファクタリングすることを検討しましょう。

  2. リファクタリングの習慣をつける
    コードを書いた後に、リファクタリングの時間を持つ習慣をつけると良いでしょう。
    リファクタリングを通じて、コードをDRYに保つことができます。

  3. テストを活用する
    テストコードもDRY原則を守るために活用しましょう。
    テストの重複を避け、共通のセットアップやアサーションを共有することで、テストコードを整理できます。

  4. コードレビューを活用する
    コードレビューは、他の人の視点でコードの重複や改善点を見つけるのに役立ちます。
    チームメンバーとのコードレビューを通じて、DRY原則を意識したコードを維持しましょう。

まとめ

DRY原則は、Railsアプリケーションの品質を保ち、保守性や再利用性を高めるために非常に重要な考え方です。
コントローラの共通処理、ビューの部分テンプレート、モデルの共通ロジック、モジュールの利用など、さまざまな方法でDRY原則を実践することで、よりクリーンで読みやすいコードを書くことができます。

開発を進める中で、DRY原則を意識しつつ、過度な抽象化に注意しながら実践していくと良いでしょう。
これからの素晴らしいRailsアプリケーション開発に役立ててくださいね！

質問があれば、いつでも聞いてくださいね。😊
それでは、素敵なコーディングライフをお楽しみください！ 🌟

Discussion