前置き

こんにちは。　#teamサイゼリヤ アドベントカレンダー 最終日。初日も担当しました、マスブチです。
クリスマス当日、未来をよくするクリエイターの皆さんはどのように過ごしましたでしょうか。

僕は大学が停電してしまったので、美味しいコーヒが支給される、緑の自由の女神がささやく檻の中でせかせかと卒論という魔物と戦っている状態でございます。
ちなみに僕がお気に入りの緑の自由の女神のお店は新宿マインズタワー店です。会社のビルの1階に入っていて、落ち着いてる+あまり混んでいないのが好きです。

今回の記事では、スタートアップのプロダクトのサーバーサイド開発を1年強やってきた僕が思う失敗談と良かったことを書いていこうと思います。開発を始めた当初は、
Railsで初歩的なCRUD開発ができます！
くらいのレベルでした。そこから時間も経って、やったほうが良いこと、悪かったことなどたくさんありました。そこから抽出して紹介していこうと思います。

この記事を読んで欲しいひと！

• 「Railsで0-1の開発をすることになったなう」とtwitterで呟きそうな人

• 経験がそこまでないのに少ない人数で開発しなければいけない！><　やばぽよ！な人

• 新しい技術入れた方が良いのは分かっているけど、いまいち踏み出せない人

などかなぁ。

失敗談 3選

1. Railsなのに直書きSQLが頻出する問題

結論、DBのリソース設計をミスると大変だよって話です。

また、これはDBの設計があまり良くないのに比べて、

• PostgresqlのExtensionであるPostGISというExtensionを利用している
• 一回のAPIコールでSQLの呼び出しを最小限にしたい
• 返すリソースのロジックが少し複雑

なども関係してきます。
ここで伝えたいのは、ActiveRecordで発行するSQLを考えた上で、DB設計しないとまずいよ。ということです。
DB設計は正規化をちゃんとやっていれば大丈夫だと思いますが、自分は概念が被ってくるリソースの設計に少し失敗したなぁと思うことがあります。

最近は可能な限りActiveRecordに置き換えていますが、実装に時間をかけられなく複雑なロジックが必要なところは実装が早いのでとりあえずSQLを書いてしてしまったりしています。
ActiveRecordを通すために、付け焼き刃の浅い考えでDBの設計を変更したりするよりは、後々修正可能+実装が早いという判断軸のもとでの意思決定でやっています。

余談ですが、この苦労のおかげで僕個人のSQLを書くという能力は飛躍的にアップしました笑

2. DBでのstatusカラムの設計崩れた問題

これはDBでは状態変換を表すようなカラムを定義するのは可能な限りやめようという話です。

Rails にはenum という状態変化を管理するのにとても便利な機能が用意されています。

class Article < ActiveRecord::Base
  enum status: { draft: 0, published: 1 }
end

が、調べればばたくさん出てくるのですが、そもそもDBに置いて状態変化を扱うことはかなり慎重にならないといけないです。

理由しては

• 状態がintegerで定義されていると、その状態が何を表しているのかがわかりにくくなる
• 状態の定義が変化する可能性がある

があると思います。

僕の主観的な感想ですが、状態変化を将来も見据えて最適な粒度で定義するのはかなり難しいのではないかと思います。
ECなどある程度設計が体系化されているサービスを除いて、新規サービスを作る上で状態変化は可能な限り定義しない方向が良いと思います。

参考
DELETE_FLAG を付ける前に確認したいこと。
【データ設計アンチパターン】誤ったステータスカラムの設計

3. API レスポンスで返すリソースの形がバラバラになる問題

これは規約とか、レビューとかをちゃんとしていない開発で起こりそうだと思います。

たとえばあるAPIで帰ってくるリソースがこんなだったのが

{
  article {
    id: 1,
    name: 'サイゼリヤは美味しい',
    is_publish: true,
    tags: ['イタリアン']
  }
}

あるAPIだとこんなんになる現象です。(多少大げさに書いていますがw)

{
  article {
    article_id: 1,
    article_name: 'サイゼリヤは美味しい',
    is_publish: 1,
    tag: 'イタリアン'
  }
}

APIで返すjsonはibuilderで作っていますが、jbuilderはチーム開発であまり向かないのではないかと思っています。
理由として、jbuilderを使ってしまうとよくも悪くも好き勝手jsonを作ることができてしまうので、APIによって微妙にレスポンスの形が変わるということがあります。
この対策としては、シリアライザーを使ってAPIは開発すべきだと考えています。
RailsのシリアライザーはActiveModelSerializersが有名だと思いすが、少し前に話題になったNetflix製のFast JSON APIもあります。

現在、新規サービスをVue.js + RailsAPIでサーバーとフロントを完全分離して開発中ですが、APIのレスポンスにはどちらかのシリアライザーを入れようと考えています。

参考
Rails アプリに RESTful API のレールを敷いて生産性が大きく上がった話
マイクロサービス指向 Rails API 開発ガイド/building rails api on microservices

