Gumi study#15 Sass構造化

ソシャゲでCSS Sassを構造化

gumi study #15

自己紹介原口 剛 (はらぐち ごう)

株式会社gumi所属

UIエンジニア

Ghrgc

ドラゴンジェネシス

2013年4月26日リリース!!「剣と魔法」に彩られた大作王道ファンタジーRPG

URL: http://pf.gree.jp/3393

今回のモチベーション大所帯(最大70人ぐらい)での開発

すごく貴重な経験させてもらった

安心・安全なフロントエンド開発手法を共有

Sassの設計で扱う内容1.構造化する理由

2.構造化へのアプローチ

3.スタイル適応範囲の限定

4.SCSSファイルの結合

5.問題点

6.まとめ

Sass.とは拡張子は｢.sass｣と｢.scss｣ の二種類

｢.scss｣ はcssと文法が似ている（SCSS記法）

コンパイルを通してCSSへ出力

本件の環境は、Sass 3.2.9

本家(http://sass-lang.com/)

Sassの設計で扱う内容1.構造化する理由

2.構造化へのアプローチ

3.スタイル適応範囲の限定

4.SCSSファイルの結合

5.問題点

6.まとめ

ドラジェネ開発案件全220ページほど･･･

全ページにおいて一点物のカンプ

単純にコピペで済む話ではない

四ヶ月ぐらいかかると思ったorz

チームでフロントエンドコミットの数が激増

スタイル定義の大量生産

使いどころがちょっとわからないスタイル

どこから混入したかわからないスタイル

なんか大変そう･････

これまでの実装実績、、、

いちフロントエンジニアの裁量で実装

ファイルの分割方針も曖昧

既存のスタイルがどこで使われているのか不明

他人のコードは･･･多分こんな感じに見える･･･

そんなコードに関わりたくない

もうメンテ無理･････

となる前に、、

構造化しましょう!

Sassの設計で扱う内容1.構造化する理由

2.構造化へのアプローチ

3.スタイル適応範囲の限定

4.SCSSファイルの結合

5.問題点

6.まとめ

構造化とは全体を把握した上でその構成要素について明らかになっている

構成要素間の関係が分かりやすく整理されている

やってみた

用途別にSCSSファイルをわける

ActionScript 3.0 パッケージ構造を参考

ディレクトリ名 役割controls 単体で形成される部品scenes ページ固有share scenes内ファイル間で共有stage 描画領域どこでもanimations アニメーションconstants 変数utills 汎用化されたスタイル

わけました

ページ単位でもっと細分化

ページ単位でもっと細分化

HTMLの階層構造に沿う

やっちゃえ

HTMLはサブディレクトリで階層化されている

サブディレクトリの数だけSCSSファイルをscenes/に用意する

SCSSファイルの名前はHTMLサブディレクトリ名と同じ

プロジェクト環境に合わせる

card/scenes/

root/

gacha/

HTML Sass

同名

同名

同名

card.scss

root.scss

gacha.scss

Sassの設計で扱う内容1.構造化する理由

2.構造化へのアプローチ

3.スタイル適応範囲の限定

4.SCSSファイルの結合

5.問題点

6.まとめ

scenes/のSCSSファイルどのHTMLのスタイルか明確にしておく仕組み

定義したスタイルのスコープを限定する

SCSSファイル固有のidを親要素にしたネスト構造の中にスタイルを記述

ネストセレクタの親子関係を入れ子で表現できる

親セレクタの指定が一度で済む

SCSS記法のネスト

こうなる

ネスト内のスタイルはネスト外への干渉をしない

限定的なスタイル定義

scenes/_root.scss

限定的なスタイル定義

scenes/_root.scss

出力されるCSSは親セレクタに必ず#rootが含まれる

idの命名規則HTML側はルート要素にサブディレクトリ名のidを付与しておく

scenes/*.scssは必ず親要素をidでネストする

HTMLルート要素のid属性手書きは正直めんどくさい

命名規則を守ってもらえるか不安

サーバーサイドでページのルート要素にid属性を付与する

自動付与

サーバーサイドでページのルート要素にid属性を付与する

自動付与

Sassの設計で扱う内容1.構造化する理由

2.構造化へのアプローチ

3.スタイル適応範囲の限定

4.SCSSファイルの結合

5.問題点

6.まとめ

CSSを結合分けただけでは部分的なCSSがたくさんコンパイル出力されるだけです

scssscssscss csscsscss

コンパイル

SCSSを結合しましょう!

SCSSを結合しましょう!@import

@importCSSの@importはCSSから別のCSSをロード

Sass独自の@import

構造化したSCSSファイルを共有

別ファイルの@mixinや@extend、変数が使用可能になる

@importの実践結合するので結合前のSCSSからのCSSは不要

結合結果のCSSだけあればよい

CSS出力しないSCSSファイル（パーシャル）

パーシャルはファイル名が_（アンダースコア）からはじまる

target.scss

_target_1.scss

_target_2.scss

target.css

target_1.css

target_2.css

compile

CSS出力されない

結合専用のSCSSファイル構造化した結果、200個以上のSCSSファイル

@importを管理簡素化と一元化

各サブディレクトリ内のSCSSファイルをすべて結合する__init__.scssを用意する

__init__.scss

scenes/

_sub_1.scss

_sub_10.scss

～@import

production.scss@import

production.scss

結果•テンプレートサブディレクトリscene/*.scssルート要素のid属性は必ず関連していることになる

•構成要素の関係が明らかになった•scene/*.scssに書かれたスタイル

チームでフロントエンドテンプレートディレクトリ単位でのスタイルを担当

担当分のscenes/*.scssをコミット

scenes/での実装のブレは、影響範囲が狭いので寛容

チームでフロントエンドテンプレートディレクトリ単位でのスタイルを担当

担当分のscenes/*.scssをコミット

scenes/での実装のブレは、影響範囲が狭いので寛容

→コンフリクトが少い

チームでフロントエンドテンプレートディレクトリ単位でのスタイルを担当

担当分のscenes/*.scssをコミット

scenes/での実装のブレは、影響範囲が狭いので寛容

→コンフリクトが少い

→スタイルをぶち込め!!!

Sassの設計で扱う内容1.構造化する理由

2.構造化へのアプローチ

3.スタイル適応範囲の限定

4.SCSSファイルの結合

5.問題点

6.まとめ

コンパイルが遅い@extendの使用箇所の増加

CSS Spriteの自動生成の増加

どちらも必要な機能

@extendは、セレクタをグルーピングしてスタイル定義を共有する仕組みでは強力な機能ではあるが使用箇所が増えるとコンパイルに時間がかかる

css spriteを自動生成すれば、UI素材を1つにまとめられることによって画面が描画されるまでの時間の短縮に繋がる

スプライト自動生成キャッシュなしの初期コンパイルに7分以上

遅!!!!

developmentモード$ compass compile -e development

コンパイルターゲットを切り替えて CSS Spriteを自動生成をしない

ミニファイしない

config.rb

productionモード$ compass compile -e production

コンパイルターゲットを切り替えて CSS Spriteを自動生成をする

ミニファイルする

config.rb

Sassの設計で扱う内容1.構造化する理由

2.構造化へのアプローチ

3.スタイル適応範囲の限定

4.SCSSファイルの結合

5.問題点

6.まとめ

大規模開発できた!Sassの構造を保ちつつ

フロント側10人で並行して大量の画面を作成可能

4ヶ月→1ヶ月半でフロント実装を完成させた構造化しているので複雑な問題であっても規則性のある管理が出来ている

大規模開発できた!Sassの構造を保ちつつ

フロント側10人で並行して大量の画面を作成可能

4ヶ月→1ヶ月半でフロント実装を完成させた構造化しているので複雑な問題であっても規則性のある管理が出来ている

継続的なリファクタが可能

ご清聴ありがとうございました