はじめましてコンさん、さようならコンさん、

わたしとRailsのConcernの物語

Transcript

1. はじめましてコンさん、 さようならコンさん、 ２０25/04/26 ぼとふね X: @botofune
2. コンさん ＝ Concern
3. これからお伝えすること Concernの活用方法
4. Concernを使うと、 Railsのお作法に則して、 機能を整理できるよ。 まとめ
5. まとめ ただし、、、
6. わたしと コンさんの 物語 わたしと コンさんの 物語
7. わたしとコンさんの物語 登場人物 わたし コンさん
8. 第一話 はじめましてコンさん、
9. 第一話 はじめましてコンさん、 BCD は似てるけど微妙に違うテーブルの感じ。 ・ カラム数やカラム名が異なる ・ 共通のカラムもある こんなアプリを作っていました。
10. 第一話 はじめましてコンさん、 こんな状況でした。 似てるテーブルたちそれぞれに、 コントローラーや テストを作っていた。 共通化すると、 微妙な差異の対応によってコードが カオスになるかも、 と思っていたので。 でも、 「これまとめられそうだな…まとめられないかな…。」 と思いながら同じような内容のコントローラーやテス トを作っていく内に、 精神的にツラくなってきた。
11. 第一話 はじめましてコンさん、 ようAIさん、オレやっぱ共通化するわ。 どうやって共通化したらいいんだい。 Concern紹介したるわ。
12. 第一話 はじめましてコンさん、 そして、 わたしはコンさんと出会った。 コンさんについて軽く調べたら、 どうやら重複するコードを まとめるのが得意って主旨の説明を複数読んだ。
13. 第一話 はじめましてコンさん、 コンさんは最初からそこにいた。
14. 第一話 はじめましてコンさん、 Before カラム数とかカラム名が少し違うテーブルが 複数ある状態。
15. 第一話 はじめましてコンさん、 After
16. 第一話 はじめましてコンさん、 第一話 はじめましてコンさん、 完 こうして、 わたしとコンさんは、 仲良く幸せに暮らしました。
17. 第二話 さようならコンさん、
18. 第二話 さようならコンさん、 同じような内容のコントローラー群を見て、 わたしは思った。
19. 第二話 さようならコンさん、 「テーブルごとの値は、 モデルに書くべきだろう」 と。 そしたらコントローラー残るのは includeのみになる。 であれば、 単一のコントローラーに処理を書いて、 テーブルごとの値は モデルから読めばいい。
20. そしてそれは上手くいった。 第二話 さようならコンさん、
21. 第二話 さようならコンさん、 完 こうして、 わたしのリポジトリから、 コンさんがいなくなった。 第二話 さようならコンさん、
22. 最終話
23. ひと夏の幻のように、 わたしの前からいなくなった コンさん。 「コンさん、 わたしはアナタをもっと知りたい…！」 そう思ってしまったわたしは、Railsの公式ガイドへ 走った。 最終話
24. 最終話 https://guides.rubyonrails.org/getting_started.html#extracting-a-concern Productモデルから、 通知に関する機能を、
25. 最終話 https://guides.rubyonrails.org/getting_started.html#extracting-a-concern Concern に移行している。
26. ・ Concern はコードを整理するのに有効である ・ Concern はコードの再利用性を高める なのでコンさんが活躍できるのは、 コードの重複の解消だけじゃない。 なんだったら、 機能の整理が本分なのかもしれない。 最終話 https://guides.rubyonrails.org/getting_started.html#extracting-a-concern Concerns are a great way to organize features of your Rails application. As you add more features to the Product, the class will become messy. Instead, we can use Concerns to extract each feature out into a self-contained module like Product::Notifications which contains all the functionality for handling subscribers and how notifications are sent. Extracting code into concerns also helps make features reusable. For example, we could introduce a new model that also needs subscriber notifications. This module could be used in multiple models to provide the same functionality.
27. コントローラーが fat になった ↓ モデルに諸々移動させた ↓ モデルが fat になった ↓ モデルの整理にコンさんが必要だ 最終話
28. 最終話
29. コンさんに以下をやってもらった。 ・ 機能の整理 ・ 重複したコードの解消 ・ Viewで使わないけど定義していた 　helperメソッドの代替 最終話
30. こうして、 わたしとコンさんは、 仲良く幸せに暮らしました。 最終話
31. わたしと コンさんの 物語 わたしと コンさんの 物語
32. Concern の活用方法まとめ ・ 機能ごとの整理 ・ 再利用性の向上
33. ただし、Concern の評価はあんまり。。。 ・ X ・ 記事 ・ discuss.rubyonrails.org ・ Hacker News で、 「あんまり評価」 を複数見かけました。
34. 「代わりに Service Object パターン 使おうぜ。」
35. Service Object の場合
36. ・ バリデーションとか、 コールバックとか、 　 メソッドとかが、 競合するリスクがある ・ テストが書きにくい ・ コードを分散しているだけで、 　 責務を分離できていない ・ 「継承よりコンポジション」 に反する Service Object と比較して、 Concern が あんまり…なポイント
37. ← モデルに includeすると、 モデル.new が上書きされる。 複数のConcernをincludeした場合、競合リスクが上がる。 Concernにバリデーションとかコールバックとかも書けるので、 それも競合するかも。 バリデーションとか、 コールバックとか、 メソッドとかが、 競合するリスクがある
38. モデルに Concern を include ↓ モデルにメソッドが生えたり、 バリデーションなどが追加される。 ↓ モデルが fat になる ↓ Concern 自体はテストできないので、 モデルのテストで concern のテストを書く。 コードを分散しているだけで、 　 責務を分離できていない テストが書きにくい ＆
39. Concern を include すると、 モデルの一部となる ＝ 実質的な継承 Product モデルは通知機能を持っていない、 使ってるだけ。 ＝ 継承ではない 「継承よりコンポジション」 に反する
40. Service Objectパターンで、 Product モデルの新規機能開発を想像してみよう。 「メールの他にLINEで通知する機能を実装するなら？」 「メールクラスと LINEクラスを作って、 それぞれを 呼び出すクラスの、 計３クラスを作る？」 「ディレクトリはどうやって分ける？」 「メールと LINEのクラスの上の階層に、 呼び出すクラスを置く？」 「他のモデルで同様にクラスをつくることになったら、 Product の階層と合わせる？」 「ルールを設けたとして、 それを守り続けられる？」 「ルールの柔軟性はどうする？厳守する？例外を認める？」 「ルールやコードを忘れたとき、 ディレクトリやコードが辿りやすく、 すぐに思い出せそう？」
41. ここで思いませんか。
42. 「ルールを決めるのって大変そうだな」 と。 「私はルールを決めるべきじゃない。 開発をするべきだ」 と。 「どうせ何事も一長一短だし、 もう Rails が定めたルールでいいんじゃね」 と。 「Rails のお作法に則した方がいいな」 と。
43. 一旦はモデルに諸々書いちゃっていいんじゃないでしょうか。 大丈夫です。 Skinny Controller, Fat Model っていう言葉があります。 「わたしはモデルを fat にしているのではない。 ゴージャスにしているのだ」 と自分に言い聞かせましょう。 それでも大きくなり過ぎたモデルに頭を抱えるときが来るかも しれません。 そのときに、 機能を整理しましょう。 我々人類は、 具体的にどうすればよいのだろうか。
44. Railsのお作法に則して、 機能を整理するには、 どうしたらいいんだっけ？
46. はじめましてコンさん、 さようならコンさん、 ２０25/04/26 ぼとふね X: @botofune
47. 参考 Getting Started with Rails — Ruby on Rails Guides https://guides.rubyonrails.org/getting_started.html#extracting-a-concern Put chubby models on a diet with concerns – Signal v. Noise https://signalvnoise.com/posts/3372-put-chubby-models-on-a-diet-with-concerns Helping devs understand concerns faster - A May Of WTFs - Ruby on Rails Discussions https://discuss.rubyonrails.org/t/helping-devs-understand-concerns-faster/74619 I disagree - I think we're talking about two competing philosophies. DHH / stand... | Hacker News https://news.ycombinator.com/item?id=7438038 Buckblog: Skinny Controller, Fat Model https://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model 人は Fat Model を恐れサービスを求め ドメインモデルは貧血に至る - @ledsun blog https://ledsun.hatenablog.com/entry/2022/04/08/000748