• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Gumi study#15 Sass構造化
 

Gumi study#15 Sass構造化

on

  • 1,422 views

2013年7月22日(月)

2013年7月22日(月)
gumi study#15
Sass構造化の事例

Statistics

Views

Total Views
1,422
Views on SlideShare
902
Embed Views
520

Actions

Likes
5
Downloads
1
Comments
0

5 Embeds 520

http://d.hatena.ne.jp 486
http://cloud.feedly.com 28
https://twitter.com 4
http://rss.ameba.jp 1
http://feedly.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

Gumi study#15 Sass構造化 Gumi study#15 Sass構造化 Presentation Transcript

  • ソシャゲで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
  • @import CSSの@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ヶ月半でフロント実装を完成させた 構造化しているので複雑な問題であっても 規則性のある管理が出来ている 継続的なリファクタが可能
  • ご清聴ありがとうございました