AngularJSプロジェクトを保守しやすくするためにやっておくべき5つのこと

AngularJSプロジェクトを保守しやすくするためにやっておくべき5つのこと

いなば

いなば

こんにちは、フロントエンドエンジニアのいなばです。
ここ最近案件でAngularJSに関わるエンジニアが若干名増えたので、社内共有も兼ねてAngularJSを保守しやすい状態に保つためにやっておくべきだと思うことを思いつく限りまとめておきたいと思います。

1. プロジェクトのファイル構成を決める

これは別にAngularJSに限った話ではないですが、まず一番最初に決めなくてはいけないことですね。
AngularJSに限らずある程度規模が大きくなる&運用をするのであれば、構成ははじめにきちんと考えて設計するべきだと思います。
ある程度規模が大きくなる場合、app.jsにすべてを記述したり、controller.jsみたいなファイルにcontrollerの処理をずらずらと記述したりしていくと、開発が進むにつれエディタをスクロールする量が増えていき、保守がとてもつらい感じになります。

例:controller.jsにずらずら書く

angular.module('controller',[])
.controller('hogeCtrl', [
    function(){}
]).
.controller('fooCtrl', [
    function(){}
]).

// 省略

.controller('barCtrl', [
    function(){}
]);

ディレクトリ構成をどうするかはプロジェクトにもよると思いますが、ひな形の自動生成はYeomanで行えるようにして、1ファイルに1モジュールとするのが望ましいです。
Yeomanを使うことにより、ファイルの設置場所やファイル名のモジュール名といった表記揺れなどから守られやすくなります。

AngularJSのディレクトリ構成に関しては、過去に弊社エンジニアのびすけくんが勉強会で登壇をしています。

参考:Angular.jsのディレクトリ構成のベストプラクティスを探る
http://qiita.com/n0bisuke/items/6a79d3ee63020f771260

ディレクトリ構成のパターンを紹介してくれているので参考になりますね。
悲惨なことになる前に、最初にきちんと構成を決めましょう。

ちなみに弊社のとある案件は現在このような構成になっています。
※ざっくりです

app/
    ├ app.js
    ├ common.js
    ├ components/
   │ └ hoge/
   │   └ hogeCtrl.js
   │   └ hoge.html
    ├ directives/
   │ └ hoge/
   │   └ hoge.js
   │   └ hoge.html
    ├ services/
   │   └ HogeService.js
   │   └ model/
   │   └ HogeModel.js
   └ test/
        └ components/
           └ hoge/
           └ hogeCtrlSpec.js
        └ directives/
           └ hogeSpec.js
        └ services/
           └ HogeServiceSpec.js
           └model
              └ HogeModelSpec.js

2. $rootScopeは極力使わない

グローバル変数は極力減らしたほうが良いのと同じ理屈です。
$rootScopeにプロパティは原則生やしません。
複数人で開発する場合、$rootScopeを多用してしまうとプロパティ名のバッティングなどで思わぬバグを出すリスクも高くなります。
また、$rootScopeは根幹にいて常にダーティチェックが走るので、パフォーマンスを下げる要因にもなります。

ただし、アプリケーション全体でイベントを監視したい場合には、$rootScopeにイベントを設定します。

例:$rootScopeに設定しているイベント

$rootScope.$on('$viewContentLoaded', function () {});
$rootScope.$on('$stateChangeStart', function() {});
$rootScope.$on('$stateChangeSuccess', function() {});

3. $broadcastと $emitを使わない

現在自分が携わっている案件では、最初に$broadcastと$emitは使わないというルールを決められていました。$broadcastと$emitをあちこちで使ってイベントが飛び交っていくようになると、つながりも適用範囲もわかりづらくなり、処理を追えなくなって破綻してしまうからです。

実際半年ほど開発と運用をしていますが、$broadcast, $emitを禁止して困ったことはありません。代わりにController間で状態や値を共有したい場合は、Serviceで仲介するようにしています。

LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。

Webサイト制作の実績・料金を見る

この記事のシェア数

フロントエンドエンジニアのいなばです。 LIGではAngularやVueなどのフレームワークを使った中~大規模のWebアプリケーション開発、フロントエンドエンジニアの育成などを担当しています。 好きなものはカフェインとカプサイシン。 趣味はランニングと一眼レフです。

このメンバーの記事をもっと読む
デザイン力×グローバルな開発体制でDXをトータル支援
お問い合わせ 会社概要DL