PHPerがRuby(Ruby on Rails)を約3年経験した結果

はじめに

Hubbleでバックエンドエンジニアをしている @power3812 です。オブジェクト指向大好きマンで、神クラスを作れないかと模索の日々です

今回はHubbleに転職して約3年経つので、振り返りの意味も込めてPHPerで一切Rubyを触ったことがなかった僕が、約3年Rubyを使った所感を書こうと思います！

筆者のサマリ

大学は電子情報で大学院は技術経営を学んでしました。大学院は21卒なので21卒で就活をして、サマーインターンでWeb開発を知り、PHPと出会い、Web開発の沼にハマりました。

しかし、大学院にいるよりも早く実践を積みたいと、大学院を中退し、20卒としてソーシャルゲーム会社に就職しました。
ソーシャルゲームということで、PHPをそのまま経験、その後受託系の会社に転職し、そこにはPHPerKaigiの運営にも携わっている方にPHPの真髄を叩き込まれました。

その後、自分が完全未経験のRubyで開発しているHubbleに入社しました。

結論

RubyもPHPも本質はなにも変わらないです。
これはその通りと言えば、その通りのことなんですが、どちらも動的型付けでオブジェクト指向なので書き方や若干の仕様が違うだけで方言違う程度の差でしか感じなかったです。

重要なのはオブジェクト指向を理解できているかどうかで、PHPで培った力はRubyでも全然横展開することができました。

感じた違い

言っても方言程度には違うので軽く感じた違いを書きます。

Laravelにあった機能がない

LaravelはRailsインスパイアなのでかなり似ています。
例えば、Railsだとrails g scaffold Postsを実行すると以下のコントローラーが作成されます。

class PostsController < ApplicationController
  def index
  end

  def show
  end

  def new
  end

  def edit
  end

  def create
  end

  def update
  end
end

Laravelでも、php artisan make:controller PostController --resourceと実行するとほぼ一緒のactionが作成されます。

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class PostController extends Controller
{
    public function index()
    {
    }

    public function create()
    {
    }

    public function store(Request $request)
    {
    }

    public function show(string $id)
    {
    }

    public function edit(string $id)
    {
    }

    public function update(Request $request, string $id)
    {
    }

    public function destroy(string $id)
    {
    }
}

他にもORMがメソッドチェーンでどんどんつなげる方式だったり、pluckでwhereすると、プレスホルダーが逼迫するなどかなり性質が似ています。
しかし、LaravelにあってRailsにない機能で歯がゆい気持ちも感じました。

FormRequestがない

これが一番あったらいいなと感じた機能になります。
LaravelにはFormRequestというRequestがコントローラーに渡される前に、本当にそのRequestが正常かバリデーションするミドルウェアが存在します。

フレームワークには下記のように大きく2種類のバリデーション方法があります。

1. Request -> Validate -> Controller -> Model
2. Request -> Controller -> Validate -> Model

Laravelでは1方式で、Railsは2方式になります。
これは設計思想の違いなので、なんとも言えないのですが、Laravelを最初に触ってしまった自分的には1方式の方がController以降に不正値が入り込む余地がほぼないので安全に開発できるので、若干の歯がゆさを感じました。

Route Model Bindingがない

LaravelにはRoute Model Bindingという機能があります。
これは例えば下記のようなURIの場合、

/api/v1/posts/postId

Controller側で下記のように書くとORMでfindしなくて事前に取ってきて存在しなければ404にしてくれる機能です。

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class PostController extends Controller
{
    public function show(Post $post)
    {
        return $post;
        // 下記のように書かなくて良い
        // $post = Post::query()
        //           ->where('id', $request->input('id'))
        //           ->firstOrFail();
    }
}

この機能に慣れると、毎回before_actionでfind文書かないといけないのかという気持ちなりました。

Railsで良かった点

逆にRailsの方で良かった点もあります。

そこまでアーキテクチャの縛りが強くない

設定より規約というスタンスの最低限のフルスタックフレームワークであることで、柔軟にアーキテクチャも変えることができるのが魅力に感じました。
例えば、service層を作ってfat modelを回避するのか、はたまた、あえてfat modelのままで行くのかなど時々の設計は使い手側に任されているのが柔軟性であり、メリットデメリットどちらにでもなるのが魅力に感じました。

比較的プログラミング初心者でも書きやすい

これもメリットでもデメリットもあるのですが、見様見真似で誰でもコード自体書きやすく、アーキテクチャも簡素でデータの流れも複雑ではないなと感じました。
例えば、Laravelだとroute model bindingなどの便利なミドルウェアがあることで処理が隠蔽されすぎて動作しても実際どんな処理をされているか分かりにくい場面があるのですが、Railsは簡素であることでコードがベタ書きになるので、データの流れが追いやすくかったり、初心者でも書きやすいだろうなと感じました。

まとめ

今回は入社して約3年経ったのでRubyの所感について書いてみました！

3年経ってもPHPほど流暢に書けている実感はないのでまだまだ精進の日々だなと感じました

今度はもっとRailsっぽい記事をかけるようにします！