Backbone.jsでフロントエンド開発 - エニグモ開発者ブログ

はじめまして、エンジニアの高松です。今回は先日リリースした、「色・サイズ改修」でのフロントエンド開発についてお話したいと思います。

「色・サイズ改修」は、主に以下を目的としたプロジェクトです。

リリース時のお知らせがこちらです。

BUYMAはC2Cのショッピングサイトなので、改修は大きく出品側と購入側に分かれます。開発は私と部長の2人体制、さらにデザイナーのチームで制作しました。

私: 出品側開発部長: 購入側開発デザイナー: 全般的なデザイン

部長が先行して開発した部分を引き継ぐことから、開発は始まりました。

引き継いだのは、500行ほどのJavaScriptでした。検討中の画面の仕様と併せて見ると、動的な制御の多いポップアップ画面のコードの一部です。

$と_の量が多い事と、「ここはAjaxで取ってくるか?」というコメントが気になりましたが、続きを書き始めました。

少しずつ画面が動き始め、行数にして1300行を超えた頃でしょうか、開発が日に日に辛くなってきました。ちょっとした修正にも時間がかかり、どこかを直せば、どこかが壊れます。私(と部長)の書いたコードが読みづらく、子泣きじじいのように重くのしかかってくるのです。

「このまま作りきれるのか...」不安が募ってきたところで、一度書いたコードを捨て、Backbone.jsで書きなおすことを決めました。一部ですが、既にBUYMAの中にはBackbone.jsで書かれた部分があったのが理由です。

結果、Backbone.jsを使って書き直したコードは、以前よりずっと可読性が高いものに生まれ変わりました。

開発で使ったのは、View・Collection・Modelといった、Backbone.jsのベーシックな部分で、ルーターなどの機能は使っていません。テンプレートエンジンには、Handlebars.jsを使いました。

Backbone.jsを利用して得られた、主なメリットは以下の部分です。

Viewとロジックが分離でき、イベントも所定の場所に書くので、処理が追いやすくなった。
CollectionがUnderscore.jsをラップしていて、使いやすい。eachやmapなどのコレクション系のメソッドや、findなどのファインダーメソッドがRuby・Railsライクで馴染みやすかった。
フレームワークとしてコンパクトで、学習コストは低かった。
結果として、ロジックの実装に集中できるようになったのが、一番のメリット。

逆にハマった部分です。