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

1. ソシャゲでCSS
Sassを構造化
gumi study #15

2. 自己紹介
原口 剛 (はらぐち ごう)
株式会社gumi所属
UIエンジニア
Ghrgc

3. ドラゴンジェネシス
2013年4月26日リリース!!
「剣と魔法」に彩られた
大作王道ファンタジーRPG
URL: http://pf.gree.jp/3393

4. 今回のモチベーション
大所帯(最大70人ぐらい)での開発
すごく貴重な経験させてもらった
安心・安全な
フロントエンド開発手法を共有

5. Sassの設計で扱う内容
1.構造化する理由
2.構造化へのアプローチ
3.スタイル適応範囲の限定
4.SCSSファイルの結合
5.問題点
6.まとめ

6. Sass.とは
拡張子は｢.sass｣と｢.scss｣ の二種類
｢.scss｣ はcssと文法が似ている（SCSS記法）
コンパイルを通してCSSへ出力
本件の環境は、Sass 3.2.9
本家(http://sass-lang.com/)

7. Sassの設計で扱う内容
1.構造化する理由
2.構造化へのアプローチ
3.スタイル適応範囲の限定
4.SCSSファイルの結合
5.問題点
6.まとめ

8. ドラジェネ開発案件
全220ページほど･･･
全ページにおいて一点物のカンプ
単純にコピペで済む話ではない
四ヶ月ぐらいかかると思ったorz

9. チームでフロントエンド
コミットの数が激増
スタイル定義の大量生産
使いどころがちょっとわからないスタイル
どこから混入したかわからないスタイル

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

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

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

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

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

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

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

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

20. となる前に、、

21. 構造化しましょう!

22. Sassの設計で扱う内容
1.構造化する理由
2.構造化へのアプローチ
3.スタイル適応範囲の限定
4.SCSSファイルの結合
5.問題点
6.まとめ

23. 構造化とは
全体を把握した上でその構成要素について明らかに
なっている
構成要素間の関係が分かりやすく整理されている

24. やってみた

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

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

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

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

29. ページ単位でもっと細分化
HTMLの階層構造に沿う

30. やっちゃえ

31. HTMLはサブディレクトリで階層化されている
サブディレクトリの数だけSCSSファイルをscenes/に
用意する
SCSSファイルの名前はHTMLサブディレクトリ名と
同じ
プロジェクト環境に合わせる

32. card/
scenes/
root/
gacha/
HTML Sass
同名
同名
同名
card.scss
root.scss
gacha.scss

33. Sassの設計で扱う内容
1.構造化する理由
2.構造化へのアプローチ
3.スタイル適応範囲の限定
4.SCSSファイルの結合
5.問題点
6.まとめ

34. scenes/のSCSSファイル
どのHTMLのスタイルか明確にしておく仕組み
定義したスタイルのスコープを限定する
SCSSファイル固有のidを親要素にしたネスト構造の
中にスタイルを記述

35. ネスト
セレクタの親子関係を入れ子で表現できる
親セレクタの指定が一度で済む

36. SCSS記法のネスト

37. こうなる

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

39. 限定的なスタイル定義
scenes/_root.scss

40. 限定的なスタイル定義
scenes/_root.scss
出力されるCSSは親セレクタに必ず#rootが含まれる

41. idの命名規則
HTML側はルート要素に
サブディレクトリ名のidを付与しておく
scenes/*.scssは必ず親要素をidでネスト
する

42. HTMLルート要素のid属性
手書きは正直めんどくさい
命名規則を守ってもらえるか不安

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

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

45. Sassの設計で扱う内容
1.構造化する理由
2.構造化へのアプローチ
3.スタイル適応範囲の限定
4.SCSSファイルの結合
5.問題点
6.まとめ

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

47. SCSSを結合しましょう!

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

49. @import
CSSの@importはCSSから別のCSSをロード
Sass独自の@import
構造化したSCSSファイルを共有
別ファイルの@mixinや@extend、変数が使用可能にな
る

50. @importの実践
結合するので結合前のSCSSからのCSSは不要
結合結果のCSSだけあればよい
CSS出力しないSCSSファイル（パーシャル）
パーシャルはファイル名が_（アンダースコア）
からはじまる

51. target.scss
_target_1.scss
_target_2.scss
target.css
target_1.css
target_2.css
compile
CSS出力されない

52. 結合専用のSCSSファイル
構造化した結果、200個以上のSCSSファイル
@importを管理簡素化と一元化
各サブディレクトリ内のSCSSファイルを
すべて結合する__init__.scssを用意する

53. __init__.scss
scenes/
_sub_1.scss
_sub_10.scss
∼
@import
production.scss@import

54. production.scss

55. 結果
•テンプレートサブディレクトリ
scene/*.scss
ルート要素のid属性は必ず関連してい
ることになる
•構成要素の関係が明らかになった
•scene/*.scssに書かれたスタイル

56. チームでフロントエンド
テンプレートディレクトリ単位でのスタイルを担当
担当分のscenes/*.scssをコミット
scenes/での実装のブレは、影響範囲が狭いので寛容

57. チームでフロントエンド
テンプレートディレクトリ単位でのスタイルを担当
担当分のscenes/*.scssをコミット
scenes/での実装のブレは、影響範囲が狭いので寛容
→コンフリクトが少い

58. チームでフロントエンド
テンプレートディレクトリ単位でのスタイルを担当
担当分のscenes/*.scssをコミット
scenes/での実装のブレは、影響範囲が狭いので寛容
→コンフリクトが少い
→スタイルをぶち込め!!!

59. Sassの設計で扱う内容
1.構造化する理由
2.構造化へのアプローチ
3.スタイル適応範囲の限定
4.SCSSファイルの結合
5.問題点
6.まとめ

60. コンパイルが遅い
@extendの使用箇所の増加
CSS Spriteの自動生成の増加

61. どちらも必要な機能
@extendは、セレクタをグルーピングして
スタイル定義を共有する仕組みでは強力な機能では
あるが使用箇所が増えるとコンパイルに時間がかかる
css spriteを自動生成すれば、UI素材を1つにまとめら
れることによって画面が描画されるまでの時間の短
縮に繋がる

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

63. 遅!!!!

64. developmentモード
$ compass compile -e development
コンパイルターゲットを切り替えて CSS Spriteを自
動生成をしない
ミニファイしない
config.rb

65. productionモード
$ compass compile -e production
コンパイルターゲットを切り替えて
CSS Spriteを自動生成をする
ミニファイルする
config.rb

66. Sassの設計で扱う内容
1.構造化する理由
2.構造化へのアプローチ
3.スタイル適応範囲の限定
4.SCSSファイルの結合
5.問題点
6.まとめ

67. 大規模開発できた!
Sassの構造を保ちつつ
フロント側10人で並行して大量の画面を作成可能
4ヶ月→1ヶ月半でフロント実装を完成させた
構造化しているので複雑な問題であっても
規則性のある管理が出来ている

68. 大規模開発できた!
Sassの構造を保ちつつ
フロント側10人で並行して大量の画面を作成可能
4ヶ月→1ヶ月半でフロント実装を完成させた
構造化しているので複雑な問題であっても
規則性のある管理が出来ている
継続的なリファクタが可能

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