Angular Advent Calendar 2022 12 日目の記事です。
昨日は @masayasviel さんの ControlValueAccessorコンポーネントをmarkAllAsTouchedできるようにする でした。
カルテットコミュニケーションズで働き始めて 11 年目に突入しました、松岡です。ひとりぼっちでフロントエンドのコードを書いていた時代からチームマネージャーとして仕事をするようになった現在まで、弊社に興味を持ってくれた応募者とそれなりに多く関わる機会がありました。採用のステップを踏む中で数多くの応募者からいただいた質問「Angular を使っている理由はなんですか？」をブログ記事にしたためておこうと思います。
AngularJS から Angular へ
弊社のフロントエンドで最初に導入したフレームワークは AngularJS でした。当時は、他に実用的なフレームワークの選択肢がないからという消去法で選定されました。
それまでは jQuery をフル活用し、ユーザーアクションに対してリアルタイムに反応する DOM の変化や装飾がフロントエンドのテクニックの中心だったように思います。知識の中核も HTML、CSS、JavaScript といったもので、これらを使って見た目をどう変化させるかが最大の関心事でした。
フレームワークはここに「ロジックにまとまりをつけて分離すべきでないか」「どのような構造が変更に強いのか」という新しい考え方をもたらしました。AngularJS のスコープやダイジェストループといった独特の概念を理解するまでにそこそこ時間がかかりましたが、今振り返ると私にとっての良きパラダイムシフトとなりました。
AngularJS の公式ドキュメントで Angular への移行が促されるようになり、弊社ではこのタイミングでいくつかのフレームワークのチュートリアルを実践して再び選定を行っています。当時は Angular4 がリリースされて間もない頃で、DI やコンポーネント志向など、なじみのない概念が登場するフレームワークという印象でした。概念がより多く提示されているフレームワークほど新たなチャレンジやパラダイムシフトをもたらしてくれるだろう、公式ドキュメントに沿って書けば自然とフロントエンドの設計手法が学べるのではないか、当時はそう考え Angular を推しました。
AngularJS ※AngularJS は 2022 年でサポートが終了しました。
Angular のいちユーザーとしての所感
Angular に対して、クラス志向や大規模開発向け、という意見を見かけますが、私はそう思っていません。クラスを採用しているのは Angular 内部のコンポーネントの構造であって、そこにのっかる独自のロジックはクラスでも関数でも自由に書くことができます。ファイルの命名など公式ドキュメントで推奨されたものはありますが、あくまでガイドラインであって遵守するかどうかはエンジニアに委ねられています。
絶対に守らなければいけないものを「限界」とすると、コードの書き方の限界は TypeScript の言語仕様に存在していて、挙動の限界はビルドした後の JavaScript や実行環境に存在しています。もとを正せば JavaScript として動くものを作るためにフレームワークの力を借りて開発者体験を向上させている、という感覚です。
JavaScript に変換される特性ゆえ、クラスや関数の混在、あるいは HTTP リクエストに対する Observable パターンと fetch の混在などカオスになる自由度もあわせ持ちます。システム開発が大規模になってアサインされるメンバーが増えるほど、命名やアーキテクチャ統一のためのコミュニケーションが必要なのであって、フレームワークはカオスさに歯止めをかけることはできません。ドメイン知識とするべきロジックがコンポーネントと密結合している、チームで決めた集約ルール無視のマジックストリングが随所に登場する、これらはフレームワークを超えたフロントエンドあるあるではないでしょうか。
ここ最近の Angular のリリースでは、TSLint や Protractor のオプトアウト、Standalone Component の登場などにより「概念の提示」から「使いやすさ」にシフトしてきていると感じています。アドベントカレンダー 1 日目で @kasaharu さんが紹介されている Testing Library も気軽に導入できるようになりテストの書きやすさも実感しています。どのフレームワークにも「使いにくさ」や「使いやすさ」が部分的に共存していると思いますが、自身で使っているフレームワークの「使いやすさ」が向上するとモチベーションが上がりますね。
Angular アプリケーションに Testing Library を導入する | Angular Advent Calendar 2022
Angular は半年ごとに新しいメジャーバージョンが発表されるリリースサイクルで、定期的にメンテナンスされる「生きているフレームワーク」です。それによって新しい概念が学べたり、追随するサードパーティのライブラリを試したり、自然発生的に学習機会が得られます。実際、マイクロタスクやサニタイジング、CSS カプセル化などのウェブの知識は Angular でプロジェクトを作ることをきっかけに得た知識でした。
フロントエンドエンジニアなら当然知ってるでしょ！と思う方もいるかもしれませんが、HTML・CSS・TypeScript・JavaScript・ブラウザ等ありとあらゆる基礎知識を積み、動向に目を光らせてキャッチアップをするというのは大変な作業です。Angular の公式ドキュメントやリリースノートから未知のワードを見つけ、それがウェブの技術をベースとしたものであることが分かり、あらためて調べて基本を知る、という小さく遡及的な学習サイクルが私にはマッチしているように思います。
半年ごとのメジャーバージョンは破壊的変更というよりも機能リリースの側面が大きいと思っています。公式ドキュメントでマイグレーションガイドが示されますし YouTube の ng-japan OnAir でアップデート内容を共有してくれることを本当に有り難く思っています。おかげで ng update コマンドのアップデート実行に困ったことはあまりなく、よかれと思って導入した公式ではないライブラリのアップデートに多少苦戦した思い出があるくらいです。ライブラリがメジャーバージョンアップに追随しないとか、TypeScript アップデートに付随してシンタックスを変更しないといけない、といった類なのでアップデートあるあるかなと思います。
フレームワークを固定するメリット
自社のプロジェクトでは 2022 年現在、フロントエンドのフレームワークにすべて Angular を採用しています。フレームワークが固定されることで、どのメンバーがどのプロジェクトにアサインされてもすぐにコードを書くことができ、学習コストは最初のアサインに集約できます。複数人が知識を持ち合わせているので詰まった時にヘルプを投げかけても、わらわらと回答者が集まってきます。
仮に新しいプロジェクトで別のフレームワークに乗り換えた場合、乗り換え前のフレームワークで書かれたコードはだんだんとメンテナンスが後回しにされ過去の遺産となり得ます。新旧それぞれのフレームワークの熟練メンバーの人数によってプロジェクトのアサインが左右されるケースも考えられます。メンテナンスも熟練メンバーも減っていくフレームワークは属人化が高くなり、いつか大きなリファクタリングのコストを払ってフレームワーク乗り換えプロジェクトが発足するかもしれません。
弊社のような十人前後のエンジニア集団ではよほどの根拠がない限り、フレームワーク乗り換えよりも、誰もが自由にプロジェクトを行き来できる環境のほうにメリットがあるのではないかと考えています。
フレームワークを固定するデメリット
フレームワーク選定は採用活動においてエンジニアの母数がどれくらいか？という視点も必要になります。経験者なら自分が使ったことのあるフレームワークのほうが応募しやすいでしょうし、その数が多いほど採用する側の選択肢が増えることになります。フレームワークを固定することにこだわりすぎてしまうと、トレンドが採用活動に影響してエンジニアが枯渇する事態にもなり得ます。
弊社の募集要項ではあえて TypeScript の実務経験のみを問い、過去にどんなフレームワークを使っていたか不問としています。ここには、どのようなフレームワークを使っていても（あるいは使っていなくても）フロントエンド開発の難しさや悩みは共通で、助けとしてフレームワークが存在するという持論があります。そしてフレームワークそのものに困難の解決を求めるのではなく、前述の「アーキテクチャ統一のためのコミュニケーション」や「誰もが自由にプロジェクトを行き来できる環境」のようなチームの最適解を一緒に考えてくれる人材を求めています。
もし私が転職活動をするとしたら最初に検索するキーワードは「Angular 採用」ですが、それがチームでなく個の最適解だったと気づいたら Angular は趣味で使うにとどめるでしょう。同じ思考のエンジニアであれば、使ったことのないフレームワークであっても興味を持って取り組んでくれるであろう期待を募集要項に込めています。
Angular を使っている理由はなんですか？の解
{フレームワーク名} が好きな（もしくは好きになった）メンバーが集まっていて、チームの最適解として {フレームワーク名} を選択しつづけている、という現状が「理由」です。そしてプレースホルダーは私のいるチームでは Angular が当てはまります。
私にフロントエンド開発の楽しさや学びを与えてくれる Angular、ひいては jQuery や AngularJS まで、それらのリリースやサポートに関わった開発者のみなさんに感謝を込めて、今後さらなるアップデートに期待しています！
明日は https://qiita.com/negishi292 さんの投稿です。よろしくお願いします！