見出し画像

メンテナンス性の高いCSSコーディングが大切な理由

TAK / Web Creator.

はじめまして！TAK(@tak_dcxi)と申します。

noteのアカウントを取得して数週間経つのですが、一度も投稿をしていないはずなのにフォロワーが15人もいたのでそろそろ手を出さないとなーと思いながら書いております。

今後もnoteを投稿していこうとは思っておりますが、僕が投稿するnoteは基本的に自分自身への備忘録のつもりで書いています。

今回のnoteもあくまで自分の感想の紹介であり、世間一般の考え方とは違うものも含まれます。あくまで参考としてご覧いただけますと幸いです。

# なぜ丁寧なCSS設計が求められるのか？

簡単に言えば以下の点です。

- 保守性・メンテナンス性が向上する
- 複数人でコーディングを行う際に作業がスムーズに行える
- スケールの大きなwebサイトに対応しやすくなる

まず、「保守性・メンテナンス性が向上する」という点ですが、これはめちゃくちゃ大切です。

Webサイトは制作してローンチして終わりではありません。むしろローンチして運用してからが本番です。(多くの制作会社やフリーランスはWebサイトを納品して終わりというケースが大半ですが)

運用する上でコンテンツの更新は必ず行われますし、場合によっては大きな改修が行われることも多いでしょう。
その際に、丁寧なCSS設計が行われていてメンテナンス性の高いコードを書いているとスムーズに更新・改修を行うことが可能です。

逆にスパゲッティコードと呼ばれるような設計がぐちゃぐちゃなCSSで書かれていると修正や改修の時に困りますし手間がかかります。この辺はwebサイトの更新に携わった方なら身をもって実感できているはずです…。

次に「複数人でコーディングを行う際に作業がスムーズに行える」という点ですが、CSS設計をコーディングのルールとして決めることでコードの均一化を図れます。

複数人でコーディングを行う際にみんながオレオレルールだと担当した人によってCSSの書き方が全く異なり、他の人がそのCSSを修正する時に作業がスムーズに行えなくなりますし、場合によってはCSSの世紀末化も避けられません。スポーツでもゲームでもコーディングでもルールは大切なんですね。

最後に「スケールの大きなwebサイトに対応しやすくなる」に関して。

ペライチのLPなどの場合はCSS設計が整っていなくても困らないかもしれませんが、大規模なサイトの制作など、ページ数が何十もあるサイトを構築する場合にCSS設計がしっかりされていないとグダグダになります。

パーツ（コンポーネント）ごとにCSSを記述すればあらゆる箇所で使いまわしを図れますし、設計手法を決めてCSSを書くことでスケールの大きなwebサイトを構築する際も管理が行き届いたCSSを書くことができるようになりますね。

# 「スケルトン・インフィル」に学ぶWEBサイトの構築

以前ツイートしてそこそこバズりました。

建築にはスケルトン・インフィルと呼ばれる建築手法があります。

スケルトン（建物を支える構造駆体）とインフィル（住戸内の間取りや内装・設備）を分離した建築手法をスケルトン・インフィルと呼びます。
耐久性が高いスケルトンに対し、ライフスタイルに合わせて間取りや内装を変更するなど柔軟性が高いインフィルと、はっきり分離することによって、容易に間取り・設備の変更やリフォームできるなどのメリットがあります。
（「不動産・住宅情報サイトLIFULL HOME'S 不動産用語集 『スケルトン・インフィル』より引用）

建物は大抵、建物そのものより先に内装にガタが来ます。

エアコンの製造メーカーは平均寿命を10年程度に設定していますし、ガス給湯器も一般的に寿命は約10年とされています。

もし、構造と内装が一体化している場合、内装を修理・交換するために建物に穴をあけるなどのダメージを与える必要があり、それを行うためのコストも掛かります。

また、間取りを後から変更したいとなった時も構造と内装が一緒の場合、大規模な工事と多額の費用が必要となります。

スケルトン・インフィル住宅ならメンテナンス性に優れているため、内装が壊れても建物にダメージを与えないで交換が可能なため建物の寿命を延ばすことに貢献できますし、今まで建物にダメージを与えるために必要だったコストを抑えることができます。

