判決： まあまあ（でもないか）

一体何の話なのか？

私は2年間、Angularにのめり込んでいました。

それぞれの考えを持つさまざまなチームによる、10以上のAngularベースのプロジェクトを見守り、関わってきました。

1年目はフレームワークの採用、APIの変更、ドキュメントの改良、コミュニティの形成を注視して過ごし、徹底的に習得しました。

2年目は実務に全面的に携わり、チームメンバーの意見を聞きました。

私の意見は、 Angular.jsは大多数のプロジェクトには“まあまあ”だが、本格的なWeb アプリ開発には不十分である ということです。

“本格的なWebアプリ”とは？

“本格的なWebアプリ”というのは、長期の 保守が可能 で、最新の一般的なブラウザで 実行できる 、 スムーズなUX を備えた、 モバイルフレンドリー なアプリのことです。

専門家が開発したWebアプリは単なるアプリではなく、いくつかの問題を解決します。これは便利な製品で、快適に使用できます。

このようなアプリは、コードベース内部（良い設計、シンプルなコンセプト、理解しやすいコンポーネント）だけでなく、デプロイプロセス（CDN、縮小、SEO、クリティカルパスの最適化など）や、ユーザビリティ領域（読み取りスピード、コンテンツファースト、グレイスフルデグラデーション、インフォメーションアーキテクチャなど）にも適用されるベストプラクティスを用いて、かなり短期間で開発する必要があります。

Angularを活用できる場面は？

1. フォームベースの“CRUDアプリ”を構築するとき。
2. 使い捨て型プロジェクト（プロトタイプや小規模アプリ）。
3. パフォーマンスや保守コストが重視されない場合（うーん、でもExtJSを調べてみたことはありますか？）。

そして、Angularを使わない方がいい場合は？

1. 各自の経験内容がバラバラなチーム。
2. 規模が拡大する予定のプロジェクト。
3. 常にコード全体を見渡せる、高いスキルを持つフロントエンドリードデベロッパが不足している場合。
4. パフォーマンス要件が特に厳しいプロジェクト。

もちろん、これらの内容はすべてのフレームワークやプロジェクトに当てはまります。しかし、Angularではすぐに問題が起こり、あなたに大打撃を与えると同時に他のMVCフレームワークにも影響を与えることになるでしょう。

どうしてもAngularを使わなければならない場合、仕事上の戦略はあるか？

1. 短期間のプロトタイプ作成にAngularを使用するならOK、やり遂げたらリラックスする。
2. プロトタイプでうまくいくことが確認できたら、 そのプロトタイプを中止する 。絶対に拡張しないこと。
3. 自分の設計ミスをじっくり分析する。
4. できれば他の技術スタックを用いて、新しいプロジェクトを開始する。
5. プロトタイプから自分のMVPに機能を移す。

それでも今後プロジェクトを 拡大 、保守していく必要がある場合は、以下の手順を踏みます。

1. 今後、 被害を被るだろう という事実を受け入れる。
2. 一般的なスタイル（ 例1 、 例2 、 例3 ）を基に、自分で想像できる使用例と使用パターンをすべて網羅する 完璧な ガイドラインを作成する。
3. できるだけ、自分のオブジェクト指向設計の知識と結びつけないようにしておく。
4. MVCかMVVMのいずれかを選ぶ。ただし、この手法を最初から一緒に使用しないこと。
5. 開発プロセスに“リファクタリング”イテレーションを加える（適切な間隔は3カ月ごと）。
6. 自分の使用パターンと使用例を定期的に分析する。
7. 自分のプロジェクトのニーズとチームの経験に特化したAngularベースのメタフレームワークを作成する。

Angular、その欠陥

それでもまだAngularを使うなら、私がこれまでに投稿したいくつかの重大な問題に没頭することをお勧めします。

リストは以下のとおりです。

1. 不完全な抽象化
2. 不十分なパフォーマンス
3. 名前の衝突
4. 複雑さ
5. サードパーティ製モジュール
6. “コード化された経験”はない

「いや、Angularはすごい！ Angularがどんなものかを知らないだけだ」

こんな厄介なものに夢中になっている私を訝しむ人たちに、私はこう言い続けてきました。

これまで挙げたような問題はどれも回避できるのですから。

しかし、問題について詳しく知るには、このフレームワークと長い時間格闘する必要があります。

“危険信号”があれば、開発プロセスの中で分かるようにしなければなりません。

問題の“回避策”を見つけるための時間もかかります。

そしてようやく、 フレームワークで発生した問題が解決します 。

高性能で本格的なアプリを実装しようとするときに、こんなことはやりたくないですよね。

“回避策”のアップデートに費やす時間も、もったいないはずです。

私が学んだこと

1. 最大の間違いは、自分が楽観的すぎたこと。
   経験のある開発者から見れば、最初から分かっていた問題もあります。しかし、チームには優れたアイデアを持ったいいメンバーが揃っているから大丈夫だ、と高をくくっていました。

2. 問題は そのうち解決されるだろう と思っていた。
   GitHubでは有益なディスカッションが交わされ、多数のプルリクエストも行われています。問題の解決に役立つ解決策も挙がっています。しかし実際には、これらの解決策はまだディスカッションの最中であり、話がまとまっていません。

3. Angular 1.xの一部の問題は 今後も解決されない 。

4. 他の人に正しい使い方を教えられると思っていた。

実際には、フレームワークのサポートがないと、何度も何度も同じ説明をしなければなりません。

フレームワーク（とメタフレームワーク）の開発者に向けた教訓：

1. 抽象化の際はできるだけ数を少なくすること。
2. 突拍子もない名前は付けないこと。
3. コンポーネントに責務を混在させないこと。入念に定義したロールできめ細かい抽象化を行うこと。
4. 自分の決定事項と妥協点について常に文書化しておくこと。
5. 参照プロジェクトとサンプルは常に厳選し、最新の状態にしておくこと。
6. 小さいアイテムをCompositeパターンに適合させる“ボトムアップ”方式で抽象化すること。 「これをどうやってグローバルにオーバーライドしよう？」と最初から考えてはいけない 。
7. グローバルな状態は全くの悪でしかない。
   これは例えるとホラー映画の暗闇のような状態であり、行く手にどんな問題が待ち受けているか分からないのだ。
8. データフローとデータの変更は細かいレベルで行い、単独のコンポーネントにローカライズすること。
9. 使いやすさ は追求しない。コンポーネントと抽象化は 理解しやすいようにシンプルに 。
   新しい効率的な方法はそれぞれが考えることなので、各自の使いやすさに合わせる必要はない。
10. 優れたアイデアがあれば、すべてフレームワークにコード化すること。
    “道しるべ”を作り、誤った方向に進んだ時には警告がスローされるようにする。

Angularの代わりになるものを教えて！

Angularの代わりになるものをまだ挙げていませんでしたね。詳しくは、 こちらをご覧ください 。

それでも、Angularが好き！

そのような方がいらっしゃれば、ぜひ日頃Augularをどのように使い、問題を解決しているか、そしてコンポーネントやプロジェクトの構造をGitHubで教えてください。

でも、心からそう言えないという方は…無理に好きにならなくてもいいかもしれません。

Alexey Migutsky – フルスタックエンジニア。ITにまつわる“魔法”の使い手。