Gumi study#15 Sass構造化

2,248 views

Published on

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

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,248
On SlideShare
0
From Embeds
0
Number of Embeds
642
Actions
Shares
0
Downloads
5
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

Gumi study#15 Sass構造化

  1. 1. ソシャゲでCSS Sassを構造化 gumi study #15
  2. 2. 自己紹介 原口 剛 (はらぐち ごう) 株式会社gumi所属 UIエンジニア Ghrgc
  3. 3. ドラゴンジェネシス 2013年4月26日リリース!! 「剣と魔法」に彩られた 大作王道ファンタジーRPG URL: http://pf.gree.jp/3393
  4. 4. 今回のモチベーション 大所帯(最大70人ぐらい)での開発 すごく貴重な経験させてもらった 安心・安全な フロントエンド開発手法を共有
  5. 5. Sassの設計で扱う内容 1.構造化する理由 2.構造化へのアプローチ 3.スタイル適応範囲の限定 4.SCSSファイルの結合 5.問題点 6.まとめ
  6. 6. Sass.とは 拡張子は「.sass」と「.scss」 の二種類 「.scss」 はcssと文法が似ている(SCSS記法) コンパイルを通してCSSへ出力 本件の環境は、Sass 3.2.9 本家(http://sass-lang.com/)
  7. 7. Sassの設計で扱う内容 1.構造化する理由 2.構造化へのアプローチ 3.スタイル適応範囲の限定 4.SCSSファイルの結合 5.問題点 6.まとめ
  8. 8. ドラジェネ開発案件 全220ページほど・・・ 全ページにおいて一点物のカンプ 単純にコピペで済む話ではない 四ヶ月ぐらいかかると思ったorz
  9. 9. チームでフロントエンド コミットの数が激増 スタイル定義の大量生産 使いどころがちょっとわからないスタイル どこから混入したかわからないスタイル
  10. 10. なんか大変そう・・・・・
  11. 11. これまでの実装実績、、、
  12. 12. いちフロントエンジニアの 裁量で実装
  13. 13. ファイルの分割方針も曖昧
  14. 14. 既存のスタイルが どこで使われているのか不明
  15. 15. 他人のコードは・・・ 多分こんな感じに見える・・・
  16. 16. そんなコードに 関わりたくない
  17. 17. もうメンテ無理・・・・・
  18. 18. となる前に、、
  19. 19. 構造化しましょう!
  20. 20. Sassの設計で扱う内容 1.構造化する理由 2.構造化へのアプローチ 3.スタイル適応範囲の限定 4.SCSSファイルの結合 5.問題点 6.まとめ
  21. 21. 構造化とは 全体を把握した上でその構成要素について明らかに なっている 構成要素間の関係が分かりやすく整理されている
  22. 22. やってみた
  23. 23. 用途別に SCSSファイルをわける
  24. 24. ActionScript 3.0 パッケージ構造を参考
  25. 25. ディレクトリ名 役割 controls 単体で形成される部品 scenes ページ固有 share scenes内ファイル間で共有 stage 描画領域どこでも animations アニメーション constants 変数 utills 汎用化されたスタイル わけました
  26. 26. ページ単位でもっと細分化
  27. 27. ページ単位でもっと細分化 HTMLの階層構造に沿う
  28. 28. やっちゃえ
  29. 29. HTMLはサブディレクトリで階層化されている サブディレクトリの数だけSCSSファイルをscenes/に 用意する SCSSファイルの名前はHTMLサブディレクトリ名と 同じ プロジェクト環境に合わせる
  30. 30. card/ scenes/ root/ gacha/ HTML Sass 同名 同名 同名 card.scss root.scss gacha.scss
  31. 31. Sassの設計で扱う内容 1.構造化する理由 2.構造化へのアプローチ 3.スタイル適応範囲の限定 4.SCSSファイルの結合 5.問題点 6.まとめ
  32. 32. scenes/のSCSSファイル どのHTMLのスタイルか明確にしておく仕組み 定義したスタイルのスコープを限定する SCSSファイル固有のidを親要素にしたネスト構造の 中にスタイルを記述
  33. 33. ネスト セレクタの親子関係を入れ子で表現できる 親セレクタの指定が一度で済む
  34. 34. SCSS記法のネスト
  35. 35. こうなる
  36. 36. ネスト内のスタイルは ネスト外への干渉をしない
  37. 37. 限定的なスタイル定義 scenes/_root.scss
  38. 38. 限定的なスタイル定義 scenes/_root.scss 出力されるCSSは親セレクタに必ず#rootが含まれる
  39. 39. idの命名規則 HTML側はルート要素に サブディレクトリ名のidを付与しておく scenes/*.scssは必ず親要素をidでネスト する
  40. 40. HTMLルート要素のid属性 手書きは正直めんどくさい 命名規則を守ってもらえるか不安
  41. 41. サーバーサイドでページのルート要素にid属性を付与 する 自動付与
  42. 42. サーバーサイドでページのルート要素にid属性を付与 する 自動付与
  43. 43. Sassの設計で扱う内容 1.構造化する理由 2.構造化へのアプローチ 3.スタイル適応範囲の限定 4.SCSSファイルの結合 5.問題点 6.まとめ
  44. 44. CSSを結合 分けただけでは部分的なCSSがたくさん コンパイル出力されるだけです scssscssscss csscsscss コンパイル
  45. 45. SCSSを結合しましょう!
  46. 46. SCSSを結合しましょう! @import
  47. 47. @import CSSの@importはCSSから別のCSSをロード Sass独自の@import 構造化したSCSSファイルを共有 別ファイルの@mixinや@extend、変数が使用可能にな る
  48. 48. @importの実践 結合するので結合前のSCSSからのCSSは不要 結合結果のCSSだけあればよい CSS出力しないSCSSファイル(パーシャル) パーシャルはファイル名が_(アンダースコア) からはじまる
  49. 49. target.scss _target_1.scss _target_2.scss target.css target_1.css target_2.css compile CSS出力されない
  50. 50. 結合専用のSCSSファイル 構造化した結果、200個以上のSCSSファイル @importを管理簡素化と一元化 各サブディレクトリ内のSCSSファイルを すべて結合する__init__.scssを用意する
  51. 51. __init__.scss scenes/ _sub_1.scss _sub_10.scss ∼ @import production.scss@import
  52. 52. production.scss
  53. 53. 結果 •テンプレートサブディレクトリ scene/*.scss ルート要素のid属性は必ず関連してい ることになる •構成要素の関係が明らかになった •scene/*.scssに書かれたスタイル
  54. 54. チームでフロントエンド テンプレートディレクトリ単位でのスタイルを担当 担当分のscenes/*.scssをコミット scenes/での実装のブレは、影響範囲が狭いので寛容
  55. 55. チームでフロントエンド テンプレートディレクトリ単位でのスタイルを担当 担当分のscenes/*.scssをコミット scenes/での実装のブレは、影響範囲が狭いので寛容 →コンフリクトが少い
  56. 56. チームでフロントエンド テンプレートディレクトリ単位でのスタイルを担当 担当分のscenes/*.scssをコミット scenes/での実装のブレは、影響範囲が狭いので寛容 →コンフリクトが少い →スタイルをぶち込め!!!
  57. 57. Sassの設計で扱う内容 1.構造化する理由 2.構造化へのアプローチ 3.スタイル適応範囲の限定 4.SCSSファイルの結合 5.問題点 6.まとめ
  58. 58. コンパイルが遅い @extendの使用箇所の増加 CSS Spriteの自動生成の増加
  59. 59. どちらも必要な機能 @extendは、セレクタをグルーピングして スタイル定義を共有する仕組みでは強力な機能では あるが使用箇所が増えるとコンパイルに時間がかかる css spriteを自動生成すれば、UI素材を1つにまとめら れることによって画面が描画されるまでの時間の短 縮に繋がる
  60. 60. スプライト自動生成 キャッシュなしの初期コンパイルに7分以上
  61. 61. 遅!!!!
  62. 62. developmentモード $ compass compile -e development コンパイルターゲットを切り替えて CSS Spriteを自 動生成をしない ミニファイしない config.rb
  63. 63. productionモード $ compass compile -e production コンパイルターゲットを切り替えて CSS Spriteを自動生成をする ミニファイルする config.rb
  64. 64. Sassの設計で扱う内容 1.構造化する理由 2.構造化へのアプローチ 3.スタイル適応範囲の限定 4.SCSSファイルの結合 5.問題点 6.まとめ
  65. 65. 大規模開発できた! Sassの構造を保ちつつ フロント側10人で並行して大量の画面を作成可能 4ヶ月→1ヶ月半でフロント実装を完成させた 構造化しているので複雑な問題であっても 規則性のある管理が出来ている
  66. 66. 大規模開発できた! Sassの構造を保ちつつ フロント側10人で並行して大量の画面を作成可能 4ヶ月→1ヶ月半でフロント実装を完成させた 構造化しているので複雑な問題であっても 規則性のある管理が出来ている 継続的なリファクタが可能
  67. 67. ご清聴ありがとうございました

×