はじめまして！デザイナーのきよえし(@kiyoe_furuichi)です。 ママリ、ママリQ のUIデザインとフロントコーディングを担当しています。最近暑すぎて溶けそうです。スイカたべたい！
さて今回は、爆速で拡大成長中のママリが行っている『よりよいCSS設計のための開発手法』についてまとめてみました。
『よりよいCSS設計』を考える
「あれ？スタイル効かない…!importantしよ♡」
身の回りでこのようなことは起きていませんか…？ 意図しないことが頻繁に起こる場合『CSS設計』の見直しが必要かもしれません。
私たちは普段からサービスを成長させていくにあたって『よりよいCSS設計』とはなにかを考え、チーム内で検討し、改善をおこなっています。
そんな私たちが実践している開発手法や取り組んでいることについて、いくつかご紹介していきたいと思います。
きっかけ
はじめに、私が『よりよいCSS設計』を考えはじめたのは、他のエンジニアさんと一緒にフロント開発をすることになったときに自分の不甲斐なさを感じたのがきっかけでした。
これまでひとりでデザイン/フロント実装を受け持っていた経験しかなく、他のエンジニアさんが書いたコードをレビューする、また私が書いたコードをレビューして頂くことが初めてのことでした。そこでいかに自分の書き方が負の遺産を生み出す書き方をしていたかを知って、悔しくなったので改めてCSSのことを勉強し直しました。
それを機にCSSの書き方や、設計について深く興味を持つようになり、今ではサービスにとってそれが『よりよい設計』であるか、またその設計がユーザー体験(開発者含め)、にとってどう良いのかを考える『CSSおねえさん』へと進化しました！
CSS Architecture
私たちの考える『よいCSS設計』の定義は、色々検討した結果、1番納得感のあるPhilip Waltonさんが提案するCSS Architectureをベースとして考えることにしました。
CSS Architectureでは、以下のようなCSS設計をする上で目指すべき4つのゴールを掲げています。 他にもバッドプラクティスの改善方法など、よりよい設計のためのポイントがいくつか提案されています。
1.『予測しやすいこと』
追加や更新をしたスタイルがちゃんと期待通りに振る舞うことのできる設計にしましょう。 そのスタイルが意図していない箇所に影響を与えないようにすること。
2.『再利用しやすいこと』
スタイルは、ボタンやフォームなど機能ごとに細かく分離した設計にしましょう。 再利用性のあるコードを書くことで再度同じUIを作成する場合、新しく追加する手間がなくなります。
3.『保守しやすいこと』
要素を追加・更新したことによって、既存のスタイルをリファクタリングするようなことが起こらない設計にしましょう。
4.『拡張しやすいこと』
サイトの規模が大きくなっても、複数の開発者がメンテナンス・管理しやすい設計にしましょう。
これらをまとめると、『メンテナブルな設計』が、よいCSS設計のゴールであると考えられます。 CSSは書くのがかんたんな分、破綻しやすいので運用・管理をしっかりと考えた設計にすることが大切ですね。
ちなみにCSS Architectureはどんな環境で設計するにおいても(他言語においても)参考になるお話なので、読んでおくと幸せになれるかもしれません！
参考 :
CSS Architecture
Hiroki Taniさんの日本語訳 CSS Architecture
私たちが実践している『CSS設計の開発手法』
私たちの開発環境では、CSSの設計ガイドラインとしてFLOCSS(フロックス)、コーディング規約にGoogle HTML/CSS Style Guideを採用しています。 ただ、これらに完全に準拠しているわけではなく、それぞれの考え方をベースとして自社の環境に合うものを取捨選択しています。
FLOCSSを用いたCSS設計
ママリではつい先日、CSS設計のガイドラインとしてFLOCSS(フロックス)を採用しました。 現在は要素の追加・変更時などに、FLOCSSに沿った設計となるようリファクタリングを行っています。
FLOCSSとは？
BEMの命名、MCSSやSMACSSのレイヤー設計などの考え方を組み合わせた『CSS設計ガイドライン』です。メロン本で有名ですね！ CSS ArchitectureがCSS設計の目指すべきゴールで、FLOCSSは破綻しやすいCSSをコンポーネント(部品)として扱うことによって、再利用性や保守性を高めるCSSの設計ガイドラインです。
参考 :
FLOCSS
CSS設計の教科書 (メロン本)
FLOCSSを使うメリット
個人的に使ってみて感じたものですが以下のメリットがあるかなと思います！
- 学習コストが低いこと。とりあえずメロン本を読めば大丈夫！
- 日本製なのでほかのガイドラインと比べて取り組みやすかった。
- OOCSSをベースに作られているので、エンジニアにとっても構造の理解がしやすい
- Objectは先頭に
.c-*や.p-*などのプレフィックスをつけるので直感的に構造の把握ができる。
コーディング規約
Google HTML/CSS Style Guideとは？
Googleが提案するHTML/CSSの『コーディング規約』です。命名規則、インデントやスペースの開け方などが細かく定められています。
参考 :
Google HTML/CSS Style Guide
「Google HTML/CSS Style Guide」を適当に和訳してみた |
コーディング規約は、Google HTML/CSS Style Guideを採用しています。
コードの書き方も『よりよいCSS設計』を目指すことにおいて考えるべき要素のひとつと考えています。特に複数の開発者がコードを管理する場合、『コードの読みやすさ』を考えることはとても大切です。
インデントやプロパティの記述などが揃っているだけでも全体のコードを読んで理解するまでの早さって結構変わるんですよね。
現状単独での開発行っているとしても将来的にメンバーが増えることが見込まれるのであれば、何かしらの規約を設けて『オレオレコード』とならないように整形するのがベターかとおもいます！
社内コーディング規約
他にも社内でのコーディング規約として以下を定めています。
たとえば、
- サイズの単位は基本的に
pxで書く。 - class名で使用する単語はなるべく省略しない。
- Role of threeにのっとって、各違う箇所で３回同じ要素を使用する場合は、再利用することを検討する。(リファクタリング)
- jsで使用するclassはスタイルを適用するclassとは別に付与する。
- jsで使用するclassはわかりやすく先頭に
.js-*プレフィックスをつける。
他にも、開発の中でこれは？というものがあれば都度相談しあって、ルールを更新しています。
『よりよいCSS設計』を生み出す
さて、いかがでしたでしょうか。 今回ご紹介した内容が、みなさんの『よりよいCSS設計』を考える上で、お役にたてると幸いです。
私たちも模索をしながら日々『よりよいCSS設計』について改善を行っています。 現段階で、これだ！な答えはまだありませんが、実装する中で意識していることがあります。
『もし明日から10人、100人のエンジニアを採用して共にママリの開発をすることになったとき、ひとりひとりが容易にコードを理解できる設計であること。いかなるときも、成長のスピードを止めないために、バトンを渡しやすい環境を維持し続けること。』です。
例えば、明日から新しいエンジニアがジョインしてくれるかもしれない → ここの要素ちょっとわかりずらい気がするからコメントをしっかりめに書いておこう。みたいに この先、どうなっていくかを想像してコードを書くことができるようになると思います。
ゴールとしては『メンテナブルな設計』を目指すことに変わりはないですが、なぜそれが必要なのかを意識的に想像することで、もっと普段から『よりよく』書けるようになれると思います。
その小さな積み重ねや、コードは一時的な実装のために書くのではなく、サービスの成長のために書く、といった想いを持つことは自然と『よりよいCSS設計』を生み出すことにつながるのではないでしょうか。
今後も引き続き『よりよいCSS設計』について考えていきたいと思います！
また、みなさんもあらためて考えてみませんか？
おわりに
Connehito.incではいけてるエンジニアとデザイナーを募集してます！
爆速で拡大成長中のサービスのCSS設計をいっしょに構築しませんか？？
ぜひラフにランチでも〜！よろしくお願いします！
