2021年12月9日
プログラミング
モデルに書いていたメソッドをPOROに切り出してみた!
はじめに
この記事は新しい技術にチャレンジし続けるpalanのアドベントカレンダーDay9の記事です!
昨日は「社内のFigma勉強会について紹介します!」についての記事でした。
今回はモデルに書いたメソッドをPOROに切り出してみた話をします!
背景
今回のテーマの背景に、scriptタグに構造化データを動的に埋め込みたいという実装がありました。構造化テーマとは、検索エンジンがページの内容を理解しやすくするためのもので、ハッシュをjson形式に変換したものをscriptタグに埋め込むことで認識されます。構造化データの一部を示したものが以下になります。
この記事では一例として以下の構造化データが本の情報を表しているという仮定のもと、記述していきます。そのため、以下の構造化データはbooks/showなどで表示されるものと考えていただければと思います!
books/1の構造化データ
{ '@context': 'http://schema.org/',
'@type': 'Book',
'title': 'id1の本',
'description': 'めっちゃ面白い'
'value': 1
}
さて、これをデータに応じて動的に変更してscriptタグに埋め込もうとした時に、対応するメソッドをどこに書こうかと考えることになりました。
1、helperを使う
まずはviewに埋め込むものだしとりあえずhelperに書こう!と思い以下のようhelperに書いてみました。
books_helper.rb
def make_book_structured_data(book)
{ '@context': 'http://schema.org/',
'@type': 'Book',
'title': book.title,
'description': book.description,
'value': book.id
}.to_json
end
こちらですが、もちろん問題なく表示されるものの一点問題がありました。それはテストが書きづらいことです。
正しく表示させないと検索エンジンに読み取ってもらえないためテストは必須なのですが、helperのテストはあまり一般的でもないためいい選択肢とは言えずhelperの選択肢は却下しました。
2、modelに書く
次の選択肢として、テストをしやすいという観点からやはりmodelにインスタンスメソッドとして書くのが無難かなと思い、modelに書いてみました。
book.rb
def make_book_structured_data
{ '@context': 'http://schema.org/',
'@type': 'Book',
'title': title,
'description': description,
'value': id
}.to_json
end
この形だと確かにテストも書きやすいためここで終わりでも良さそうかなと思いましたが、この実装でも問題点はありました。それはモデルが大きくなりすぎてしまうことです。すでにメソッドが多く書かれている中で行数の長い上に(実際の構造化データはもっと行数が長い)、構造化データのための用途以外に使い道がないメソッドをモデルに書くことでbookモデルが大きくなってしまうのはあまり良いのではないのではないかと思い、別の方法を模索してみることにしました。
そこで選択肢としてPOROが浮かび上がってきました。
POROとは
POROとはPlain Old Ruby Objectの略で、Active Recordなどを継承していないクラスを作成するものになります。今回はPOROに構造化データの処理を切り出すことでテストの書きやすさは保ったまま先ほどまでの問題点を解消することにしました!以下が構造化データ用のクラスとメソッドをこのクラスに切り出したものになります。
book_structured_data.rb
class BookStructedData
attr_reader :book
def initialize( book:)
@book = book
end
def make_json
{ '@context': 'http://schema.org/',
'@type': 'Book',
'title': title,
'description': description,
'value': id
}.to_json
end
end
これによって構造化データを呼び出したいときはBookStructedData.new(book: @book).make_json
と書くことになります。
なお、テストに関しても以下のようにbook_structured_data_spec.rbを用意してモデルのインスタンスメソッドのテストと同じように書けば良いため、テストの書きやすさも確保できています。
book_structured_data_spec.rb
require 'rails_helper'
RSpec.describe BookStructedData, type: :model do
describe '#make_json' do
let!(:book) { create(:book, title: 'タイトル', description: '本文') }
let!(:structured_data_hash) { { '@context': 'http://schema.org/',
'@type': 'Book',
'title': 'タイトル',
'description': '本文',
'value': job.id } }.to_json
subject { BookStructedData.new(book: @book).make_json }
it do
expect(subject).to eq structured_data_hash
end
end
end
以上のようにPOROにメソッドを切り出したことで、今回の実装で確保したいテストの書きやすさを担保しつつ、モデルが大きくなるという問題点も解決した実装を行うことができました!他にも方法はあるかと思いますが、今回は問題が解決したためこの実装で動的に構造化データを作成するタスクは終了しました。
社内の共有会でPOROの実装について話してみた
palanでは、週1回バックエンドエンジニアが集まり実装の相談や実装で試したことなどを持ち回りで話し合っております!そこで自分の持ち回りの会では、POROの実装について話させていただきました。
良さそうという話もある一方で、POROのデメリットもあるのではないか?という話が挙がってきました。
主に出たものとしては、POROの自由度が高いゆえに手を広げすぎるとよくないのではないかということです。POROはActive Recordを継承していない素のRubyのクラスのため、自由度が高く書けるゆえに何でもかんでも書いてしまうと悪影響が発生する可能性があります。
今回は構造化データを表示するためのみの目的で切り出したクラスのため、特に問題はなく、問題点について深く話し合うまでには至りませんでしたが、今後POROに切り出す際にはデメリットの意識は持とうということをバックエンドチームで共有できましたし、今後デメリットが出てきた場合には話し合う機会を作ろうということになったため、チームに良い影響や知見を与えることができたのではないかと思います!
まとめ
今回は、POROを活用することでテストの書きやすさを保ちつつモデルが大きくなりすぎること、また社内の共有会で上がったデメリットについても書かせていただきました!
モデルが大きくなることに問題を抱えている方がいらっしゃいましたらPOROの活用についても考えてみていただけたらと思います!
Rubyのお仕事に関するご相談
Bageleeの運営会社、palanではRubyに関するお仕事のご相談を無料で承っております。
zoomなどのオンラインミーティング、お電話、貴社への訪問、いずれも可能です。
ぜひお気軽にご相談ください。
この記事は
参考になりましたか?
1
0
関連記事
2021年12月22日
RDBでセットメニューを表現する方法
2021年12月11日
Railsでツリー構造アプリを作ってみた
2021年12月9日
モデルに書いていたメソッドをPOROに切り出してみた!
2021年12月7日
gem cancancanを使ってみた!
2021年11月15日
CustomCopで命名規則を作ってみた
2021年10月29日
clambyを利用したウイルススキャン
簡単に自分で作れるWebAR
「palanAR」はオンラインで簡単に作れるWebAR作成ツールです。WebARとはアプリを使用せずに、Webサイト上でARを体験できる新しい技術です。
palanARへpalanでは一緒に働く仲間を募集しています
正社員や業務委託、アルバイトやインターンなど雇用形態にこだわらず、
ベテランの方から業界未経験の方まで様々なかたのお力をお借りしたいと考えております。
運営メンバー
Eishi Saito 総務
SIerやスタートアップ、フリーランスを経て2016年11月にpalan(旧eishis)を設立。 マーケター・ディレクター・エンジニアなど何でも屋。 COBOLからReactまで色んなことやります。
sasakki デザイナー
アメリカの大学を卒業後、日本、シンガポールでデザイナーとして活動。
やまかわたかし デザイナー
フロントエンドデザイナー。デザインからHTML / CSS、JSの実装を担当しています。最近はReactやReact Nativeをよく触っています。
Sayaka Osanai デザイナー
Sketchだいすきプロダクトデザイナー。シンプルだけどちょっとかわいいデザインが得意。 好きな食べものは生ハムとお寿司とカレーです。
はらた エンジニア
サーバーサイドエンジニア Ruby on Railsを使った開発を行なっています
こぼり ともろう エンジニア
サーバーサイドエンジニア。SIerを経て2019年7月に入社。日々学習しながらRuby on Railsを使った開発を行っています。
ささい エンジニア
フロントエンドエンジニア WebGLとReactが強みと言えるように頑張ってます。
Damien
WebAR/VRの企画・開発をやっています。森に住んでいます。
ゲスト bagelee
かっきー
まりな
suzuki
miyagi
ogawa
雑食デザイナー。UI/UXデザインやコーディング、時々フロントエンドやってます。最近はARも。
いわもと
デザイナーをしています。 好きな食べ物はラーメンです。
taishi kobari
フロントエンドの開発を主に担当してます。Blitz.js好きです。
kubota shogo
サーバーサイドエンジニア。Ruby on Railsを使った開発を行いつつ月500kmほど走っています!
nishi tomoya
aihara
グラフィックデザイナーから、フロントエンドエンジニアになりました。最近はWebAR/VRの開発や、Blender、Unityを触っています。モノづくりとワンコが好きです。
nagao
SIerを経てアプリのエンジニアに。xR業界に興味があり、unityを使って開発をしたりしています。
Kainuma
サーバーサイドエンジニア Ruby on Railsを使った開発を行なっています
sugimoto
asama
ando
iwasawa ayane
oshimo
異業界からやってきたデザイナー。 palanARのUIをメインに担当してます。 これからたくさん吸収していきます!