FLOCSSを2年間ほど運用した振り返り~導入編~

前回に続いて今回はFLOCSS運用振り返りシリーズ、導入編です。
既存のプロジェクトにFLOCSSを導入するのはやや大変ですが、自分の反省を踏まえた上での移行作業手順について書きたいと思います。

前提

当時自分がFLOCSSを導入しようとしていたプロジェクトについて少しおさらいです。

  • Sass(.sass)でスタイル実装している
  • サービスとしてはすでに運用フェーズ
  • 毎週何かしらの新規機能・ページ改修がリリースされている
  • Railsのapplication.sassに再利用されないスタイルが山積み

という状態だったので、いわゆる初期構築からFLOCSSを導入するケースとは異なり、既存のスタイルをFLOCSSへ移行&日々のリリースに組み込むという難しさがありました。

では早速導入手順を振り返ってみたいと思います。

役割分担

早速既存のスタイルをFLOCSSに移行していきたいところですが、 役割分担をしておいた方が良いです。
まず、移行作業とは2つの作業に大別できます。

  • 既存スタイルからFLOCSSに沿ったコンポーネントを作成する係
  • 出来上がっているモジュールを既存ページ・UIに反映していく係

自分の場合は、メインの移行担当者だったということもあり前者の役割を担当しました。
他の開発者のためにもサンプル実装があった方が親切かなと思いますので、せめて1ページだけでもFLOCSSに移行し終わった差分を移行作業前にマージしておくことをお勧めします。

コンポーネントが豊富なページから移行する

というわけで、他の開発者のためにもどこか1ページを先にFLOCSS移行しておきます。
この場合、再利用性が低いUIばかりのページを選定しないようお気をつけください。

あくまで目的はサンプル実装なので、極力使い回される可能性が高いUIが多いページを選びましょう
自分の場合はForm系のパーツがひしめく最も複雑なページを選びました。

移行第一弾のページが決まったらいよいよ移行作業に入っていきます。

先行しての移行作業

実際に移行作業を進める場合は以下の優先度で進めると良いかと思います。

  1. 再利用性が高いコンポーネント
  2. variable(変数)の追加
  3. LayerレイヤーのUI(ヘッダー・サイドバー・フッター・コンテンツエリア…etc)
  4. ページ特有のUI

また、これは反省点なのですが、初めのうちはFLOCSSのルールをよく読みながら慎重に移行していった方がよいです。
というのも、初めに定めたルールがその後の開発にずっと影響するからです。
例え間違った命名規則をつけてしまっと後から気づいても、初期構築時点から存在する命名規則だという理由だけで他の開発者が引っ張られてしまうため、やはり初めが肝心です。

一方、コンポーネント化については逆に頑張りすぎなくてOKだと思います
コンポーネント化は人によって解釈がぶれるのと、こだわればどこまで突き詰めることができるという奥深さを持っています。
あまり独自の解釈のみでコンポーネント化を進めてしまうと他の開発者と足並みを揃えにくいため、初めは70%くらいの完成度にとどめておき、周りの開発者とそれを見ながら認識を揃える作業をお勧めします

そんな感じでまずは1ページ仕上げてみましょう。

FLOCSSに沿ったディレクトリとファイルを配置しておく

これは自分がやっておけば良かったなぁという点なのですが、先行移行の中で作成しなかったモジュールなども、せめでそれらを格納するディレクトリ・ファイルだけでも作った状態で全員に共有すべきでした。

いちおう他の開発者にもFLOCSSのドキュメントは読んでもらっている前提ですが、初めのうちはどのスタイルをどのファイルに書けば良いのかわからずに混乱させてしまったのです。
念の為コメントアウトで「〜のUI関連のコンポーネントファイル」みたいな感じでファイルを初めから設置してあげると親切かなと思います。

全員で移行作業を進める

基本的なコンポーネントやLayerレイヤーモジュールがmasterブランチに組み込まれたことで、他の開発者も各々の開発の中で移行作業を進めることができます。

実はここから先が大変なのですが、メインの移行担当者は以下の作業に専念します。

  • 他の開発者が新たに追加すコンポーネント・モジュールはFLOCSSの思想に則っているかレビューで確認
  • 既存のコンポーネント・モジュールは適切にページ・UIに反映されているかレビューで確認

このフェーズでしっかりと開発チーム内にルールを定着させ、FLOCSSへの理解の属人化を解消しておくことが非常に重要だと思います。
自分の場合はここの時間をしっかりと抑えることができず、後になってから何度かテコ入れをすることになってしまいました…

また、担当範囲の分担についても当時はけっこう悩まされました。
例えば、Aページで使われているUIが、Bページでも使われており、開発者が異なる上に同時進行で進んでいる場合、どちらが先にコンポーネント化をするのか?という点で時間を食われました。

最悪なパターンとしてはどちらもコンポーネント化を行ってしまい、似たようなコンポーネントが2つ出来上がってしまうことです。
ということで、この場合はどちらか片方のみコンポーネント化を行い、もう片方はコメントアウトを残した上で該当箇所のコンポーネント化をスキップする、が良いかと思います。

そんなこんなで色々と気を使うことばかりですが、時間が経つにつれて移行作業は楽になっていくので最初だけ頑張りましょう。
コンポーネントやモジュールがある程度出揃うと、まるでBootstrapでも使っているかのようにclassを付与していくだけでUIを構築できるようになり、報われるときがいつかきます笑

おわり

こうして振り返ってみると、やはりこの導入フェーズが一番しんどかったです。
ただ上述したように、運用フェーズに入るとスタイルの実装から解放されて非常に快適な開発環境を得ることができます。

ということで、次回は導入・移行も終えての運用編について書きたいと思います。

ではでは