* これはすろっくさんの個人的な見解なのでなんかまさかりとか投げないでください。

 

会社のSlackで「最近のRailsにはserviceクラスがある」という発言があったので、そこに関して僕の見識的なの書いてみる。

Railsを使ってそろそろ6年くらいかな。いろんなドキュメントを読んでてでてくるデザインパターンとかMVCへの認識とかなんですけど、僕は2011年以前がどういう歴史を辿ってきたのかを知らないままアプリケーションエンジニアやってたので、2011年以降のものしかあまり興味なかったです。最近の新卒さんがデータセンターいったことなくてAWSとか知らないのと同じです。

Railsって基本MVCっていうデザインパターンで作られてるって言われてるフレームワークです。なんかRailsのMVCは本当のMVCじゃないよっていっている人もいるくらいなので、デザインパターン的な話は一旦置いておきます。この辺はvimとかemacsみたいな宗教論争に近いものを感じます。WikipediaのMVC項目みればだいたい概要はつかめるので、だいたいそんなもんなんだでいいと思います。僕はいくつかの会社でRailsまたは違うフレームワークのMVCを見てきましたが、同じ解釈をしている会社は一社もなかったです。だいたいなんかいじくりまわしてますし。MVCそれはみんなの心の中にっていう感じで見てました。

前置き終わり。

僕は会社にいってRailsで一から作らせてもらえることって結構稀有ですしその場合だいたい一人でやるしかない場合がほとんどです。あと一人で物をつくるときかな。

Rails5になった時点でappsの中みるんですが「えーこれデフォルトでいらんやろ」っていうのがいくつかありますよね。active jobはまあ、あってありがとーくらいですがchannel……せめて任意で選べるとかないのかな。rails new なんとか–excludeみたいなのほしいなーって。あるかもですね。

僕はだいたい共通で決めてるのって「Railsの中にないもんは使わないこと」ってことくらいですね。個人的にActive Jobは一番ありがたかったです。rescueもdelayed_jobも同じインターフェイスで使えますし。

そこで最初のに戻るんですけど僕はRailsでServiceクラスをわざわざディレクトリつくってそこにファイルつくって記述するの、やだなーって思う派です。だってappsの下にserviceとかないし。

対案としてはRails5からできたApplicationRecordとかじゃダメなのかなーとは思います。さすがにあれはApplication:Baseを引き継いでいるだけなので。

Railsさん、柔軟ななんでもありフレームワークですが、もともとないもの作るとアップグレードに相当苦労するので、ルールにのっとってつかいたいなーって、それこそレールにのって使っていきたいなーと思ってます。

おわり！