Gumi study#15 Sass構造化
Upcoming SlideShare
Loading in...5
×
 

Gumi study#15 Sass構造化

on

  • 1,572 views

2013年7月22日(月)

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

Statistics

Views

Total Views
1,572
Views on SlideShare
1,037
Embed Views
535

Actions

Likes
5
Downloads
2
Comments
0

5 Embeds 535

http://d.hatena.ne.jp 500
http://cloud.feedly.com 28
https://twitter.com 5
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
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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