Angularへのリプレースを決めた理由
なぜ旧AngularJS環境のリプレースにAngularを選んだのか。以下のポイントが決め手となりました。
-
これまでの積み重ねと経験値を活かせる
- すでに旧AngularJS時代からTypeScriptで記述しており、メンバーがTypeScriptでの記述・実装に慣れていた
- 旧AngularJS/Angular間で基となる設計思想は似ており、Service層のビジネスロジックはある程度転用可能だった
-
テンプレートHTMLに対してもコンパイル時にエラー検出ができる
- 旧AngularJSはHTML内に誤ったマークアップを行なってもWebブラウザで実行するまでエラーとして検知できなかったが、Angularではコンパイル時にチェックされるようになった（デザイナーも安心してテンプレートHTMLのコーディングができるようになる）
-
公式コマンドラインツール「Angular CLI」の秀逸さ
- プロジェクトの作成からビルド作業まで、一連の作業がコマンドラインで可能で、開発作業の効率化が見込める
- ユニットテスト、e2eテストの実行環境も内包されており、複雑な設定なしですぐ使い始められる
-
Angularのロードマップが明確である
- Angularチームによるメジャーリリースが半年ごと、またパッチリリースが毎週提供されることで、サービスの長期的な運用が確立できる
-
周囲の好反応
- 同僚のフロントエンドエンジニアにも触れてもらったとき、ポジティブなフィードバックをもらう（なんだかんだでこういう理由は大きい）
あとは、包み隠さず言うと、Angularが気に入っていて、Angularに愛があったからかもしれません（笑）。
Angularを運用していく確信と覚悟が持てたので、最終的にはフロントエンドフレームワークを旧AngularJSからAngularに移行したい旨を上司に提案しました。新しい技術を試してみる文化があり、またこれまでの機能拡充で積もってしまった技術的負債に対する課題感もあったことで、提案は比較的すんなり通りました。
Angular移行にあたって始めたこと
公式ドキュメントを翻訳して読み合わせた
Angular移行プロジェクトを立ち上げた後、Angularの公式ドキュメントを輪読形式で読み合わせることにしました。公式ドキュメントのチュートリアルを除くほぼ全ページを、事前に有志メンバーで公式ドキュメントの翻訳分担を行い、お互いの知見や認識を共有する会を1時間×週2回開催することで、メンバーのAngularの全体像と実装方法に対する理解が深まっていきました。
翻訳が終盤を迎えていた一部ページにおいて、気付けばAngularのバージョンアップによって公式ドキュメントの内容が大きく変わってしまっていた……なんていうハプニングもありましたが、公式ドキュメントからAngularの全体像を頭の中にインプットできたことで、なにか問題が出た際も「そういや公式ドキュメントのあのページに確か書いてあったな……」と索引付けができたことはとても大きかったです。
翻訳成果物を本家へ還元
チーム内だけで翻訳後のドキュメントを保管しておくのはもったいないので、翻訳したドキュメントの一部はangular-ja（Angularの公式サイトを日本語に翻訳するオープンソースプロジェクト）に還元しています。
後編に続く
後編では、実際にAngularでWebアプリケーションを再構築していく中で、中長期的な運用を行なうにあたって採用したアプローチを中心にお話したいと思います。
