Railsでのフロント開発は？テストはなに使ってる？RubyKaigiのアンケート結果まとめ
Rubyが誕生して30年が経ち、Ruby on Railsが世の中にでて約20年が経ちました。スタートアップのベンチャー企業から、数百万件のトラフィックを捌く大規模サービスまで、幅広くRuby / Railsが利用されています。
しかし、長年、使われてきている言語やフレームワークだからこそ、開発をするうえでの選択肢も数多くあり、技術選定に頭を抱えることもあるでしょう。開発当初に決めたことで、今も苦しめられている人がいるかもしれません。う、頭が……
そこで、今回はRubyKaigiに来ているRubyistの方たちに、開発についてのアンケートを取ってみることにしました。note社もサーバーサイドをRuby/Railsでほとんど開発しているので、参考になることがあればなと。以下が、RubyKaigiの3日間で行われたアンケートの内容です。
1日目：テストフレームワークはなにを使ってる？
RSpec
Minitest
その他
2日目：Railsのフロント、どうしてる？
分離
asset pipeline
Hotwire
3日目：YJITでパフォーマンス上がった？
あがった
変わらない
使ってみたい
では、ここからアンケートの結果と回答者の感想を、1日目から紹介していきたいと思います。
ちなみにアンケートは基本的には、個人ではなく企業での利用という観点で回答してもらっています。（あくまで基本的にはであり、個人として回答している方もいました）
1日目：テストフレームワークはなにを使ってる？
やはりRSpecが圧倒的に多い結果となりました。続いてMinitest、その他はほとんどなしという結果に。弊社としても「RSpec以外を使ってる人の意見を聞いてみたい」ということで、今回この質問を採用しました。
『RSpec』についての意見
会社でも個人でもRSepcを使っています。
RSpec以外を使ったことがない。APIのモック書いたりすることを考えるとやっぱりRSpecかな。
RSpec一択。周辺ライブラリも揃ってるし、良い意味で枯れている。Minitestはチュートリアルで触ったくらいかな。
上から読んでいくと文脈としてわかりやすいのが私の好み。
逆にRSpec以外を使って業務している人の話を聞いてみたい。
『Minitest』についての意見
gemを開発しているのでMinitestを使うことが多い。
SinatraでAPIをつくったときのプロダクトではMinitestを使っていた。軽量で書きやすくてSinatraには合っていた。
速度が速いので、自分で技術選定ができるプロダクトはMinitestを使っている。
単純にRSpecよりもわかりやすくて好き。RSpecは人によって書き方が大きく変わって冗長になりやすい。
『その他』についての意見
フロントエンドエンジニアなのでサーバーサイドのテストがよくわからず。
自分がtest-unitのコミッターなので。
2日目：Railsのフロント、どうしてる？
2日目のアンケートは、フロントエンドの開発についてです。
Webサービスを開発する際には、スモールスタートの速度重視でフロントのフレームワークを使わない選択肢もありますし、先を見越して最初から分離する道を選ぶことも考えられます。
アンケートを回答した人の中には、「分離している途中で混同していて辛い……」という方も多くいました。
『分離』についての意見
RailsはAPIのみでフロントはNext.jsを使っています。
asset pipelineから移行して、Nuxt3系にしました。まだサービス開始から1年くらいなので、大変だったけれど移行にそこまで時間はかかりませんでした。
asset pipelineからNext.jsに移行中です。サービスが大きなってくるとasset pipelineはビルド時間が長くなって、開発体験を損ねる可能性があります。
Next.jsに移行してもビルド時間との戦いにはなると思いますが、まずはサーバー側とフロント側で問題を切り分けることから始めることにしました。
移行途中です。今、半々くらいなので一番つらい時期です。ただ、開発当初はエンジニアが私一人だったので、最初から分離して開発するのは厳しかったと思います。一人でも素早く開発をスタートできるので、asset pipelineの恩恵は大きかったです。
『asset pipeline』についての意見
長年続いているサービスなので、現状から他に移行するのはかなり難しい。
スモールスタートで始めるには良い。ただ、サービスを拡大する段階で問題も大きくなっていく。専任のフロントエンドエンジニアがいるのであれば、最初から切り分けるのをおすすめしたい。
Railsの強みを活かして素早く少数で開発するのであれば、asset pipelineがなんだかんだ一番良さそうです。むしろ、最初から分離するならRuby / Rails以外の選択肢を考えたほうがいいと思います。
『Hotwire』についての意見
プロトタイプをつくるときは、Hotwireを使うようにしている。今までのRailsで一番良い体験。社内用のサービスなど小さいものを早く動かしたいのであれば、Hotwireでとりあえず作ってしまうのはあり。
DHHが好きなので、彼が作ったものを推していきたい
業務で使っています。SPA風のサイトがサクッと作れるので、管理画面系や運用があまり必要ない受託系の開発にはかなり向いています。最小工数で成果を出したい人にはおすすめ。フロントエンドの開発に力を入れたいのであれば別の選択肢が良いとハッキリ言えます。また、改修が多く入りそうな開発であれば要検討です。
3日目：YJITでパフォーマンス上がった？
最終日はYJITのパフォーマンスについてです。弊社もYJITを利用して、レイテンシが約20%改善しました。YJITオプションをONにするだけでいいのは、手軽で最高です。Rubyの進化に感謝。
『あがった』についての感想
計測してハッキリと性能があがった。
オプション変更だけで変えられるのは本当にありがたい。本番環境に問題がなさそうであれば、「とりあえず変えてみる」でOK。
前々からRubyKaigiで言われていたし、使わない手はない。
『変わらない』についての感想
サービスがまだ小さいので、それほど大きな変化はありませんでした。
変えただけで計測していないので。
『使いたい』についての感想
Rubyのバージョンが2系からあげられていないので、使うことができない。
自分としては早くやりたいのだけれど、会社の方針的に後回しになっている。検証するチームの人数も足りない。
自分の思想と会社の方針、プロダクトの大小など、様々な条件によって変わる
回答されている方の中には、「自分だったら〇〇だけれど、会社だったら△△かな」と個人と企業での違いに悩まれる方もいました。自分が好きな技術を使うことはもちろん大切なことですが、会社のフェーズやメンバーなどによって、開発環境は左右されるのだなと改めて実感しました。
現状、note社はこのままRuby / Railsで開発を続けていく予定なので、様々なエンジニアの方の意見を聞いて議論しながら、よりよいプロダクトを創っていければいいなと思っています。
▼ RubyKaigiのアフターパーティーを行います。note社からはテックリードが登壇するのでぜひご覧ください。
▼note社の技術記事が読みたい方はこちら