こんにちは、主にフロントエンド周りを担当させて頂いているSと申します。
いきなりですが「良いcss」とは何でしょうか。
- validなcss
- tableを避けてdivやulで擬似的に表現するcss
- cssで表現できる事はcssで表現しているcss（svg,data URI,animationの利用）
- postcssなど最新の技術を取り入れているcss
- styleguideを作成しているcss
確かにこれらは「良いcss」ですが、それだけでは足りません。
「良いcss」は「良いアーキテクチャ」である事が必要です。
幸運な事に私たちには、oocss,smacss,bemなどの素晴らしいアーキテクチャがありますが、単純にこれらを利用するだけでは「良いアーキテクチャ」にはなりません。
「良いアーキテクチャ」にするためには
- 理解しやすい
- 探しやすい
- 修正しやすい
という3つの"-able"が必要なのです。
本記事では私が3つの"-able"を満たすために重要だと考えるtipsを、3回に分けてつらつらと書いていこうと思います。
初回は「理解しやすいcssアーキテクチャにするためのtips」です。
小生、twitterの140文字も超えられないもので拙い文章になりますが、最後までお付き合い頂けると幸いです。
tips1 : 力を入れるべき配分は 8:2
私がcssを書く時に力を入れる配分は、アーキテクチャ8割、コーディング2割 でおこなっています。
良いアーキテクチャは良い名前をうみます。そして、これらは探しやすさ、理解しやすさ・修正しやすさをもたらしてくれるからです。
一度、エクセルやUML、マインドマップなどのツールを用いながら、時間をかけじっくりと良いアーキテクチャを構築して見てください。私が言った事が真実であると分かるはずです :)
tips2 : 要素の特性を明記しよう
例えば、oocssの設計思想として Separate structure and skin（構造と見た目の分離） があります。
その例としてよく下記のコードが出されますがこれは例としては良いコードではありません。
<button class="btn btn-blue">ボタン</button>
確かにこのコードは読みやすいですが、この質問に答えることは誰もできないはずです。
「何のためのボタン？」
- btn = ボタン
- btn-blue ＝ 青いボタン
ボタンの特性上、必ず「目的」がありますが、このボタンからは「青いボタン」であるということ以外何もわかりません。
要素の特性（この場合は目的）を明記することで「理解しやすいコード」になります。
<button class="btn btn-error">ボタン</button>
tips3 : 略称ダイエットはリーサルウェポン
webサイトの高速化はユーザー体験を向上させる素晴らしいデザイン手法であり、最も重要視すべき項目の一つで、その方法として「ファイルサイズのダイエットのためにクラス名を略称化する」がありますが、過度な略称は避けるべきです。
下記コードはgoogle検索結果ページから抜粋し、一部修正したhtmlになります。
<div class="rc"> <h3 class="r"> <a href="XX">hogeとは</a> </h3> <div class="s"><div> <div class="f kv _SWb"> <cite class="_Rm bc">aaa › bbb › ccc</cite> <div class="action-menu ab_ctl"> <a class="_Fmb ab_button" href="#"> <span class="mn-dwn-arw"></span> </a> <div class="action-menu-panel ab_dropdown"> <ol> <li class="action-menu-item ab_dropdownitem" role="menuitem"> <a class="fl" href="xxx">キャッシュ</a> </li> <li class="action-menu-item ab_dropdownitem" role="menuitem"> <a class="fl" href="XXX">類似ページ</a> </li> </ol> </div> </div> </div> <span class="st">abcdefg...</span> </div>
このrc, r, s, f, flの意味が分かる方が一体何人いるでしょう。
スタイルガイドなどのドキュメントを読まなければまず理解できない略称です。
メンバーが成熟した時に、高速化の最後の方法として行いましょう。
tips4 : 無意味な連番
名付けに困ってつい連番で逃げてしまうことがあるかもしれませんが、それは今日で終わりにしましょう。「過度な略称」と同じ、いや、「過度な略称」よりも悪い命名です。
何故ならば、ドキュメントに連番である意味は書きようがないからです。
<ul> <li class="list01">hogehoge</li> <li class="list02">piyopiyo</li> </ul>
tips5 : 「ちょっとだけ」が命取り
安易な命名や追加、追記を行ってはいけません。 例えタイトなスケジュール、言語化できないユニークなコンポーネントの大群に襲われたとしても、です。
何故ならば、その行為はwebサイト・アプリケーションはじわじわと蝕ばみ、気づけば誰の手にも負えないほどの重症を負わせる事になるからです（経験のある方も多いことだと思います）。それは2年後かもしれませんし、もしかしたら1週間後かもしれません。
「ちょっとだけ」。
その気持ちが後々の自分たちの首を締め上げる事になるのは想像できるでしょう。
tips6 : リファクタリングは定期的に
リファクタリングを定期的に行い、読みやすさを維持・向上していきましょう。
読みやすさはcssの保守性を維持するためにとても有効な手段となります。
tips7 : デザイナーとのコミュニケーションを欠かさない
時としてデザイナーがとんでもないモンスターに見える事があるかもしれません。 ですが決してモンスターボールを投げつけてはいけません。
我々はチームで1番の良き理解者でならなくてはならないのです。 彼・彼女らの力添えなしにコンポーネントを言語化する事は大変困難な事です。
たくさん議論して、素晴らしいコンポーネントを生み出していきましょう。
ここまで読んでいただきありがとうございました。 次回は「探しやすいcssアーキテクチャにするためのtips」です。
