Rails wayってなんだ？？？

# Rails wayってなんだ
Railsの学習をしている中で
- fat_controllerは避けよう！
- controllerにロジックを書くのは避けよう！
- ロジックはModelに書こう！
  - fat_modelは避けよう！

どっちやねん！！！！！！！と思ったときに、自分もそもそもRails wayをちゃんと理解していないなと感じたので、Rails wayについて調べてからfat_controller, fat_modelについて調べようとなったのでまずはRails wayとはなんぞやを探る記事を書く

## Ruby on Railsとは
[Railsガイド](https://railsguides.jp/getting_started.html#rails%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%8B)

>Railsとは、プログラミング言語「Ruby」で書かれたWebアプリケーションフレームワークです。Railsは、あらゆる開発者がWebアプリケーション開発で必要となる作業やリソースを事前に想定することで、Webアプリケーションをより手軽に開発できるように設計されています。

>Railsは、他の多くのWebアプリケーションフレームワークと比較して、アプリケーションを開発する際のコード量がより少なくて済むにもかかわらず、より多くの機能を実現できます。ベテラン開発者の多くが「RailsのおかげでWebアプリケーション開発がとても楽しくなった」と述べています。

>Railsは「最善の開発方法は1つである」という、ある意味大胆な判断に基いて設計されています。何かを行うための最善の方法を1つ仮定して、それに沿った開発を全面的に支援します。言い換えれば、Railsで仮定されていない別の開発手法は行いにくくなります。

>この「Rails Way」、すなわち「Railsというレールに乗って開発する」手法を学んだ人は、開発の生産性が驚くほど向上することに気付くでしょう。逆に、レールに乗らずに従来の開発手法にこだわると、開発の楽しさが減ってしまうかもしれません。


**Railsの基本理念**
- 繰り返しを避けよ（Don't Repeat Yourself: DRY）
>DRYはソフトウェア開発上の原則であり、「システムを構成する知識のあらゆる部品は、常に単一であり、明確であり、信頼できる形で表現されていなければならない」というものです。同じコードを繰り返し書くことを徹底的に避けることで、コードが保守しやすくなり、容易に拡張できるようになり、バグも減らせます。
- 設定より規約が優先（Convention Over Configuration）
>Railsでは、Webアプリケーションの機能を実現する最善の方法が明確に示されており、Webアプリケーションの各種設定についても従来の経験や慣習を元に、それらのデフォルト値を定めています。デフォルト値が決まっているおかげで、開発者の意見をすべて取り入れようとした自由過ぎるWebアプリケーションのように、開発者が大量の設定ファイルを設定せずに済みます。

## Rails wayってなんなの？
Railsガイドにかかれている内容で気になった部分は以下２つ
>「Rails Way」、すなわち「Railsというレールに乗って開発する」
と書かれている。

>Railsは「最善の開発方法は1つである」という、ある意味大胆な判断に基いて設計されています。
>設定より規約が優先

この記述から
#### 個人の思想を柔軟に取り入れるのではなく、あくまでRailsというフレームワークが提供している方針に則って開発しましょうね。さらば与えられん。

的な感覚がある

でもまだよくわからない

## Kaigi on Rails 2024の講演から探る-1

[RAILS WAY, OR THE HIGHWAY](https://speakerdeck.com/palkan/kaigi-on-rails-2024-rails-way-or-the-highway)

[Kaigi on Rails 2024 Palkan氏による基調講演](https://kaigionrails.org/2024/talks/palkan/)

### RAILS WAYがRAILSアプリケーションを構築する哲学
- 生産性と幸福のための最適化
- 意思決定からの開放（おまかせ）
- スケーラビリティを考慮した設計（スケーラビリティ：必要に応じて、必要なリソースで、必要な速さで実行すること）


RailsをWebアプリケーションとして見たときの役割はWebリクエストに答えること

デフォルトでは３つの工程（Controller->Model->View）を使ってレスポンスを生成する
しかしアプリケーションが成長するにつれてロジックを入れる箱が３つでは足りなくなる

Railsの「おまかせ」は完全ではなく埋めるべき隙間がある->認可、複雑なUI、ワークフロー、AIエージェント


この隙間を埋めようとすることでフレームワークが歪み、生産性と幸福度が下がる

あくまでRailsフレームワークは構造を与えてくれている
RAILSWAYは**導きの星**

### 迷子にならない方法
**Railsを習得し、拡張すること**
- Railsの設計パターンを学ぶこと
- 規約の原則を受け入れる
- Railsの構成要素をあなたのツールボックスにいれる

**Railsを他のものと混ぜるのではなく拡張することが大事**

### 担当分野の分離には新しい抽象化が必要
Railsアプリケーションに新しい抽象化レイヤーを導入する際の４つのルール
- Railsらしい開発者体験とコアコンポーネントとの互換性を提供する
  - カスタムアプリケーション開発者の考えではなくフレームワーク作者の考え方をもつ
- 抽象化レイヤーの間に明確な境界を引く
  - 抽象化レイヤーを分置するためにレイヤードアーキテクチャの原則を参照できる
  - 各抽象化は特定のアーキテクチャレイヤーに属する必要がある
  - データ原則として上から下に流れて、そこで各抽象化は自分より下位の者だけ知ることができる
  - それぞれの装花rあどこまで下位層にアクセスできるかを制限することも可能なので疎結合が実現
    - Presentation
      - Controller
      - Channels
      - Views
    - Application
      - Jobs
      - Mailers
    - Domain
      - Models
    - Infrastructure
      - Adapters(DB, Mail)
      - API clients
- 介入より抽象：コード内で既存の抽象化を見つけよう
- 関心事と複雑さのレベルを分離する

### フレームワークと戦わなければRails wayで成長できることは可能
1. Railsに似た新しい抽象化を導入する
2. 明確な境界を引く
3. 担当分野と複雑性を分離する
4. アプリケーションに属する

## Kaigi on Rails 2024の講演から探る-2
**Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング**

[Railsの仕組みを理解してモデルを上手に育てる](https://speakerdeck.com/igaiga/kaigionrails2024/)

[Kaigi on Rails 2024 igaiga氏による講演](https://kaigionrails.org/2024/talks/igaiga/)

### Rails wayに関わっていそうな部分を抜粋
行為を記録するモデル -> **イベント型モデル**
- Order（注文）
- Shipment（出荷）
- Payment（支払い）

名詞であるモデルに「~する」とつけると行為になるもの

どんなメリットがあるか
1. 適切なイベント型モデルを探し出せると、責務がてきせうなモデルに処理かける
  - 複数モデルにまたがる処理を書きたい問題を解決できる
2. つくられたのはモデルでRails wayに乗った設計方法になっている
  - Rails wayに乗っていると迷いづらく説明も簡単になる
  - できるだけ遠くまでRails wayに乗っていきたい

#### Service層を入れるのはできるだけやめてほしい
Railsの特徴
- Railsはレイヤー分割を減らして記述するコード量を減らす設計
- レイヤーとはルーティング、コントローラー、ビュー、モデルなど
- モデルが担当する仕事
  - ORマッパー
  - バリデーション
  - コールバック
  - フォームオブジェクト
  - ビジネスロジック置き場
  - **いろいろな機能を併せ持った密結合な設計** -> Rails

密結合な設計によってメリットがある
- 1箇所に書いたコードが複数の役割を担当できる
- Railsは一緒のクラスに集めると都合がいいものを上手に集めている
- その結果コード量、クラス数、ファイル数を減らせる
  - 高い生産性が得られる
  - 登場人物を減らすことで全体の把握を容易にするメリットがある

このようなメリットを得るために下のような密結合による弱点は受け入れている
- 複数の役割を持つコードが役割ごとに分岐するとしんどい
- 変更時の影響範囲が増える

代わりにイベント型モデルを探したり、POROのようなシンプルな考え方でチームで育てていく

#### モデルを分割するタイミング
`FatModel`という言葉があるが、太っているか否かの判断するのがいいか？
- コード行数？ -> 違うと思う
  - メソッドの数が多くてコード行数が多いのは気にしなくていいと思う
- じゃあなにを持って太っている？
  - 「そのまま書き続けるとしんどくなるとき」かつ「そのタイミングで良い分割方法があるとき」
    - バリデーションを条件分岐したくなったとき

このあとフォームオブジェクトの使い方の説明などある

---

## 技術記事から探る
[Rails Wayに沿ってシンプルなREST APIを設計する](https://tech.giftee.co.jp/entry/2022/09/13/000000)

[Ruby on Rails×クリーンアーキテクチャを1年半に渡って本番運用して得られた学び](https://zenn.dev/pharmax/articles/4cdc3e2d29e41a)


## 共通している（と思った）こと → まとめ？
- Railsというフレームワークと喧嘩せずに、Railsの仕組み（規約）をうまく利用しながら弱いところを補っておこう
- Railsのいい部分をなくさずに、うまくRails wayに乗って楽して行こうぜ
- そのほうが開発しやすいし、将来的な恩恵も大きいよ
- でもそのためにはちゃんとRailsを理解してチームでも共通認識を持とうね

こんな意識を持てるようにはなった
**けど明確にRails wayの答えを言語化できるようにはなっていない**

そもそも自分がRuby on Railsというフレームワークの知識が足りていない
知識（武器）が足りていないから理解しようにも理解できない部分もたくさんある

現状「Ruby on Railsを使う上で大事な思想」のようなものがわかったことが収穫

今後知識を身に着けて武装して「Rails way」をうまく言語化して表現できるようにしたい

# 参考記事
勉強になりました。ありがとうございます！
https://tech.giftee.co.jp/entry/2022/09/13/000000
https://zenn.dev/pharmax/articles/4cdc3e2d29e41a