フロントエンド開発の初期に考えておきたいこと

Frontrend Advent Calendar 2014 - Qiita 18日目の記事です。

フレームワークや使用技術など

は方々で語られているので、それ以外の話をします!

個人的には最近Ampersand.jsが気に入ってます。

リポジトリ構成

フロントエンドのリソースはサーバー側のフレームワークassetsstaticといったディレクトリで管理される事が多いですが、フロントエンドが肥大化した今、リソースが混在することで

  • コミットやPRがどちらのものなのかわかりにくい
  • 問題が起きた時に切り分けがしにくい

といった難点があります。もしもサーバー側はAPIのみを提供してフロント側はシングルページのように疎結合な構成になっている場合、ネイティブアプリがそうであるようにリポジトリを分けて完全に別管理にしてしまうというのも一つの手です。その場合ローカル開発はGrunt.jsgulp.jsで別ポートにサーバー立ち上げるなどすると良いでしょう。

JSの依存解決手段

各モジュールを一つのグローバル変数にぶら下げてconcat等でまとめる方法は、規模が大きくなってくると連結の設定やモジュール間の依存解決が煩雑になりがちです。

// app.js
var app = {};

// foo.js
app.foo = 'foo';

// bar.js
app.bar = app.foo + 'bar';

ある程度ファイル数が多くなる事が予見できているなら、Browserify, webpack, components等を使用してCommonJSのモジュールシステムを使う事をおすすめします。

// foo.js
module.exports = 'foo';

// bar.js
module.exports = require('foo') + 'bar';

CSSの設計方針

同じような記述の乱立やスタイルの衝突といった事態を防ぐためには、OOCSS, SMACSS, BEMなどのパラダイムを取り入れ、初期設計をしっかり行っておく事が重要になります。 気をつけたいのはこれらはあくまで設計のルールであってフレームワークではないので、チーム開発で運用していくにはスタイルガイドなどを用意しておくと良いでしょう。

CSS設計に関してはこの本が非常におすすめです。
今見たらKindle版がセールで60%OFFの¥950になってました。

デプロイフロー

SPAなどAjaxを多用するアプリケーションのデプロイを稼働中に行う場合は注意が必要です。クライアントのリソースが更新されないため、API側の仕様変更があると不整合が、起きたり静的ファイルのバージョンにズレが生じてあるファイルだけ古い、といった事態を引き起こす可能性があります。これを防ぐためには、例えば

  1. デプロイはバージョンごとに/v1,/v2といったディレクトリを切る
  2. APIのレスポンスにクライアントのversionを追加
  3. クライアント側では通信毎にversionをチェック
  4. クライアント側で保持しているversionとdiffがあれば適当なタイミング(ルーティングの切り替え時だと自然)でリロードをかける

といった具合に、アプリケーションに合わせたリソース更新の仕組みを用意しておく必要があります。

まとめ

にうまく乗り切るためには、構成要素のモジュラビリティを高めておいた方が良さそう、という話でした。