Ruby on Rails と Spring に実務で携わっての開発体験の比較
RailsエンジニアとしてWebアプリケーション開発を続けてきた自分が、 はじめて本格的に Springのプロダクトに参加しました。
この記事では Rails, Spring のフレームワークの解説はせず、 Rails と Springをどちらも実務で使ったうえで、「結果的にコードを書くうえでどんな快適さを感じたか？」を比較します。
言語やフレームワークの思想批評ではなく、開発体験の個人的な実感として読んで頂けますとありがたいです。
Rails の開発体験
1. rails console による動かしながら理解できる強さ
Rails には Rails Console と呼ばれる、アプリケーションを対話的に操作できる実行環境があります。
Rubyでは、標準でもirbという対話的にRubyを実行できるツール (REPL) が備わっていますが、Rails Console の特徴は、単なるコードの実行環境としての REPL ではなく、Rails アプリケーションそのものを読み込んだ状態で起動される点にあります。
Rails Console 上ではモデルやサービスのメソッドを直接呼び出して、データベースの値も含めて実際のコードの振る舞いを確認することができます。
Spring にもApplicationRunnerなどアプリケーションコンテキストを直接起動する手段は存在しますが、 Rails Consoleのように対話形式で実行でき日常的な調査・検証手段として文化的に定着している点は Rails 特有だと感じました。
2. 豊富な標準メソッドと DSL による効率的な実装
Rails では
- モデルまわりの CRUD
- バリデーション
- association
- routing
- migration
- ActiveSupport の便利メソッド
- ruby言語自体の標準メソッド
- ..etc
など、 短いコードで実装できる手段が揃っています。
これらの抽象化により、アプリケーションの振る舞いそのものの実装に集中しやすい点は Rails の強みです。
結果として、 機能追加や仕様変更を素早く回しやすく、 短いサイクルで開発を進められるフレームワークだと感じています。
Spring の開発体験
1. IDE が提供するコードリーディングとリファクタリング時のサポート
Spring は IntelliJ IDEAなどの高機能 IDE を前提に開発することで、依存関係や呼び出しの流れが把握しやすく、型レベルでの破綻も事前に見つけやすいと感じました。 「読む前に、壊れそうな箇所を IDE が示してくれる」という感覚があり、リファクタリング時の心理的負担が軽くなる印象があります。
- 呼び出しグラフの追跡
- 参照元・定義元へのジャンプ
- Rename / Move / 抽出のリファクタリング支援
- 未解決メソッドや型不整合を事前に検出
コードの表層を読む前に、IDE が依存関係や型設定を表示することで、コードの読み書きを強力に補助します。
その結果リファクタリング時で抜け漏れがないかなどを探す実務上のコストや、typoや命名変更漏れというミス等をしていないかという精神的コストも実装の段階で大きく減らすことが可能です。
※補足
Java言語 は nullable な仕様が前提なので、静的型付け言語ではありますが Null Pointer による例外は発生しうるという悲しみはあります。 個人的には、静的型付け言語 & IDE での静的解析を最大限に活かすなら、Null 安全に開発できる言語だとより体験が良いと感じる場面が多々ありました。
2. レイヤー分離による責務単位の把握とコード構造の安定化
Spring のコードは、
- Entity
- Repository
- Service
- Controller
- Dto / Dta
- Exception
- ..etc
といった責務ごとの細かなクラスの分割を前提とします。
分割されたクラスでそれぞれの責務を果たすことに集中でき、かつフレームワークによって依存関係が解決され注入される (DI) ことでアプリケーションとして動作するようになります。
このような分割は単一責任の原則に基づいて考えられていて、どこで何をしているかはアプリケーションがスケールしても理解しやすい構造を保ちやすいです。
もちろん Entity, Service などで適切な責務の分離を意識した実装を促すわけであって、この点を意識せずにロジックを実装してしまった場合は Spring でもビジネスロジックが散見する、もしくは特定のクラスに偏るなどの実装は起こりえます。
これは、あえて高凝集であることを是とする Rails の Active Record モデルとは対照的です。
Railsの設定より規約や、Active Record モデルを含めた高凝集に実装していくことの良さなどについては、弊社の id:morihirok の資料で深堀りされているのでそちらもぜひご参照ください。
Ruby on Rails の楽しみ方 - Speaker Deck
結論：Rails と Spring の開発体験は快適の源泉が違う
Rails は、Rails way に則り、動かしながら作れることで「素早く形にできる」開発体験を提供してくれます。
Spring は、DI と明確なレイヤー分離、そして IDE の型ベースな支援により、「変更や分業を前提にした設計を安心して進められる」開発体験を提供してくれます。
どちらが優れているかという話ではなく、 プロダクトの性質、フェーズ、人数、変更頻度といった条件によって、どこを重視したいかによってそれぞれ適切な選択肢が異なるとは感じました。
あくまで私個人の感想ですが、 Rails はリリース頻度が高く、素早く改善を回していくプロダクトではとても相性が良いと感じます。
少人数での開発や、仮説検証を高速に回したいフェーズでは特に効果的な選択肢になると思います。
一方でSpring は、DI を前提とした疎結合な設計を自然に取り入れやすいため、多くのエンジニアが同時に開発するような大規模プロジェクトほど真価を発揮する印象があります。
複数の開発が並行しても他の箇所に影響が出にくく、おのおのが自分の責務の実装に集中しやすい環境を提供しやすいです。
最後に二つのフレームワークを行き来した経験によって、 コードを読む／設計に迷うといった場面で比較軸を持てるようになりました。
その違いを体験として理解できたことは、自分にとって価値のある学習経験でした。
