フロントエンドエンジニア

CSSの設計を破綻させない「良いCSS」にする為の4つ定義

こんにちは、SHIBAKEN – @dec_shibaken – です

これからマークアップを初めて行く人に、是非考えて読んでいただければ幸いです。私の失敗談も含めて是非一度目を通して頂ければと思います。

  • Sassの知識が必要になります。あらかじめご了承ください!
  • BEMの設計思想を学んでおくことが前提になります。以下の記事を是非、参考にしていただければと思います。

CSS設計手法と「良いCSS」にする為の4つ定義

CSS設計手法は、端的にいうとclass設定の規約を厳密化させたもの、、っていう理解の仕方がすごくシンプルでわかりやすいのかなと思います。

CSS設計を考える前に一度4つの定義を理解しておくと良いと思います。

「良いCSS」にする為の4つ定義
※GoogleのエンジニアのPhilip Waltonさんのお言葉をお借りしました

予測しやすい(可読性)

期待通りに振る舞うことができ、追加・更新したときに意図せず、他に影響が出ないような作りであること

再利用しやすい(再利用性)

既存のパーツから新しいコンポーネント(部品)を速くつくることができる状態であること

保守しやすい(メンテナンス性)

新しいコンポーネント(部品)と機能が追加・更新されるか、再編される必要があるとき、その都度、既存のCSSのリファクタリング(整理)を必要とする作りであってはならない。

拡張しやすい(拡張性)

ひとりの開発者か、大きなチームかを問わず、容易に管理できることを意味する。またそのサイトのCSSアーキテクチャに、学習時間を必要することなく容易に近づけるという意味でもある。

設計を考える理由と私の失敗談

CSSはスタイルシート言語です。マークアップを行う方にとっては、htmlコーディング時に不可欠なものではあり誰しもが必ず利用する言語となっています。

とても簡単であり、コード規約が少ないため、誰でもチャレンジができる敷居の低いものだと私は理解しています。

しかし、簡単であり自由であることが時に恐ろしい結果を招くことがあるんですね・・

私の経験談なのですが、

ほとんどのサイトは基本的に継続的な運用を想定していますので、コーダーは運用を想定した作りにしておかなければなりません。当時の私は想定ができず、スピードを意識するがあまりにその場しのぎで闇雲に記述を行ってしまいました。

それが悲劇の始まりでした。

サイト全体に影響の出る共通部分のスタイルを壊してしまい、本番サイトのレイアウト全てを崩壊させてしまったのです。

関係者は大激怒し、会社まで直接電話でクレームが何十件も届き、スタッフ全員で火消しを行うまでの騒動に至ってしまいました。

始末書レベルに発展し、沢山の方にご迷惑をおかけいたしました。

思い出すだけでも冷や汗が出るくらいです。一つのミスであったとしても大規模サイトになればその破壊力は半端ないです。

これが原因で私は、スピードだけでなく、破綻させない設計を考えるようになりました。

作るのがゴールではなく、スタートあるということを。

なぜそこまでのトラブルに発展してしまったのか、
具体的にいくつかピックアップしてみました。

設計崩壊の原因

  • クラス名が重複
  • スタイルの詳細度(ヒエラルキー)・!importantでの上書き合戦
  • HTMLの構造に依存しがちな作りになっている
  • コーディングルールが存在しない
  • コードレビュー文化が無い

6つほど出しましたが、実際はそれ以外にもあったのかもしれません。

導火線に火のついた爆弾が私のタイミングで爆発した。。そんな感じです。

当時は数名で運用を行っていたのですが、上記の挙げた原因が日々積み重なり、私のタイミングで壊れた。。そんな感じです。

今更なのかもしれませんが、前述の「4つの定義」を少しでも理解していれば、原因を作ることにもならなかったのだと思います。

いかがでしたでしょうか?
サービス運用を行う企業さんにとっては本当に致命的な問題になると思います。

私が言うのもなんですが、一人の責任にはできません。

小さな火種は必ず大きくなります。
当事者だけでなく、ディレクターなども交えてコードレビューを確実に行い、壊れない設計を目指していきましょう。

フリーランス / ブロガー
SHIBAKEN
埼玉生まれ東京育ちの独身30代男。 都内の出版社でWebデザイナーとして就職。その後転職し、制作会社でフロントエンドエンジニアとして6年間従事。 現在は会社を退職し、フラリフラリと風に吹かれながらフリーランスとして現在に至る。

プロフィールの詳細はこちら
\ Follow me /