Angularを選択した理由¶
クライアントアプリケーションのフレームワークとして Angular を選択した理由です。
前提となる要件¶
今回は以下のことを要件として定義しています。
- コンポーネント単位で分離でき組み合わせることでページを作成できること
- コンポーネント間の遷移を URL でルーティングして表示できること
- パッキング (HTML, CSS, JavaScript を統合/圧縮) が行えること
- 見た目 (HTML, CSS) と 振る舞い (JavaScript) が分離できること
- TypeScript で処理が書けること
- SCSS が利用できること
- 単体テストが行えること
- ビルド時に Docker Image が作成できること
Angularについて¶
Angular はフレームワークという位置づけであり、全部入りです。
全部入りなので何も考えずにすべての機能が揃っており、要件にあげたもののうち Docker 以外は考える必要がありません。
Docker に関しても Microsoft が提供しているテンプレートを利用することで解決します。
よく聞くデメリット¶
導入・学習コストが高い¶
他のライブラリに比べるとコストは高いのかもしれませんが、今回クライアントアプリケーションはデザイナーやマークアップエンジニアには処理 (TypeScript) を触らせることを想定していません。
TypeScript 自体の学習コストは C# エンジニアには無視できるものと考えています。
一からプロジェクトを作成して全体を作り上げるのはそれなりに技術を持っている人でないと難しいと思いますが、既にプロジェクトが存在しておりサンプルがある状態からの機能追加は極端な話コピペプログラマーでも可能です。
ASP.NET MVC でも一からプロジェクトを作成して全体を作り上げるのは難しいと思いますが、C# や ASP.NET MVC が難しいという話はあまり聞きません。
Angular が難しいと言われる理由にはデザイナーやマークアップエンジニアを対象にしているから、ということが含まれていると考えられます。
多機能であり小規模なアプリケーションではオーバースペック¶
小規模なアプリケーションではないので問題ありません。
仕様に対する品質を担保するためにテストを重視したいのと、出来る限り自動化したいので機能が多いことが好ましいです。
部分的な導入が難しい¶
新規開発であり部分的な導入はしません。
開発を一度Angularで始めると基本的に乗り換えはできないので引き返せない¶
万が一乗り換えが必要な場合は新しく別のアプリケーションとして一から作成すればいいです。
マイクロサービスが前提としてあり、UI層とアプリケーション層の責務を明確に分離しているので一から作り直しても影響範囲は限定的です。
他の選択肢¶
React と Vue.js が選択肢にあがります。
どちらもライブラリという位置づけなので、要件を満たす場合は複数のライブラリを組み合わせる必要があります。
逆に言えば要件を満たすようなライブラリを含めての提案があるのであればそちらでも構いません。
結論¶
Angular を選択したのは他のことを何も考えなくていいというところが大きいですが、基本的には私の趣味です。
クライアント開発は強く型付けされた言語と比べると手軽にコードが書けるかわりに品質の維持が難しく、何を選択しても大きな違いはないので要件が満たされているのであれば何でも構わないと思ってます。
コード自体の品質の維持が難しいので、最初から高いレベルでの品質を維持することは諦め、ダメならプロジェクト全体を捨てて作り直す、という選択肢もありです。
今回はマイクロサービスが前提としてあり、UI層とアプリケーション層の責務を明確に分離しているので一から作り直しても影響範囲は限定的です。
UI層はユーザーから一番目に見えるところであり、頻繁に修正が発生します。
UIに関して最初に仕様を定義してすべて決めきるのは無理なので、どういうレベルであれ作り直しは必ず発生します。
例えばコストの安いオフショアにすべて投げ、ダメなら一から作り直し、良さそうなら他の機能もまかせてみる、という方針で使えそうな人材を探してみるとか。
私はオフショアを利用して成功した案件を見たことがないのと、コミュニケーションコスト (言語、国民性の違い) から上手くいくイメージが持てないので、いきなり重要な機能 (ドメイン層、インフラストラクチャー層) を任せることには反対します。
⇒セキュリティ的な都合で海外に流すことにも抵抗がある