Rails 整頓術 ActiveSupport::Concern と委譲

Transcript

1. Rails 整頓術 ActiveSupport::Concern と委譲 Loose 2025 年7 月 1
2. Fat Model の問題 ありがちなこと 責務が多すぎて見通しが悪い どこに何があるか把握困難 変更の影響範囲が不明確 これらのことから 変更が不安、確信がもてない 頻繁に不具合が出る レビューがつらい 2
3. Fat Model がつらい原因 一度に扱わなければならない情報量が開発者の認知限界を超えてしまう 解決策 私たちの場合は、以下の2 つの戦術を用いています。 モデルのコードをconcerns で整理する 機能をオブジェクトの追加システムに委譲する（純粋なオブジェクト指向プ ログラミングとも呼ばれます） Concern と 委譲 で情報を小分けにする 素のRails は十分に豊かである（翻訳）｜TechRacho by BPS 株式会社 37signals Dev — Vanilla Rails is plenty 3
4. AI コーディングにて Claude Code で、あるプロダクトの User モデルに変更を加えようとしたとき > User からxxx 関連のロジックを Concern に抽出してください。 • Read(app/models/user.rb) ⎿ Error: File content (28761 tokens) exceeds maximum allowed tokens (25000). Please use offset and limit parameters to read specific portions of the file, or use the GrepTool to search for specific content. Fat Model は AI にも優しくない 分割統治はトークン消費量という面でも有効な可能性あり 4
5. ActiveSupport::Concern ActiveSupport::Concern はクラスからロジックを module として切り出すための便 利機能 # app/models/user.rb class User < ApplicationRecord include Friendable include Subscriptable : end # app/models/user/friendable.rb module User::Friendable extend ActiveSupport::Concern included do has_many :friendships has_many :friends, through: :friendships scope :with_friends, -> { includes(:friends) } end def add_friend(other_user) return false if self == other_user friendships.create(friend: other_user) end def friends_with?(other_user) friends.include?(other_user) end end Rails: 私の好きなコード（3 ）" 正しく書かれた" concerns （翻訳）｜TechRacho by BPS 株式会社 37signals Dev — Good concerns 5
6. Concern の正しい使い方 どのconcern も、ホストとなるモデルの特徴を凝縮した形でキャプチャすべきで あるという点が重要です concerns は本物の「has trait 」や「act as 」セマンティクスが機能する必要があ ります https://techracho.bpsinc.jp/hachi8833/2023_04_04/127023#2 6
7. ActiveSupport::Concern の注意点 複数の Concern が 1 つのクラスに include されたとき、他の Concern の private メソッドが参照できてしまう → private メソッドにも関わらず、どこか ら参照されているか（参照されていない か）を確認するのに手間がかかる module Foo extend ActiveSupport::Concern private def foo = "foo" end module Bar extend ActiveSupport::Concern def bar = foo end class MyClass include Foo, Bar end MyClass.new.bar #=> "foo" 7
8. 委譲 Ruby には Delegator と Forwardable 、 Rails （ActiveSupport ）には delegate がある。 しかし、ここでの委譲は一般的なプログ ラミングテクニックとしてのもの。 特定の public メソッドと、そこから参照 される一連の private メソッドをグルー プ化し、PORO としてまとめる。 # app/models/user.rb class User < ApplicationRecord def subscribe(plan) SubscriptionCreator.new(self, plan).run end end # app/models/user/subscription_creator.rb class User::SubscriptionCreator def initialize(user, plan) @user = user @plan = plan end def run # private メソッド呼び出し end end 37signals Dev — Vanilla Rails is plenty 8
9. 委譲のメリット 実装の詳細を隠蔽できる 委譲先クラスの private メソッドはクラス 外から参照されない class User::SubscriptionCreator def initialize(user, plan) @user = user @plan = plan end def run create_subscription send_notification log_activity end private # これらのメソッドは User::SubscriptionCreator 内でのみ使用される def create_subscription # ... end def send_notification # ... end def log_activity # ... end end 9
10. 委譲のその他のメリット ロジックをイミュータブルなモデルで構成しやすくなる クラス内ではインスタンス変数でパラメータを共有できるため、メソッド間で引 数を省略できる よりコードの見通しが良くなる 10
11. 分割統治の効果（イメージ） Before app/models/ └── user.rb (581 行) spec/models/ └── user_spec.rb (1200 行) After app/models/ ├── user.rb (70 行) └── user/ ├── friendable.rb (90 行) ├── messageable.rb (76 行) : ├── achievable.rb (14 行) └── achievable/ └── granter.rb (45 行) spec/models/ ├── user_spec.rb (156 行) └── user/ ├── friendable_spec.rb (320 行) ├── messageable_spec.rb (195 行) : ├── achievable_spec.rb (39 行) └── achievable/ └── granter_spec.rb (132 行) 11
12. 分割統治の副次的な効果 VCS でのコンフリクトが減少し、解消も容易に テストファイルも Concern や委譲単位に分割可能 AI コーディングツールに優しい（かも） 12
13. まとめ 1. ActiveSupport::Concern クラスからロジックを module として切り出せる 元モデルの特徴を凝集した形で抽出 2. 委譲 特定の public メソッドとそこから参照される private メソッドをグループ化でき る 実装の詳細を隠蔽 13