また、レイアウトの変更に関しても構造を弄らずに可能になるため、ライフサイクルの変化によって柔軟に内装を変えることができますね。

webサイトもこの「スケルトン・インフィル住宅」のように構造と内装をしっかりと分けることでメンテナンス性に優れたサイトを構築することが可能なはずです。

実際、Googleのコーディング規約には以下のような文言があります。

HTML(構造)とCSS(見た目)とScript(振る舞い)は独立させて、3つの相互関係はなるべく最小限にする。
ドキュメントやテンプレートにはHTMLだけを含むようにし、HTMLには構造だけを表現するようにする。
見た目に関するあらゆる内容はCSSへ、振る舞いに関してはScriptへ記述する。
HTMLからCSSやScriptへのリンクはなるべく減らし（まとめて）、互いのファイル間の接触部分をなるべく少なくする。
メンテナンス面を考慮すれば、構造、見た目、振る舞いの分離は重要。CSSやScriptの更新よりも、HTMLドキュメントやテンプレートの修正コストのほうが常に大きい。
（「Google HTML/CSS Style Guide」より引用）

HTMLは文書の構造を表し、CSSはHTMLで作られた構造に装飾やレイアウトをほどこすための言語です。

構造と装飾を一緒くたにするとスタイルを優先するあまりにセマンティックではないHTML構造を書いてしまったり、見栄えを変えるためにHTMLを変える必要が出て、HTMLが変わったことにより周囲のHTMLも変える必要が出る…といった感じでメンテナンス性が非常に落ちます。

例えば以下のようなCSSの書き方はメンテナンス性を落としやすいです。

- インラインスタイル（HTMLにstyle属性で直接スタイルをあてる）
- タイプセレクタ（見出しタグやdivやspanなど、変更や追加がされやすい要素に直接CSSを指定する）

これらが決して悪いとは言いません。

実際、僕はbackground-imageはCMSの管理画面からの更新で都合がよいのでstyle属性で行っていますし、Gutenbergのデフォルトの見出しブロックには固有のclassがついていないので.p-post-content h2:not([class])のように記述することもあります。（他のh2要素と干渉を起こさないように:not([class])を付与してクラスのついていない時だけに限定しています）

とはいえ、これはあくまでイレギュラー対応です。

TrelloのCSSコーディング規約には「Make sure every selector is a class. (すべてのセレクタをクラスにするということを守りましょう)」という記述があります。全てのセレクタにclassはやりすぎ感が否めないものの、classで管理すればHTMLが変わっても柔軟に対応できるので、HTMLタグには極力classをつけてclassにスタイルをあてた方がメンテナンス性はめちゃくちゃ上がります。

また、JSに関してもCSSで使われるclassにJSで振る舞いを指定すると、将来的にスタイルは必要だけれどJSでの振る舞いは不要、またはその逆というケースが出てきたときに変更する手間がかかります。

同じくTrelloのCSSコーディング規約に「Separate style and behavior concerns by using .js- prefixed classes for behavior.(js-というプレフィックスの付けたクラスを利用して見栄えと振る舞いに関連するクラスを分けましょう)」という記述があるように、見た目と振る舞いの分離もまた重要です。
僕もTrelloに倣い、JSで使うclassとidにはjs-プレフィックスを付与してJSで使われているそれらを分かりやすく区別しています。

# メンテナンス性の高いwebサイトを作りましょう

冒頭でも述べたようにwebサイトは作って終わりではなく、作り終えて公開されてからが本番です。

CSS設計がぐちゃぐちゃだと、今見た目が綺麗に整っていても将来メンテナンスをする際に一から作り直されることもあるかもしれません。

せっかく手塩にかけて作ったwebサイトが破壊されてその上に新しいwebサイトが建設されていたらめっちゃ悲しいじゃないですか。

Mr.Childrenの櫻井さんも自身を育ててくれた景色である幽霊屋敷がマンション建てるためにキャタピラに踏みつぶされたことについて感傷に浸っていましたね。

大切なwebサイトを長生きさせるためにも、現在(いま)だけでなく将来(みらい)も見据えてコーディングしましょう。

おわり

※そのうち需要があれば自己流のCSSコーディングガイドラインを書きます。


愛と平和