2021年12月9日

プログラミング

モデルに書いていたメソッドをPOLOに切り出してみた!

目次

  1. はじめに
  2. 背景
  3. POLOとは
  4. 社内の共有会でPOLOの実装について話してみた
  5. まとめ

はじめに

この記事は新しい技術にチャレンジし続けるpalanのアドベントカレンダーDay9の記事です!

昨日は「社内のFigma勉強会について紹介します!」についての記事でした。

社内のFigma勉強会について紹介します!

今回はモデルに書いたメソッドをPOLOに切り出してみた話をします!

背景

今回のテーマの背景に、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モデルが大きくなってしまうのはあまり良いのではないのではないかと思い、別の方法を模索してみることにしました。

そこで選択肢としてPOLOが浮かび上がってきました。

POLOとは

POLOとはPlain Old Ruby Objectの略で、Active Recordなどを継承していないクラスを作成するものになります。今回はPOLOに構造化データの処理を切り出すことでテストの書きやすさは保ったまま先ほどまでの問題点を解消することにしました!以下が構造化データ用のクラスとメソッドをこのクラスに切り出したものになります。

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

以上のようにPOLOにメソッドを切り出したことで、今回の実装で確保したいテストの書きやすさを担保しつつ、モデルが大きくなるという問題点も解決した実装を行うことができました!他にも方法はあるかと思いますが、今回は問題が解決したためこの実装で動的に構造化データを作成するタスクは終了しました。

社内の共有会でPOLOの実装について話してみた

palanでは、週1回バックエンドエンジニアが集まり実装の相談や実装で試したことなどを持ち回りで話し合っております!そこで自分の持ち回りの会では、POLOの実装について話させていただきました。

良さそうという話もある一方で、POLOのデメリットもあるのではないか?という話が挙がってきました。

主に出たものとしては、POLOの自由度が高いゆえに手を広げすぎるとよくないのではないかということです。POLOはActive Recordを継承していない素のRubyのクラスのため、自由度が高く書けるゆえに何でもかんでも書いてしまうと悪影響が発生する可能性があります。

今回は構造化データを表示するためのみの目的で切り出したクラスのため、特に問題はなく、問題点について深く話し合うまでには至りませんでしたが、今後POLOに切り出す際にはデメリットの意識は持とうということをバックエンドチームで共有できましたし、今後デメリットが出てきた場合には話し合う機会を作ろうということになったため、チームに良い影響や知見を与えることができたのではないかと思います!

まとめ

今回は、POLOを活用することでテストの書きやすさを保ちつつモデルが大きくなりすぎること、また社内の共有会で上がったデメリットについても書かせていただきました!

モデルが大きくなることに問題を抱えている方がいらっしゃいましたらPOLOの活用についても考えてみていただけたらと思います!

Rubyのお仕事に関するご相談

Bageleeの運営会社、palanではRubyに関するお仕事のご相談を無料で承っております。
zoomなどのオンラインミーティング、お電話、貴社への訪問、いずれも可能です。
ぜひお気軽にご相談ください。

無料相談フォームへ

1

0

AUTHOR

shogokubota

kubota shogo

サーバーサイドエンジニア。Ruby on Railsを使った開発を行いつつ月500kmほど走っています!

アプリでもっと便利に!気になる記事をチェック!

記事のお気に入り登録やランキングが表示される昨日に対応!毎日の情報収集や調べ物にもっと身近なメディアになりました。

簡単に自分で作れるWebAR

「palanAR」はオンラインで簡単に作れるWebAR作成ツールです。WebARとはアプリを使用せずに、Webサイト上でARを体験できる新しい技術です。

palanARへ
palanar

palanはWebARの開発を
行っています

弊社では企画からサービスの公開終了まで一緒に関わらせていただきます。 企画からシステム開発、3DCG、デザインまで一貫して承ります。

webar_waterpark

palanでは一緒に働く仲間を募集しています

正社員や業務委託、アルバイトやインターンなど雇用形態にこだわらず、
ベテランの方から業界未経験の方まで様々なかたのお力をお借りしたいと考えております。

話を聞いてみたい

運営メンバー

eishis

Eishi Saito 総務

SIerやスタートアップ、フリーランスを経て2016年11月にpalan(旧eishis)を設立。 マーケター・ディレクター・エンジニアなど何でも屋。 COBOLからReactまで色んなことやります。

sasakki デザイナー

アメリカの大学を卒業後、日本、シンガポールでデザイナーとして活動。

yamakawa

やまかわたかし デザイナー

フロントエンドデザイナー。デザインからHTML / CSS、JSの実装を担当しています。最近はReactやReact Nativeをよく触っています。

Sayaka Osanai デザイナー

Sketchだいすきプロダクトデザイナー。シンプルだけどちょっとかわいいデザインが得意。 好きな食べものは生ハムとお寿司とカレーです。

はらた

はらた エンジニア

サーバーサイドエンジニア Ruby on Railsを使った開発を行なっています

kobori

こぼり ともろう エンジニア

サーバーサイドエンジニア。SIerを経て2019年7月に入社。日々学習しながらRuby on Railsを使った開発を行っています。

sasai

ささい エンジニア

フロントエンドエンジニア WebGLとReactが強みと言えるように頑張ってます。

damien

Damien

WebAR/VRの企画・開発をやっています。森に住んでいます。

ゲスト bagelee

ゲスト bagelee

かっきー

かっきー

まりな

まりな

suzuki

suzuki

miyagi

ogawa

ogawa

雑食デザイナー。UI/UXデザインやコーディング、時々フロントエンドやってます。最近はARも。

いわもと

いわもと

デザイナーをしています。 好きな食べ物はラーメンです。

kobari

taishi kobari

フロントエンドの開発を主に担当してます。Blitz.js好きです。

shogokubota

kubota shogo

サーバーサイドエンジニア。Ruby on Railsを使った開発を行いつつ月500kmほど走っています!

nishi tomoya

aihara

aihara

グラフィックデザイナーから、フロントエンドエンジニアになりました。最近はWebAR/VRの開発や、Blender、Unityを触っています。モノづくりとワンコが好きです。

nagao

SIerを経てアプリのエンジニアに。xR業界に興味があり、unityを使って開発をしたりしています。

kainuma

Kainuma

サーバーサイドエンジニア Ruby on Railsを使った開発を行なっています

sugimoto

sugimoto

asama

ando

CONTACT PAGE TOP