そのCSS、ヤバイかも？CSS設計が破綻するありがちな失敗パターン4つ

セイト

2015.09.30

Web制作

こんにちは、LIGフィリピン支社代表のせいと(@seito_horiguchi)です。

ここ近年、Web界隈ではCSS設計というキーワードに注目が集まっていますね。
僕もこれまで、右往左往しながらいかにより良いCSSを設計できるかを考えてまいりました。
そして、そこに至るまでに実に多くの失敗をしてきました。。。ハハハ……。

そこで今回は、より良いCSS設計をするためにぜひとも避けたい失敗パターンを、僕の経験から発表したいと思います。俺の屍を超えてゆけ！

▼俺のCSSとコーディング

【CSS設計】拡張や修正に強いコンポーネントをマークアップする6つのテクニック

セイト

2015.07.24

コーディング中のクラス名で迷いたくない！よく見るコンポーネントの名前17選

セイト

2015.06.18

コーダーがおさえておきたいコーディングのツール8選

セイト

2015.05.07

本題に入る前に

本題に入る前に、今日はお知らせ（広告）があります。
実はですね、先日、CSS設計の本を執筆しましたー！

最強のCSS設計チーム開発を成功に導くケーススタディ

コンセプトは「現場で使える、実践的なCSS設計」です。
以下のようなポイントに当てはまる方は、ぜひ手にとってみてください。m(_ _)m

CSS設計を勉強したいとは思ってるけど、まだ本格的には動いていない
CSS設計の理屈はわかったけど、いざ実務でやると上手くいかない
SMACSSとかBEMとか方法論がいろいろありすぎて、どれをどう使えばいいのかわからない
CSSを設計する意義がわからない
CSS設計を実務に導入したいけど、絶対に失敗したくない

ということで広告はこれくらいにして、本題に入りたいと思いますっ。

CSS設計が破綻するありがちな失敗パターン4つ

1. ドキュメントがない

複数人で開発を行う場合、ドキュメントがないとコーディングルールをはじめとするさまざまなお約束事項をメンバー間で共有することができません。
その結果、命名規則が守られなくなったり、CSSの書き方がバラバラになったりと、設計がみるみる内に崩れていくでしょう。。。

加えて、もしあなたが開発に深く関わっていたとしたら、例えプロジェクトを抜けても今の担当者からFacebookやSlackで「ここのソースコードってどういう意味ですか？」という質問を頂戴しつづける羽目になりかねません。
そんな事態を避けるためにも、「コーディングルール」や「スタイルガイド」といったドキュメントを揃えておくことをおすすめします。

また、例え開発者があなた1人でもドキュメントはあったほうがいいです。
もし自分が病気でいきなり倒れたり、会社を辞めたりした場合、誰かにプロジェクトを引き継いでもらう必要があるからです。
そうしたときにドキュメントがないと、FacebookやSlackで（以下略

ぜひこちらを参考にしてみてください。

Google HTML/CSS Style Guide: Googleのコーディングガイド。HTML,CSSに関するコーディング時の注意事項が書かれている。
https://google.github.io/styleguide/htmlcssguide.xml

Bootstrap Components: Bootstrapのスタイルガイド。Bootstrapで使われているコンポーネントの一覧がソースコードと共に書かれている。
http://getbootstrap.com/components/

2. メンバーや開発期間のことを考えずにBEMとか使っちゃう

そのプロジェクトで、どのCSS構成案（OOCSSやBEMなどのCSS設計を実現する方法論）を採用するかは慎重に選ぶ必要があります。
例えばBEMは公式が英語で命名ルールもそれなりに厳しいため、CSS設計に疎い人がやるには敷居が高いといえます。
もし開発メンバーがCSS設計に疎かったり、事前に勉強しておくほど時間がないにも関わらずこうしたCSS構成案を採用してしまうと、開発をすすめるのは難しくなるでしょう。

その場合はOOCSSやSMACSSといった、比較的覚えやすいものを採用するほうが好ましいかもしれません。

OOCSS: オブジェクト指向の考えをCSSに取り入れたCSS構成案。多くのCSS構成案に影響を与えた。
http://www.slideshare.net/stubbornella/object-oriented-css

SMACSS: コーディングのより広い領域にまで言及したCSS構成案。電子ブック。CSS設計に関するノウハウがたくさん書かれている。
https://smacss.com/ja

BEM: CSS構成案。厳格な命名ルールが有名。
https://bem.info/

3. オレオレルールを作っちゃう

もしあなたがOOCSSでもBEMでもない、「俺が考えたすごいCSS構成案」を思いついてしまった場合、実行する前にちょっと思いとどまってください！

自分で考案した独自ルールというのは、まずきちんと機能するのか？がわかりません。何度もテストして十分に有用性を立証したというのなら話は別ですが、そうでない場合、実際に実務で試したらうまくいかない可能性も当然ありえます。

また、オレオレルールに関する情報はあなたが作ったドキュメント、もしくはあなたの頭の中にしかありません。
もし他のメンバーがわからないと感じたら、ぐぐっても情報はありませんから、真っ先にあなたに質問しに来るでしょう。
そうなった場合、その分自分の時間が削られることは覚悟しなければなりません。

ですから、CSS構成案はできるだけ既存のものを流用し、変えるにしてもちょっとしたアレンジに留めておくといいでしょう。
MindBEMdingのようなアレンジはいい例だと思います。

MindBEMding: BEMの原則を守りつつ、命名規則をアレンジした方法論。
http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/

4. コメントが皆無

CSSにもコメントを書くべきです！
コメントがないとクラス名やプロパティだけで内容を推測することになりますが、CSSを書いた本人以外の開発者にとって、それはなかなかハードです。
僕の場合は、以下のようなコメントを書いています。

SCSS

/*
#ボタンのデフォルトのコンポーネント。
```
<a href="#" class="button">button</a>
<a href="#" class="button button-primary">button-primary</a>
```
*/
.button {  
    display: inline-block;
    border-radius: 5px;
    background-color: #000;
    padding: 9px 25px;
    text-align: center;
    text-decoration: none;
    color: #FFF;
    font-size: 14px; 

	// メール送信やログインの際に使うボタン
    &.button-primary {
    	background-color: blue; 
    	padding: 12px 30px;
    	font-size: 15px;
    }
}

ここでは「これがどんなコンポーネントなのか」「使用するシーン」「HTMLタグ」などをコメントで書いています。
少し丁寧すぎるかもしれませんが、コメントは丁寧に越したことはありません。
時間に余裕がない場合はここまでできないかもしれませんが、なるべく意識するといいです。
また、スタイルガイドジェネレーターを使用している場合、こうしたコメントは大いに役立ちます。