言うほど使いやすくないRuby on Railsの「良いところ悪いところ」

2019年3月26日 15:40

初めまして。グラムにて、『Jobgram（ジョブグラム）』の開発・運用をしているWebエンジニアです。
あとは、月間400万UUのインフラをやったり、サイトの構築とか運用をやったりしてます。

得意な言語はJava。最近は、RubyやったりNodeやったりAWSの構築やったりが主な仕事のフルスタックエンジニアです。

弊社のWebシステムでは「Ruby on Rails」を採用しています。
私自身、グラムに入社するまでRubyは触ったことがありませんでした。

今回のnoteでは、一通り業務をやってみて感じた「Ruby on Railsの良いところ悪いところ」を上げてみたいと思います。

Ruby on Railsのいいところ

■ generateのscaffoldで管理画面の枠を作れる

rails generate scaffold　〜

もしくは、

rails generate scaffold_controller

のように、Railsではコマンドで一気に「一覧・新規・編集」の「ルーティング・画面・コントローラ」のガワを用意してくれます。

これがなぜ便利かというと、Webページに新規で画面を追加するほとんどの場合で、管理画面と新規テーブルの作成が必要。
そうした際、このコマンドで必要なファイルをほとんど用意してくれるので大変便利です。

■ ローカルでの起動が楽

Railsは、「rails s」コマンドで起動でき、ローカルでの確認がすぐにできるため開発がしやすいという特徴があります。

今でこそPHPの「Laravel」やJavaの「Spring Boot」、「Play Framework」など、HTTPサーバーを別に立てずに実行できるものが増えてきているがそれを早い段階でやったのが「Ruby on Rails」だと思います。

個人的には、Railsが流行りだした一番の理由なのではないかと考えています。

また、Railsが国内で流行りだした頃はPHPならApache、javaならApache TomcatなどのHTTPサーバーを別で用意しないとブラウザ上での確認ができず、当時は、それらをインストールして設定してい起動まで持っていくのが一苦労でした。

少し話が脱線してしまいましたが、コマンドのみで起動できるようになったのは結構な革新的な方法だったのではと考えています。

■ システムが肥大化するとRails特有のメリットが薄れてくる

保守運用フェイズに入ると、新規で画面やテーブルを作成することより既存画面を修正することが多くなります。

そうなるとどうしてもコントローラやViewが肥大化してきてメンテナンス性が落ちたりします。

それらを整理するためにtrailblazer（サービス層）を導入したり、ActiveDecorator（viewやヘルパーまわり）を導入したりして改善しています。

しかし、これらにつきまとうのは公式の提供しているgemではないために開発が止まる可能性があるということ。それならば、標準で用意されているSpringなどを採用しておくべきかと考えてしまいます。

ですので、初期段階では「Ruby on Rails」のほうが扱いやすいが、その段階をすぎるとメリットが薄れてくると感じているのです。

■ 文法や記法の自由度が高い

each文などで、{}やdo〜endなどいくつかの書き方があります。

個人の好きに書くことができるのは一見メリットのように感じますが、チームで一つのプロダクトを作り上げる場合だと、書き方を統一することが経験上ベターです。なので、色々な記法があっても結局は1つの書き方になってしまうので、そこまでの自由度は必要ないかもしれないと感じています。

そして、個人的にはRubyやNodeに多いワンライナーや3項演算子はあまり好きではありません。

単純な処理を省略して書くのは大変便利ではあります。しかし、ワンライナーにこだわって処理が複雑になると結局はメンテナンス性が落ちてしまうことが少なくなかったためです。

- - - - - -

何が言いたいのかというと、Ruby on Railsは巷で言われているほどすごく使いやすいわけではないと感じている、ということ。

良いところだけ見ずに、悪いところまで見てRuby on Railsをプロダクトに採用してほしいです。

以上、Rubyのお話でした。

この記事が気に入ったらサポートをしてみませんか？