Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

大規模Angular SPA開発に立ち向かうためにアプリとUIを切り分けた話

BizReach Tech Blog 第4回(後編)

  • LINEで送る
  • このエントリーをはてなブックマークに追加

 ビズリーチで「HRMOS(ハーモス)採用管理」のフロントエンドエンジニアをしています、浅井です。前編では「AngularJSのリプレースにAngularを選んだ話」についてお話しました。 今回は、長期的にサービスを発展させていくことを念頭に置き、アプリケーションの規模やチームメンバーの人数が増えていってもスムーズに開発・メンテナンスしていくために、AngularでWebアプリケーションを再構築していく中で盛り込んだことをご紹介したいと思います。

目次

AngularJS時代の課題

 せっかくAngularに移行するからには、「AngularJS時代からの負債は引き継ぎたくない、メンテナンスしやすい仕組みにしておきたい」というのがチームメンバー全員の想いとしてありました。

 まずは、AngularJS時代に実装・運用フェーズで感じていた課題を洗い出したところ、

  • ページ単位で似たようなUIが別々に作られている
  • ゆえに、UIの改善を行なう画面を洗い出すのが大変。すべての画面で一貫性が担保できているのかわからない

という大きな課題がありました。

 これは、(Angularの醍醐味でもある)コンポーネント指向で一から書き直せば解決できると考えました。

アプリケーションから独立したUI Componentsライブラリを開発

 「HRMOS採用管理」は、採用担当者向け/エージェント企業向けと、利用者に応じた複数のAngularアプリケーションが存在します。

 これら複数のAngularアプリケーションで共通のUIを利用できる基盤があれば、上述した「AngularJS時代の課題」を解決できるのではないかと考え、UIに関わるコンポーネント(UI Componentsと呼ばれる)をAngularの1ライブラリとして別で集約することにしました。

 UI ComponentsライブラリをGitHubの別リポジトリで管理して、npmのプライベートパッケージとして公開することで、Angularアプリケーションが利用できる基盤となります。別リポジトリにすることで、採用管理アプリケーション開発とは独立したUIコンポーネントのリリースフローを回せるようになります。

 Angularアプリケーション自体の再構築を進めながら、このUI Componentsライブラリも並行で開発することにしました。アプリケーションのアーキテクト設計に強いフロントエンドエンジニアと、UI設計に強いフロントエンドエンジニアという志向性の異なるメンバーがいたため、分業体制をとることができました。

 まずAngularJS環境で使われているUIを洗い出し、ボタンや入力フィールドといった、インタラクションが単純でかつアプリケーション内で頻出するコンポーネントから開発に着手しました。

使われているUIを洗い出して書き出したところ。およそ30種類のコンポーネントを用意する必要がある
使われているUIを洗い出して書き出したところ。およそ30種類のコンポーネントを用意する必要がある

  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

バックナンバー

連載:BizReach Tech Blog
All contents copyright © 2005-2018 Shoeisha Co., Ltd. All rights reserved. ver.1.5