やってよかったこと 3選

やっている企業からすれば当たり前といえば、当たり前なのですが人数が少ない、実装のスピードが求められる環境だとおろそかにされそうなことを書いて行こうと思います。

1. Linter(rubocop)を導入した！

これはフリーランサーの方のとあるレビューをいただいてから導入しました。

linterを入れることでコードが共通化できるのに加えて、その言語のオードソックスな書き方を学べて自分のスキルアップにもつながると思ったので、今後他の言語で何かをやる際もlinterは入れようと思います。

自分はエディターにlinterのプラグインを入れるとエディターの処理が重くなったりして嫌だったので、gitでcommitする際にフックをかけてrubocopが回るようにしました。 pre-commitファイルにこんな感じで書いておくと自動で修正もしてくれるので良いです。

git diff --name-only --staged | grep '\.rb$' | xargs rubocop -a
rubocop_result=$?
echo $1

2. テストをちゃんとかく + CIを導入する！

これも当たり前といえば当たり前ですが、テストはちゃんと書いた方が良いです()
規模が小さいうちは実装の仕様をある程度覚えているのですが、時間が経ってアプリケーションの規模も大きくなってくると自分で書いたコードの仕様が把握できなくなってきました。
なので、testはちゃんと書きましょう笑

またこれもやっている会社が大半だと思いますが、githubにpushした時に自動で回るCIの導入はやった方が良いです。
linterが自動で回るCIとプルリクからdeployまで自動化するところまで整備できていないのですが、タイミングをみてやろうと思っています。

3. Dockerを入れた！

ちょっと前に比べて、Dockerを使ってやっていくのがだんだんスタンダードになってきたなぁと思います。
うちもPostgresSQLにExtentionを使っていたりして、Docker未熟者の僕にとっては既存の環境にDockerを入れるのクソ大変だったのですが、ガンバって入れました。

Dockerを入れてからやっぱり環境を整えるのがとても楽になりました。
新しい人の環境構築、PCを変えたり、Railsアプリなどを同一PC複数に存在させたりする時にDockerで環境構築をしているとともて楽です。

個人的な話、ペライチのスクリプトでもなんでもDockerで環境を構築するようになりました。
Dockerは良いぞという話でした。

最後に

いかがだったでしょうか。？？
やって良かったことについては、結構当たり前のことしか書けていないような気もしてますが、当時の僕からしたら頭にないことばかりだったので、当時の僕に届け！という思いで書きました。

人間というのは環境が変わると、当たり前の基準が変わってしまい、変化に気づかないものだと思います。いわゆる、情報の非対称性が価値になっている時代だからこそ、自分の環境の変化にも敏感になっていきたいですね！

最後に、このアドベントカレンダーに参加していただいた皆さん本当にありがとうございました！
正直、埋まっても10日くらいかなぁとか思っていたので、こんなに埋まって僕は感動です。😭
まだ、書けていない人も年末年始でなんとか書いてもらえるとありがたいです！僕は読みます！笑

番外編！ 独断と偏見で選ぶ #teamサイゼリヤ アドベントカレンダー大賞！！！！

最後にせっかくなので、僕が読んでおもしろかったアドベントカレンダーの記事をPickUpしようかなと思います。(笑)
賞金などはないので、名誉のみ受け取ってください！w

必見！汎用的技術賞

個人でUnityゲームアプリを開発してリリースするまでにやったこと・学習したことまとめ

deploygate, fastlane, firebaseなどは弊社でも導入していて、親近感も湧きました。
一方、これらの技術をリリースまで体系的に紹介している記事は少ない&&インターンなどしないと触れる機会が少ない技術なので、すごく価値がある情報だと思いました。

おもしろい！使える！技術賞

Tinderを自動化し、無限自動スワイプして、今年のクリスマスはサイゼリアから抜け出そう

Tinderの自動スワイプは僕も実装しようと考えていました。が、これの良い点はブラウザのコンソールで実装したという点だと思います！これで、自動スワイプする敷居が下がりました！笑

ギーク技術賞

Strong Parameterとメタプロ

よくも悪くも、Ruby+Railsを書いている人じゃないと読む気にあまりならない記事だったと思います笑
そして、それを書いている僕にとってはとても勉強になる記事でした！

これはやりたい技術賞

クリスマス前なのでMacの中身をAnsible化するぞぉ

Macを変える予定なので、これは構成管理ツールの勉強のためにもやりたい。。。！

その他

その視点は無かった！＞＜賞

カレー好きなデザイナーが贈る デザインセンスを感じるカレー屋 5選

キータでカレーの紹介している人初めて見ましたw

以上、スターバックスとい名の檻とからお送りしました！
長い記事読んでいただいて、ありがとうございました！
アドベントカレンダーを書き上げてくださった方お疲れ様でした！

来年も幸せなクリエイターズライフを送りましょう！！