こんがらがったCSSと向き合う – 方針の立て方

以前の記事では Gaji-Labo がCSSのリファクタリングを行う際に最初に見る部分をまとめてみました。
今回はある程度の問題を把握したあと、どのように作業を進めていくかの検討について書いてみたいと思います。

対象範囲を見定める

サービスやアプリケーションの規模や複雑さによって改修の方針もバラバラになるかと思います。
抱えている課題が比較的軽い場合（以前の記事で上げた点などがそこまで深刻でない場合など）は既存のソースコードをまとめて改修することも可能です。

しかし、いくつかの理由によってまとめて改修することが適切でない場合があります。

• CSSやHTMLを一箇所触るだけでどこに影響が出るか全く読めない
• 絶対に壊れてはいけない機能を有している
• 更新頻度も低く改修するメリットが少ないページや機能が大量にある
• サービス開発を止めず、運用しながら徐々に改善していきたい
• etc…

これらのようにアプリケーション全体を横断的に変更することが適切でない場合は、主要なページから徐々に綺麗にしていくのが理想です。
対象となるページは下記のような意義の大きい部分から着手することをおすすめしています。

• 頻繁にユーザーの目に触れるページや機能
  • 反響が大きいページなので頻繁に更新して課題の検証などに使えると有意義
• サービス上重要なページや機能
  • 課題や効果検証の速度をあげるためにクリーンな状態を維持
• 関係ない修正などで壊れやすい経緯があり、ユーザーへの影響が大きいページや機能
  • フォームなど重要な動線で壊れやすくなっている場合、優先してクリーンな状態を維持できると安心

決めること

• 全体改修か部分改修か決める
• 部分改修の場合、最初の対象範囲を決める

クリーンな環境を用意する

改修の対象範囲を全体とした場合も、個別ページや機能とした場合も最初に行う作業は「クリーンな環境を用意する」ことです。
既存コードを引き継いだまま行う場合はこの作業自体が改修のほぼすべてとなってしまう場合もあります。

しかし、個別に対応を進める場合は新規の CSS ファイルを用意するのが妥当かと思います。
下記のような状態の CSS ファイルが用意できるか検討します。

理想は normalize.css や reset.css のようなブラウザ差異を吸収する CSS と base.css のようなサービス全体のトーンなどを指定した CSS のみの状態から始められることです。（Sass 変数などで綺麗に管理出来る場合は base.css すら不要かもしれません。）
それらが現実的でない場合でも、基本的な要素（section, div, h1-h6, p, ul, ol, li, table, tr, th, td, span, a, img, ….）そのまま使用して意図しないスタイルが当たらない状態は必ず作りたいところです。

決めること

• 新規のCSSを用意するか既存CSSを引き継いで修正するか決める
• 既存CSSを引き継ぐ場合はクリーンな環境を用意できるか十二分に精査する

名前空間を区切る

既存コードを引き継がない場合はソースコードのディレクトリ src/assets/{CODE_NAME_v1}/css のようにし、コードネームなどで名前空間を限定すると良いです。
これによって、改修進めた部分と改修していない部分とを綺麗に分けられるので、運用時に結局混ざってしまって元に戻ってしまうリスクを減らせます。

このコードネームの短縮形を今後作成するコンポーネントの接頭辞とすることで命名の衝突を避けられるのであわせて推奨したいです。

また、コードネームはメンバーが愛着を持てる名前にすることで浸透を促進できるので良い名前を考えられるととても良いです。（最終的にはガイドラインやライブラリ一覧などを整備し、その呼称になると最高ですね。）
全員が認知することで「【コードネーム】なページは安全だから見積もりがしやすい」や「【コードネーム】なページではコンポーネントの整備がまだ途中なので〇〇をする必要がある」のような具体的で踏み込んだ会話がなされる傾向にあると感じています。

決めること

• 愛されるコードネームを用意する
• 作業対象にあわせた名前空間を設計する
  • ディレクトリ名の決定
  • （必要に応じて）コンポーネントの接頭辞の決定

汎用コンポーネントを洗い出す

アプリケーション全体で広く使われるコンポーネント（ここでは汎用コンポーネントとします。）を洗い出します。
既存のアプリケーションでUIが綺麗に設計されて管理維持されている場合はただ列挙するだけで済む場合もありますが、多くの場合歴史的経緯で役割の重複するコンポーネントが複数現れたり、本来必要なコンポーネントを用意できず別のもので代替している場合もあるかと思います。

コンポーネント数が多い場合、アプリケーションはどんどん複雑になっていく傾向があります。
極力汎用コンポーネントでまかなえないか検討し独自のコンポーネントの数を減らせると、デベロッパーやデザイナーが把握しなければならない情報が減り、結果的に開発速度にも良い影響を与えます。
※コンポーネントの精査大事です！！！

• 見出しコンポーネント（h1 から h6 までルール化されていると理想です）
• リード文や通常の段落コンポーネント
• リストコンポーネント（ol, ul 相当、ネストのパターンも考慮）
• 表組みコンポーネント（レスポンシブウェブデザインも考慮）
• 画像とキャプションをセットにしたコンポーネント（画像はキャプション付きを原則としておくと後々の調整が少なくおすすめです）
• 各種フォームパーツ
  • テキストフィールドやラジオボタン・各種ボタンなど個別のパーツ
  • 入力フィールドとラベルなどをセットとした入力フォーム全体の凡例（実際のアプリケーションにあわせて数パターン設計されていると理想的です）
  • エラー時の表現
  • 確認時の表現

少なくともこれらは現在使用されていなくても整備しておくと後々の開発効率があがるので整備しましょう。

決めること

• 作成する汎用コンポーネントの決定
• 既存コンポーネントをそのまま使うか新たにUIデザインから行うか決定
  • 部分的にアップデートするという判断もありです。

特殊コンポーネントの洗い出し

改修対象ページで汎用コンポーネントではまかないきれない物は一点物のコンポーネントと作成します。
「汎用コンポーネントを洗い出す」でも触れたとおり、コンポーネント数は少ないほど開発速度にも良い影響を与えるので、既存が一点物のコンポーネントだったとしても一旦は汎用コンポーネントが使えないかを検討してみてください。

その上で、汎用コンポーネントでは機能的に対応できなかったり、強調・ブランディング・細かなチューニングのために汎用コンポーネントではない方が良いものについては専用のコンポーネントを作成します。
重要なのは闇雲にコンポーネント数を増やさない事であって、必要なものについてはしっかりと作成していくのが肝要です。

決めること

• 汎用コンポーネントではまかなえないコンポーネントの洗い出し

まとめ

ここまでのステップで作業対象となるページ数とコンポーネント数がだいたい見えてきました。
これで必要なリソースとスケジュールの検討ができるようになりました。

また実際に作成する（もしくは移植する）コンポーネントを俯瞰することで作業の全体像も見通しやすくなったのではないでしょうか。
これによってどのタイミングでリリースするか（全部まとめてリリースするのか、さらに細かい単位でリリースしていくのか）なども検討可能になっているかと思います。

ある程度の作業ステップが見えてきたので、次回は各フェーズにおいて Gaji-Labo が特に気をつけている点などをまとめていけたらと考えています。（予定は未定です。これ結構書くのしんどそう・・・。）

宣伝

自社内でCSSのリファクタリングをやりたいなーと思っているチームがいらっしゃったらぜひお声かけください。
実際の作業は自分たちで行う想定であってもお話伺います。
また初回のお打ち合わせについては無料で対応いたしますので、その場で気になっていることなどあれば是非ご質問ください。お時間が許す範囲でお答えいたします。
ご検討よろしくお願いいたします！！