サービスをローンチした

仕事でやっていたサービスをローンチできました。ここで紹介しても差し支えないのだけど、サービスのURLが知りたかったら言ってください。

実はいままでfirst commitから見守っていた(まともな)サービスがローンチを迎えたことは一度もなかったので、とりあえずほっとしています。

最初から設計を考えるのって、やっぱりなかなか難しいですね。それなりにMySQLのテーブル設計には詳しくなれた気がします。

Railsはモデル=テーブルなので、テーブル設計の段階でちゃんとしてないとのちのち辛くなると思います。RailsにはSTI(Single table inheritance=単一テーブル継承)、ポリモーフィック関連などといった機能がデフォで存在してますが、ここらへんの理解が深まった気がします。ぶっちゃけた話どっちも使わなくていいんですけどね。 ※1

究極的に、テーブル設計は理想と現実のどこに立つかの勘所であって、正規化うんぬんを学んでも仕方がないと思います。そもそも、本質的に正規化されたテーブルは、idとnameと外部キーだけしか存在しないのではないでしょうか。
Railsも、例えばusersテーブルにemailが生えてるのはよくある設計だけど、usersにはemail_idだけもって、emailsテーブルに格納することだってできるわけだし。

まぁ、これは行き過ぎた例なのかもしれないけど、困った時は細かく分けとけばそんなに問題はない。

次に、もう一個思ったのは、はじめから厳密すぎるテストを書いてはいけない。というか、書かなくてよいという思想すら持ち始めた。

というのはちょっとショッキングな言い方だけど、サービスをローンチするまでにやらないといけないことはプロダクトを作ることというよりもプロトタイプを作ること。プロトタイプを作るフェーズと、落としこむフェーズを曖昧にしてはいけないと思う。

今回のプロジェクトで、UI設計が画面遷移がほとんどできて、それに対応するfeature specなりcontroller specをいろいろと書いた直後に、いざローンチ前のユーザヒアリングという段になって根本的にいろいろ変えないといけないことがでてきました。つまり、プロトタイプをつくるべき段階で必要以上のものを作っていたわけです。

状況によっては、UI設計・コーディングを先にやって、データベースなんてなしでまずは動く紙芝居を先に作ってやるほうが必要なのかもしれない。従来型の、(model作る=> controller作る=> url作る) => 文字列だけのサイト作る => html/css書く という流れは視野が狭いのかもしれない。

ダメな点ばかり上げてしまったけど、最後によかった点。今回は僕の個人的な意識によって、spec用のライブラリがかなりたくさんできました。というとなんかすごそうだけど、要するにカスタムマッチャとかfactory_girlのファイルとか、shared_contextとかです。
今度、機会があったときにいままとめているSpec design patternという記事をあげようと思います。そこで、この話の続きを。

※1 まずポリモーフィック関連は使わないに越したことはありません。なぜならjoinが難しくなるから。ここらへんは「SQLアンチパターン」などを読むといいです。次にSTIですが、やりたいことは要は同じテーブルのインスタンスなのだけど、条件によってサブクラスを返したい場合にはActiveRecordのinstantiateをオーバーライドしてやったほうが良い、というか現実的にそういう使い方のほうが柔軟性があると思います。typeカラムにサブクラス名が入るというのは、規約にしてはちょっと強すぎるし状況によってはそうもいかなかったりするので。