営業職の俺がエンジニアになる〜群馬Web化計画編〜

2017年に未経験からエンジニアに転職をした私が群馬でイノベーションを起こすまでの備忘録です。

先週の開発ハイライト_20171210

ひとり1on1

今週は割りとTabimemoの開発に時間を割くことができたので、充実した1週間だったかなぁと感じています。今週の開発ハイライトとしては大きく2つ。

  • has_oneに納得をした話
  • I18nの運用方針は事前に決めるべきだった話

こちらについてお話をしていきたいと思います。

has_oneに納得をした話

ユーザーのプロフィール情報を実装したのですが、usersテーブルにプロフィール項目のカラムを追加するのではなく、profilesテーブルを作成しusersとhas_oneの関連を持たせる形で実装をしました。

正直この実装については少し悩みました。っというのが自分自身がhas_oneのメリットをいまいち理解できていなかったためです。理由としてはhas_oneのアソシエーションをしなくても上記の通り、usersテーブルにプロフィール項目のカラムを追加することもできたためです。

テーブルを分けて1対1の関連付けを行うよりも、1つのテーブルにまとめたほうがActiveRecordでデータを引っ張ってくるときも簡単に書けるから、そっちの方が便利なんじゃないの？と思ったり思わなかったり。

でもなんでhas_oneがわざわざ存在するのかなぁ、というのは少し気になり「rails has_one メリット」というようなキーワードで調べてみましたが、答えには行き着かず。仕方なくいろいろなキーワードで調べている内に、ユーザーのプロフィールのデザインパターンについての記事を発見し、「なるほどな」と思ったのでピックアップしました。

kenn.hatenablog.com

usersテーブルにカラムを追加していった時に発生するデメリットと、has_oneで実装をしたとしても運用がスッキリとできる方法が書いており、とても納得をしました。

まずuserテーブルにカラムを追加していった際のデメリットとしては、1つのテーブルに膨大な量のカラムが存在した際にコードの見通しが良くないという点と、無駄な情報を呼び出すことになる（ログインをするのにプロフィール情報も呼び出す、プロフィールを検索するのにログイン情報を呼び出すなど）という2点があります

そして、has_oneを使った際の実装については、外部キーを使わずに互いのプライマリーキーを連携させるという実装方法を紹介しているのですが、この方法を使うことにより無駄なカラムが作られず、かつ適切にスコープを設定してあげれば、ActiveRecordで互いの情報を連携させる際にもスッキリと書くことが出来るという内容に、目からウロコが出ました。

Railsのアソシエーションについての考え方が少し広がったような気がしました。そして、デザインパターンを知ることで同じような開発が発生した場合にルーティーンとして高速化ができる、ということにも気づけました。

I18nの運用方針は事前に決めるべきだった話

皆さんはご自身が開発しているサービスをI18n対応していますか？

おそらく殆どの方はYesと答えるんじゃないかなぁと思います。私も今回のTabimemoでは積極的にI18n対応を進めています。（世界的に使われる日はいつになるのかはおいておきｗ）

そんな中で、今回ハマったI18nの運用方針について備忘録として書いていきたいと思います。

当初は管理するページもそこまで多くないという事もあったので、Model用のlocaleファイル（models.ja.yml）とView用のlocaleファイル（views.ja.yml）のみ作成して特に何も考えずに運用をしていました。しかし、開発を進めていく中で徐々にページ数が増えていき、いよいよファイルの中の見通しが良くなくなってきました。（特にView用のlocaleファイルが）

これまたどうするべきかと悩みましたが、結論としてはViewやModelのディレクトリと同じ構造で管理をすることにしました。イメージとしては下記の通りのディレクトリ構造です。

├── en.yml
├── ja.yml
│
├── controllers
│    ├── en.yml
│    └── ja.yml
│
├── models
│   └── users
│       ├── en.yml
│       └── ja.yml
│
└── views
    └── users
        ├── en.yml
        └── ja.yml

この方針を考えること自体はそんなに難しくなく、色々なサイトでも一般的な運用方針として取り上げられていたのですが、何よりこのディレクトリ構造になるように実装をすることが大変でした。

コピー&ペーストの嵐。そして動作確認の嵐。

やっている事自体はそんなに難しくなく、むしろ簡単なことなのに対応する量が多いメンドクサイ案件です。そんなこんなでこのディレクトリ移行を行うだけで2時間強もの時間を使うこととなってしまいました。

今回のこの作業を通しての反省として、I18nに限らずではありますが、設計をしっかりとしなきゃなぁということを感じました。これからは闇雲に開発をするのではなく、予めある程度の方向性を考えて進めるということも頭の片隅に入れながらやろうと思います。

まとめ

デザインパターンを知ることにより新規の開発をある程度ルーティーン化できるということと開発をするにあたって最低限の方針は定めておくべきである、ということを今週の開発を通して学びました。

前者は先人の知恵を借りてパターンを増やしていく、そして後者は先人の知恵を取捨選択して最適な解を見出していくことだと思います。今回の学びもいい具合にインプットとアウトプットに関連する経験だったので、今後の開発に積極的に役立てていきたいと思います。

Tabimemoの開発状況も良さげな感じなので、年内にはプロトタイプをリリース出来たらいいなぁ。

以上、今週の開発ハイライトでした。