4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

このままやったらフロントエンドエンジニアになれへんで!Advent Calendar 2022

Day 3

中途半端な導入は後で痛い目見ることになるで!CSS設計を導入する時のBadケースと回避方法

Last updated at Posted at 2022-12-02

私が入社した当時弊社サービスは10周年を迎えようとした時で、CSS設計は導入されてませんでした。
その後SMACSSを導入し、6年程が経ちました。

CSS設計の導入によって社員のリテラシーや技術は向上したことは間違いなく、CSS設計の運用ノウハウやメリットも得られたと考えています。

一方でCSS設計は長い年月運用していると反省すべき点が多くあります。

導入にはコストが掛かりますし、新しくメンバーをアサインしようとした時のハードルも上がります。

これまでの運用によって得られた知見をBadケースとしてまとめてみました。
導入を検討している方にとって何か1つでもお役に立てることがあれば幸いです!

CSS設計とは?

一般的にコードのメンテナンス性や作業効率を上げるために、CSSコードの管理の方法や命名規則の考え方のことです。
良いCSS設計の条件として「予測しやすい」「保守しやすい」「拡張性がある」の3つがあります。

一般的によく耳にするCSS設計は3下記の3つだと思います。

  • BEM
  • SMACSS
  • FLOCSS

ちなみに、私が関わるサービスでは、SMACSSとFLOCSSを利用しております。

  • CSS設計導入することで生産性が上がりそう!
  • CSS設計ってすごいやん!

となっているところ恐縮ですが、主題の「CSS設計を導入する時のBadケース」に話題を移します。

CSS設計を導入する時のBadケースって?

冒頭でも書きましたがCSS設計は非常に難しいです。
その上でこれだけはやってはいけない!ってことが1つだけあるとすれば…

それは、『導入を中途半端に終わらせてしまうこと』です。
つまり、中途半端な導入によってサイト全体のCSSの記述や管理ルールから一貫性を失ってしまうことがBadケースになると考えています。

CSSの記述や管理ルールに一貫性がなくなった場合にどのような問題が発生するか詳しく説明していきます。

CSSの記述や管理ルールに一貫性がなくなった場合発生する問題

大きく分けて下記の2つだと考えています。

  • 教育・採用コストの増加
  • 開発工数の増加

教育・採用コストの増加

大前提としてCSS設計に関する知識を持っている人材を探さないといけません。
加えて古くからあるCSSと新しいCSSが共存している状態なので、コードを見ても正しいCSSの記述方法の予測がつかない常態のため問い合わせやサービス固有のローカルルールを教えるのに多くの工数を必要とするでしょう。

開発工数の増加

導入が中途半端になるとさまざまな命名ルールが入り乱れることになります。
また、古くからあるスタイルはidで指定してあるとするとCSSの詳細度があがることによって新しく定義したCSSが上手く当たらない事態が発生します。

命名が難しくなるだけでなく、CSSのオーバーライドによって試行錯誤や調査などCSSの見通しが悪くなり多くのメンテナンス工数がかかることで開発工数が増加します。

どこか一部だけでなく、サイト全てに導入する計画を立てて実施に踏み切ってほしいと切に願います。
導入して間もない頃は良いですが、5年も経たないうちに運用に無理が出てくることは間違いないと断言します

導入後にBadケースにならないための対策

とはいえすでにCSS設計で運用している、今まさに導入途中だという方のために…
やっておけばBadケースを回避できるかもしれないと思う方法を紹介しておきます!

1つのモジュールに対してバリエーション数の上限を決めておく

サービス改善が行われる限り一定のルールを設けないとパターンは無限に増えていきます。

  • ちょっとpaddingが広い
  • 文字が大きい
  • キャプション付き
  • コンテンツに枠線がある

という具合です。

例えば、モジュールのパターンは3つまでと決めておけば4つ目を作ろうとしたときに…
「4つ目になるけど、他にいらないパターンはある?今あるデザインとほとんど一緒なら統合したい」という相談の機会ができます。

モジュールが増える分断捨することをルールに設け、実施することでCSSの平和が保てるのではないかと考えています!

なんでも好きに記述していいようなsassファイルを1つだけ作っておく

サービスの改善スピードが速いサービスなどには有効だと思います。
ABテストで成果が出たとき実際にサイトに組み込んでいきます。
開発スピードを優先して、パフォーマンスやコードの奇麗さは二の次になることがしばしばあります

そんな時はいったん設計は無視していいと割り切って記述できるようなCSSファイルを用意し記述。
落ち着いたタイミングでリファクタリングしながら実装するタイミングを設ければCSSの見通しがよくなると考えます。

新しいモジュールの追加にはとにかく慎重に

モジュールを拡充する時は神経質になることが多いかと思いますが、新しく作る時は全く新しい命名でモジュールが作れるので意識が緩みます…。

もっというとネームスペースが確保されているためだと考えています。
長年運用するときにまず考えたいことがネームスペースをどうするか?ということです。

ネームスペースを確保するためにはできるだけモジュールを増やさないほうがいいのです。

似たようなモジュール等があった場合はデザインされた方に導入の意図や利用用途を聞いた上でじっくり話し合ってから追加を決定してもらうのがいいと考えます。

まとめ

CSS設計は奥が深く、これが正解というのはないと考えています。
それぞれのサービスにあったそれぞれの設計手法があると考えています。

また、CSS設計はあくまでも1つの概念なのでそのまま利用するのではなく、それぞれのCSS設計ルールの中で自社のサービスに合う形で変形させていけるといいのでは?と感じます。

CSSの見通しが良く保守性に優れたCSS設計の運用ができることを願っています。

4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?