CSS Nite LP47「Coder's High 2016」フォローアップ（6）小山田 晃浩さん（ピクセルグリッド）、坂巻 翔大郎さん（ピクセルグリッド）、赤塚妙子さん（esa）
2016年9月24日（土）TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP47「Coder's High 2016」のフォローアップとして、小山田 晃浩さん（ピクセルグリッド）、坂巻 翔大郎さん（ピクセルグリッド）、赤塚妙子さん（esa）の『esa.ioのBootstrap利用とCSSリファクタリング』セッションのスライドなどを公開します。
「esa.ioのBootstrap利用とCSSリファクタリング」で共有した内容、いかがでしたでしょうか？
Webサービスでの例ということで、少し特殊だったかもしれませんが、皆さんのお仕事に活かせるであろう内容も色々あったと考えています。
- 共通言語としてのBootstrapが解決したこと
- 必要以上なツールは不要
- CSSリファクタリングで解決した内容
- リファクタリングの進め方の参考例
特に、「CSSリファクタリングで解決した内容」でご紹介した
- 詳細度のを低く一定にする
- コンポーネントの粒度
は、普段CSSを書く際に注意するポイントであり、
リファクタリングのタイミングでなく、最初からCSSを書く場合においても大切で、
これらがいいCSSを書くためのポイントとも考えています。
ぜひ、ツールを活かし、いいCSSを書いてみてください。
私達のセッション内容が少しでも皆さんの日々のお仕事への参考になれば幸いです。
以下は、アンケートにあった質問への回答です。
見積もり方法について教えてください
CSSコンサルティングを行う際の見積もりですが、今回が初めての試みだったため、まず最初に打ち合わせをしました。その中で、ピクセルグリッドは「コードレビューや相談が主で、実装はしない」という取り決めを行いました。基本的には、週に半日分ぐらいの稼働目安で始めて見る事となりました。
Bootstrapとの競合はあったのか、またその解決方法は？
競合がないように、共存をすることを選ぶのがよいと考えています。
そのためにコードを見直し（リファクタリング）クラス名などBootstrapと同じにならないように
しっかり再検討することが解決方法です。
高津戸がお話したESCSSの考え方も、競合しないCSSを書くためには有効です。
リファクタリングが生む価値はなんでしょうか？
CSSは、書き方が決まっておらず、とても難しいといえます。
その為、書き方ばバラバラになったり、時には表示速度に影響することもあります。
リファクタリングをすることで、CSSはもちろん、HTML（テンプレート）の管理のしやすさ、
つまりメンテナンスのしやすさに影響すると考えています。
リファクタリングをすることは、メンテナンスのしやすさ、パフォーマンス（速度）などを改善することができ、Webサイト、アプリケーションの寿命を延ばすために価値があるといえます。
また、esaの場合の考え方ですが、UIや機能を自分たちで試行錯誤しながら作っていったWebアプリケーションということもあり、普段からCSSも何度も書き直しつつ開発を進めています。
最初からベストなUIデザインやCSSを書くことを目標とせず、より良い方法を発見するたびに日々少しずつ改善していけるのが良いと考えています。
身軽にいつでもCSSを書き直せる状態を保つには、土台となる部分がある程度整理されていることが必要になりますが、Webアプリケーションが大きくなってきて年月が経ってくると、長い紐同士が絡まり合ってほどきにくくなるように、CSSも複雑化してきてしまい《いじりにくい》状態になってきてしまいます。
今回esaが行った大きなCSSリファクタリングは、その CSSを《いじりにくい》状態を解消して、絡まりあった紐がほどけた状態にし、いつでもCSSやUIを身軽に改善しやすい状態を保つということを目標としました。
リファクタリングの際に注意したポイントは？
実際に多くのユーザーが既に使って下さっているWebアプリケーションなので、リファクタリングで崩れる箇所がないかどうかの動作確認は、サーバサイドのエンジニアにも協力してもらい慎重に行っています。
この確認作業が結構大変で負担がかかり、また開発中の部分とのコンフリクトも起きやすいので、開発を比較的活発に進めているような時期にCSSリファクタリングをするのは避けるようにしています。
カスタマイズのコツは？
コード面では、なるべく _variables.scss 内の変数を上書きしていくという方法で進めていくのがおすすめです。
私（赤塚）の場合ですが、https://github.com/twbs/bootstrap-sass/blob/master/assets/stylesheets/bootstrap/￥variables.scss の中身をまず全部コピーした _variables.scss というファイルをimportし、そのファイルの中身を最初全てコメントアウトして、カスタマイズする部分のみ行コメントを外して上書きして使っています。このやり方だと、_variables.scss の中身をテキスト検索すれば目標の変数を探すことができ、またBootstrap関連の上書きが1ファイルにまとまるので便利です。
また、Sassファイルのimport順ですが、少し注意が必要になります。
@import variables;@import bootstrap;上記のように、_variables.scss の方を、Bootstrap本体よりも先にimportします。そのようにすることで、こちらで上書きした変数を使用した状態でBootstrapのCSSがコンパイルされます。（逆の読み込み順にするとvariablesは使われない状態でBootstrapが実行されてしまいます）
変数を先に読むのになぜ上書きされるのか？と疑問に思われる方もいるかもしれませんが、Bootstrap本体のSassの変数には下記のように末尾に全て !defaultがついている点がポイントです。
$brand-success: #5cb85c !default;このように、末尾に!defaultがついた状態で定義された変数は、同じ変数を定義している箇所が他にあれば、読み込み順の前後に関わらず、!default がついたもの以外 を優先するようになります。なので、上に書いても変数の上書きができるのです。
デザイン面でのカスタマイズのコツですが、まずはBootstrapのデザインにとらわれないで、そのサイトやアプリケーションにとって最適なデザインをした上で、使えるところにはBootstrapを使うくらいの感じで行うと良いでしょう。
見た目が Bootstrapっぽくならないようにするにはいくつかポイントがあります。
例えば、Bootstrapには色んな色のボタンが用意されており、つい色んな色を無意味に使いたくなってしまうのですが、ボタンの色の使い方に基本的なルールをきちんと定めておくというのもコツの1つです。
私（赤塚）は、下記のような基本ルールでやっています。
.btn-primary: そのページでの通常、メインの動作系に使うボタン.btn-default: .btn-primary よりも相対的に弱いボタン.btn-warning: 少しイレギュラーな動作に使うボタン（新規作成系が多い）.btn-danger:削除等の危険な動作に使うボタン（赤くて目立つので設定画面等の奥まった場所でしか利用しない）
1つのページ内に.btn-primary は原則1個以内
単純なページ遷移はなるべくボタンではなくリンクにする
杓子定規に全てルールを守るのが必ずしもベストではなく、その時々でバランスを見てベストなデザインにしていくのが良いと思いますが、基本的なルールが決まっているとデザイナー自身も、協業するエンジニア等もその後の展開がしやすく楽になり、統一感のある使いやすいサービスに育ってくると思います。
Aigis（スタイルガイドジェネレーター）について気になります
プロジェクト専用にコンポーネント集（フレームワーク）を作ることがあります。
その際、ピクセルグリッドでは、Aigisというスタイルガイドジェネレーターを利用します。
スタイルガイドジェネレータとしては、KSS、hologram、styledoccoなどが有名ですが
それよりも使い勝手をよく、ピクセルグリッドの一部のメンバーにより開発されています。
日本語での説明書もありますので、気概があれば試してみてください。
https://pxgrid.github.io/aigis/docs/jp/
● オチの仰天サプライズはいつの時代も有効
