みなさんは、日々の業務の中で「リファクタリング」に積極的に取り組んでいますか？

「リファクタリング」は、『リファクタリング既存のコードを安全に改善する（第2版）』（マーティン・ファウラー著）でも語られている通り、既存のコードの振る舞いを変えずに内部構造を改善する作業です。ですが、多くのエンジニアが実践できずにいます。

その最大の理由は「リスク」への不安です。

リファクタリングを阻むリスク

「挙動が変わってしまったらどうしよう」「既存機能が壊れてしまったら責任を負えるだろうか」と、多くの人がリファクタリングに躊躇します。しかし、この問題への対策はすでに知られています。それが「テストの充実」です。

なぜテストがリファクタリングに必須か

コードの振る舞いが変わっていないことを保証する唯一の手段は、十分なテストしかありません。

テストがないコードは、触ること自体がリスクになる
テストがあれば、新人や新規プロジェクト参画者でも安全にコードを修正できる
振る舞いが明確に定義されているため、変更や改善の範囲を容易に特定できる

また、最近では AI技術を活用してテストコードを自動生成することも可能になっており、テストを書くハードルは下がっています。
テストコードはアプリの品質を向上させ、バグの発見を助けるものであり、よっぽど変な書き方をしていない限りアプリの動作を妨げることはないのでどんどん書いていきましょう！

リファクタリング実践例：誰でもできる最初の一歩

では、実際にどのようなリファクタリングをすれば良いのか、具体例を挙げてみましょう。

例：メソッドの抽出/クラスの抽出

次のようなコードを見てください。

# invoice.rb
class Invoice
  attr_reader :items, :customer_type

  def initialize(items, customer_type)
    @items = items
    @customer_type = customer_type
  end

  def total_price
    total = 0
    items.each do |item|
      if customer_type == :regular
        total += item[:price] * 0.9
      elsif customer_type == :vip
        total += item[:price] * 0.8
      else
        total += item[:price]
      end
    end
    total + (total * 0.1) # 税金を追加
  end
end

このコードには以下のような問題点があります。

割引計算が total_price メソッド内に直接書かれている
ロジックが分離されておらず、将来的に拡張しづらい
計算の再利用が難しい（他の計算処理で使えない）

振る舞いを保証するためにテストコードを書いておきましょう。

# invoice_spec.rb
require 'rspec'
require_relative 'invoice'

RSpec.describe Invoice do
  let(:items) { [{ price: 100 }, { price: 200 }, { price: 300 }] }

  context "when customer is regular" do
    it "calculates total price with 10% discount and 10% tax" do
      invoice = Invoice.new(items, :regular)
      # 計算式: (100 * 0.9 + 200 * 0.9 + 300 * 0.9) * 1.1 = 594.0
      expect(invoice.total_price).to eq(594.0)
    end
  end

  context "when customer is VIP" do
    it "calculates total price with 20% discount and 10% tax" do
      invoice = Invoice.new(items, :vip)
      # 計算式: (100 * 0.8 + 200 * 0.8 + 300 * 0.8) * 1.1 = 528.0
      expect(invoice.total_price).to eq(528.0)
    end
  end

  context "when customer type is not specified" do
    it "calculates total price without discount but with 10% tax" do
      invoice = Invoice.new(items, :unknown)
      # 計算式: (100 + 200 + 300) * 1.1 = 660.0
      expect(invoice.total_price).to eq(660.0)
    end
  end
end

まずは計算ロジックを抜き出してロジックを分離していきます。

class Invoice
  attr_reader :items, :customer_type

  def initialize(items, customer_type)
    @items = items
    @customer_type = customer_type
  end

  def total_price
    subtotal = items.sum { |item| apply_discount(item[:price]) }
    subtotal + tax(subtotal)
  end

  private

  def apply_discount(price)
    case customer_type
    when :regular then price * 0.9
    when :vip then price * 0.8
    else price
    end
  end

  def tax(amount)
    amount * 0.1
  end
end

✅ apply_discount メソッドを抽出し、可読性が向上
✅ 計算ロジックの再利用が容易になった

次に、ストラテジーパターンを活用して割引計算を DiscountStrategy クラスに分離します。

class DiscountStrategy
  def apply(price)
    raise NotImplementedError
  end
end

class RegularDiscount < DiscountStrategy
  def apply(price)
    price * 0.9
  end
end

class VIPDiscount < DiscountStrategy
  def apply(price)
    price * 0.8
  end
end

class NoDiscount < DiscountStrategy
  def apply(price)
    price
  end
end

# コンテキスト
class Invoice
  attr_reader :items, :discount_strategy

  def initialize(items, discount_strategy)
    @items = items
    @discount_strategy = discount_strategy
  end

  def total_price
    subtotal = items.sum { |item| discount_strategy.apply(item[:price]) }
    subtotal + tax(subtotal)
  end

  private

  def tax(amount)
    amount * 0.1
  end
end

# 使用例
strategy = case customer_type
           when :regular then RegularDiscount.new
           when :vip then VIPDiscount.new
           else NoDiscount.new
           end

invoice = Invoice.new(items, strategy)
invoice.total_price

✅ 割引計算の責務を DiscountStrategy クラスに分離し、Invoice クラスの役割を明確化
✅ 新しい割引ルールを追加する際の拡張性が向上

このように小さな一歩を積み重ねて、安全にリファクタリングを進めることが重要です。

未来の変更可能性を高める

リファクタリングを推進するもう一つの理由は、将来の変更を容易にするためです。開発を進めるとき、コードを書く時間よりも読む時間の方が圧倒的に占める割合は大きいですよね？そう、コードは書かれるよりも頻繁に読まれています。つまり、将来的な可読性の確保こそ、継続的開発のための重要な投資です。

また、コードが分かりやすいことは人間だけでなくAIにとってもメリットがあります。

AIによるコードレビューや自動生成が効果的に機能する
保守性が向上し、新規開発時の工数やバグの発生率が低下する

まとめ

リファクタリングの推進は「リスクを減らし、コードの健康状態を維持し、未来の変化に対応できる仕組み」を作るための重要な戦略です。
テストを充実させることはアプリケーションコードに影響を与えませんし、十分なテストコードがある中でリファクタリングを行うことは、新しい機能を作るよりよっぽど簡単です。
次に自分を含むチームの誰かがこのコードを見たときを思ってぜひ一歩踏み出してみましょう！