本記事はNRIネットコム Advent Calendar 2021 2日目の記事です。
🦃 1日目 ▶▶ 本記事
▶▶ 3日目 🍗
喜早です。 前回はエモ目な記事を書きましたが、今回は本業のマネジメント寄りっぽい投稿です。
あるプロジェクトでのAngularを使ったフロントエンドの開発がなかなかにうまく回っていると感じているのでそのご紹介をしようと思います。 ちなみにタイトルをベストプラクティスではなくグッドプラクティスとしたのは、まだまだ改善の余地はきっとあるだろうという思いを込めて、永遠のβ版的な意味でつけました。
登場人物の担当領域
この話の中には、コーダーさんとフロントエンドエンジニアさんが出てきます。それぞれの担当範囲は以下のとおりです。
- コーダーさん:デザインをHTML/CSSで画面として構築する人
- フロントエンドエンジニアさん:コーダーさんが作った画面に対して、JavaScriptなどを用いて動的な動きを構築していく人
前提
このプロセスを実現する上では、2点、前提があります。この前提ができた理由は後述します。
- フロントエンドエンジニアだけでなく、コーダーさんもAngularの基礎知識を有して、コンポーネントを作ることができること
- チーム全員がgitを使え、運用フローを理解できていること
構築プロセス
以下のような流れで進めていきます
- デザイナーさんがデザインを決定する
- フロントエンドエンジニアさんが、決定したデザインに対してコンポーネントの構成を決める
- 前項で決めたコンポーネント構成をコーダーさん、フロントエンドエンジニアさんで共通認識を持つ。疑問点や懸念点があればこの場で議論しておく。
- コーダーさんがコンポーネント構成に従ってコンポーネントを作り、そこにHTML/CSSを当て込んでいく
- コーダーさんからHTML/CSS入りのコンポーネントをフロントエンドエンジニアさんに連携。
- フロントエンドエンジニアさんが動きを実装していく
コンポーネント構成について
コンポーネント構成については、デザイン画像に対してコンポーネントの割付を簡単に書いた資料(図参照)をフロントエンドエンジニア側で作り、それをもとに議論します。慣れてきたら、小さい画面であればコーダーさんにおまかせしてしまうこともあります。また、既存のコンポーネントの使い回しや拡張についても議論します。
ブランチ運用
前述のリストの3〜6についてはgit上で行っていきます。featureブランチを作成してそこからそれぞれのタスクブランチを切り、合流させるフローです。これを実現するためにGitは全員使える必要があります。
なぜこのフローにたどり着いたか。
プロジェクト開始当初、フロントエンドエンジニアさんもコーダーさんもAngularを使ったプロジェクトに関わるのは初めてでした。 Angularはコンポーネント指向のフレームワークです。コンポーネントという部品を作って、それらを組み合わせて画面を構築していきます。
コンポーネントに対するデザインの当て込みは、それぞれのコンポーネントごとにHTML/CSSを組み込むことで行います。 そのため、スムーズにHTML/CSSを取り込むためには、コンポーネントを意識したHTML/CSSの構造になっている必要があります。
ですが、スタート当初、コンポーネントの意識はフロントエンドエンジニアさんにはありましたが、コーダーさんにそのコンポーネントを意識して構築してもらうということを共有できていませんでした。 その結果、エンジニアさんが画面を作ろうとした際に、HTML/CSSをコンポーネントに組み込む際に、ほとんど再構成を行うという誰も幸せになれない事象が発生しました。
この反省から、開発を効率良くすすめるために、思い切ってコーダーさんにもAngularの基礎部分とコンポーネントを作ってそこにHTML/CSSを当て込めるようスキル習得をお願いしました。 コーダーさんにとってはフロントエンドのフレームワークは馴染みが薄かったと思いますが、快く承諾いただきました。感謝。
このフローの副次的価値
画面構築を効率的に進められる以外にも、副次的に以下のような点も得られているかなと思っています。
- リポジトリ内にHTML/CSSを連携するためだけのフォルダを用意する必要がない。
- HTML/CSSをコンポーネントに取り込むという作業が発生しないので、移植漏れのようなヒューマンエラーも発生しない
- HTML/CSSの微調整が必要な場合でもコーダーさんが完結できる。
以上、開発プロセスに悩んでいる方がいれば参考になれば幸いです。
NRIネットコム Advent Calendar 2021
🦃 1日目 ▶▶ 本記事
▶▶ 3日目 🍗