DMMで新規サービス作ったら
フロントエンドエンジニアの重要性が
浮き彫りになった話
石橋啓太
2015.11.26DMM.Study Night
自己紹介
DMM.com Labo
2014 / 05 ∼
UIデザイナー / フロントエンドエンジニア
石橋 啓太
過去のDMMのサービス構築とは
過去のDMMのサービス構築とは
旧来のWebサービス
¦¦
サービス全体に対して高度なJavaScriptが必要無い
過去のDMMのサービス構築とは
旧来のWebサービス
¦¦
サービス全体に対して高度なJavaScriptが必要無い
フロントエンドエンジニア
という職種が存在しなかった
デザイナーがなんとかしないと…
問題だらけ!!
知識差による品質低下
リファクタリングしない・できない
放置されるバグ
JS実装どっちがやる問題
メンテナンス性の低下
「とりあえず実装」が
溢れかえっていた!!
そもそも 設計 をする文化が無い…
(((((((( ;゚Д゚))))))))ガクガクブルブルガタガタブルブル
新規サービス立ち上げ…。
1から構築するチャンス!
要件定義と体制づくり
要件定義
最終的なサービス規模は未知数
保守対応者のスキル感は不明
リリース日は厳守
前提条件
拡張のしやすさ
品質の保持
開発スピード
サービス規模
対応者のスキル感
リリース厳守
前提条件 必要要件
体制づくり
フロントエンドエンジニア
HTML/CSS/JavaScript
デザイナー
PSD作成/コンセプト/レギュレーション
バックエンドエンジニア
PHP
デザイナーとバックエンドの間に入る
リードデザイナー
デザイナー
リードエンジニア
エンジニア
リードエンジニア
エンジニア
デザインセクション フロントエンドセクション バックエンドセクション
ディレクター
PL・PM
要件を満たすものをつくるために
(拡張+品質+スピード)
コーディングルール
+
ドキュメンテーション
+
開発環境
全体ルール
HTMLルール
CSSルール
JavaScriptルール
画像ルール
全体ルール
HTMLルール
CSSルール
JavaScriptルール
画像ルール
小
小
大
中
小
重要度
全体ルール
HTMLルール
画像ルール
JavaScriptルール
CSSルール
小
小
小
中
大
重要度
大事な話は最後にします!!!
全体ルール
・触るファイルの明確化(source/destination)
・ワークフロー定義(GitFlow/GitHubFlow)
・書式定義(editorconfig)
・緊急対応時のフロー
・注意事項など
HTMLルール
・命名規則(ハイフン・アンダーバーなど)
・判断に困りそうなタグのみ使い方を定義
 <h1>∼<h6>、<section>、<nav>、<span>、など
・基準が曖昧なタグはあえて非推奨
 <aside>、<article>、...
画像ルール
・png / jpg / svg 使い分け基準
・命名規則(接頭辞・接尾辞)
・必ず圧縮すること
JavaScriptルール
・jQuery(UI上の表現にとどめる)
・書式はLinterで制御
・bowerでライブラリ管理
・モジュール単位で作成し、webpackで管理
JavaScriptルール
JavaScript部分の重要度が 中 な理由
・モジュール管理されていれば、リファクタリングはしやすい
・アサインされる人員は、一定のスキルが期待できる
ふぅ…ε-ヾ(´ε`;)ゝ
CSSルール
・Sassを採用
・設計はFLOCSSを採用
・覚えづらいルールは極力排除
・書式はLinterで制御
・命名規則はBEM
・スタイルガイドの作成
Sass
CSSルール / Sass
⃝ ×
知識をそれほど必要としないもののみ使用
変数
ネスト
親セレクタの継承
コメント
関数
mixin/extend
プレースホルダー
条件分岐
繰り返し
四則演算
設計:FLOCSS
https://github.com/hiloki/flocss
はじめに…
FLOCSSの特徴を少し説明します
CSSルール / 設計:FLOCSS
大きく3つのレイヤーに分かれている
・Foundation
・Layout
・Object
━
━
━
初期化などのベース
大枠・フレーム部分
コンテンツエリア
CSSルール / 設計:FLOCSS
さらに、Objectの下に3つの子レイヤー
・Object
 ・Component
 ・Project
 ・Utility
━
━
━
再利用できるパーツ
パーツの集合体
汎用クラス
CSSルール / 設計:FLOCSS
Foundation + Layoutで作った下地に
Objectを配置していくイメージ
Componentを作って、Utility・Projectを
うまく使って要素づくり
CSSルール / 設計:FLOCSS
Foundation
Layout
Component Utility
Project
Object
CSSルール / 設計
すべての作業者に、FLOCSSの概念をキチンと理解し
運用してもらうのは難しい
CSSルール / 設計
すべての作業者に、FLOCSSの概念をキチンと理解し
運用してもらうのは難しい
でも
Componentベースの設計思想は活用したい
CSSルール / 設計
作業者に対するルールをスケールダウン
・Foundation
・Layout
・Object
・Component
・Utility
・Project
設計者が触る範囲 作業者が触る範囲
CSSルール / 設計
作業者に対するルールをスケールダウン
・Component
・Utility
・Project
パーツはすべてココ
設計者が用意・作業者は使うだけ
パーツとは無関係な独立ページ用
CSSルール / 設計
作業者に対するルールをスケールダウン
・Component
・Utility
・Project
パーツはすべてココ
設計者が用意・作業者は使うだけ
パーツとは無関係な独立ページ用
CSSルール / 設計
作業者に対するルールをスケールダウン
Component + Utility で基本全てをまかなう
・Component
・Utility
・Project
パーツはすべてココ
設計者が用意・作業者は使うだけ
パーツとは...
CSSルール / 設計
作業者に対するルールをスケールダウン
Component + Utility で基本全てをまかなう
・Component
・Utility
・Project
パーツはすべてココ
設計者が用意・作業者は使うだけ
パーツとは...
CSSルール / 設計
CSS設計は、運用/保守の開発スピードの要
CSSルール / 設計
CSS設計は、運用/保守の開発スピードの要
正確なComponent化には、
デザイナーとの密なコミュニケーションが必須
CSSルール / 設計
CSS設計は、運用/保守の開発スピードの要
デザイナー フロントエンド バックエンド
正確なComponent化には、
デザイナーとの密なコミュニケーションが必須
スタイルガイド
CSSルール / スタイルガイド
.scssファイルから直接スタイルガイドを自動生成するように
Gulpを使って開発環境を構築
src/*.scss
dest/*.css styleguide/*.html
結合・圧縮などをした
CSSファイル...
実際のフロント開発環境
*.js
JS
(modules)
*.js
JS
(library)
*.html
スタイル
ガイド
*.scss
CSS
(source)
*.min.css
CSS
(dest)
*.min.js
JS
(entry point)
lib...
*.js
JS
(modules)
*.js
JS
(library
*.html
スタイル
ガイド
*.scss
CSS
(source)
*.min.css
CSS
(dest)
*.min.js
JS
(entry point)
lib....
設計者(フロントエンドエンジニア)が管理をするために
・CSS import
・Webpack EntryPoint
・webpack.config.js
・package.json
・bower.json
管理用ファイルをキチンと作っておく ←...
フロントエンドエンジニアの重要性とは!?
まとめ
とにかくクソコードが減る!!!
とにかくクソコードが減る!!!
・メンテしやすい
・パフォーマンス高い
・バグが出にくい
・気持ちいい
・楽しい
メリットだらけ
Thank You !!
2015.11.26
DMM.Study Night
Upcoming SlideShare
Loading in...5
×

DMMで新規サービス作ったらフロントエンドエンジニアの重要性が浮き彫りになった話 - DMM Study night

317
-1

Published on

DMM Study night (2015.11.26)

Published in: Technology

DMMで新規サービス作ったらフロントエンドエンジニアの重要性が浮き彫りになった話 - DMM Study night

  1. 1. DMMで新規サービス作ったら フロントエンドエンジニアの重要性が 浮き彫りになった話 石橋啓太 2015.11.26DMM.Study Night
  2. 2. 自己紹介 DMM.com Labo 2014 / 05 ∼ UIデザイナー / フロントエンドエンジニア 石橋 啓太
  3. 3. 過去のDMMのサービス構築とは
  4. 4. 過去のDMMのサービス構築とは 旧来のWebサービス ¦¦ サービス全体に対して高度なJavaScriptが必要無い
  5. 5. 過去のDMMのサービス構築とは 旧来のWebサービス ¦¦ サービス全体に対して高度なJavaScriptが必要無い フロントエンドエンジニア という職種が存在しなかった
  6. 6. デザイナーがなんとかしないと…
  7. 7. 問題だらけ!! 知識差による品質低下 リファクタリングしない・できない 放置されるバグ JS実装どっちがやる問題 メンテナンス性の低下
  8. 8. 「とりあえず実装」が 溢れかえっていた!! そもそも 設計 をする文化が無い…
  9. 9. (((((((( ;゚Д゚))))))))ガクガクブルブルガタガタブルブル
  10. 10. 新規サービス立ち上げ…。 1から構築するチャンス! 要件定義と体制づくり
  11. 11. 要件定義
  12. 12. 最終的なサービス規模は未知数 保守対応者のスキル感は不明 リリース日は厳守 前提条件
  13. 13. 拡張のしやすさ 品質の保持 開発スピード サービス規模 対応者のスキル感 リリース厳守 前提条件 必要要件
  14. 14. 体制づくり
  15. 15. フロントエンドエンジニア HTML/CSS/JavaScript デザイナー PSD作成/コンセプト/レギュレーション バックエンドエンジニア PHP デザイナーとバックエンドの間に入る
  16. 16. リードデザイナー デザイナー リードエンジニア エンジニア リードエンジニア エンジニア デザインセクション フロントエンドセクション バックエンドセクション ディレクター PL・PM
  17. 17. 要件を満たすものをつくるために (拡張+品質+スピード)
  18. 18. コーディングルール + ドキュメンテーション + 開発環境
  19. 19. 全体ルール HTMLルール CSSルール JavaScriptルール 画像ルール
  20. 20. 全体ルール HTMLルール CSSルール JavaScriptルール 画像ルール 小 小 大 中 小 重要度
  21. 21. 全体ルール HTMLルール 画像ルール JavaScriptルール CSSルール 小 小 小 中 大 重要度 大事な話は最後にします!!!
  22. 22. 全体ルール ・触るファイルの明確化(source/destination) ・ワークフロー定義(GitFlow/GitHubFlow) ・書式定義(editorconfig) ・緊急対応時のフロー ・注意事項など
  23. 23. HTMLルール ・命名規則(ハイフン・アンダーバーなど) ・判断に困りそうなタグのみ使い方を定義  <h1>∼<h6>、<section>、<nav>、<span>、など ・基準が曖昧なタグはあえて非推奨  <aside>、<article>、<i>、など ・基本はweb標準に準拠
  24. 24. 画像ルール ・png / jpg / svg 使い分け基準 ・命名規則(接頭辞・接尾辞) ・必ず圧縮すること
  25. 25. JavaScriptルール ・jQuery(UI上の表現にとどめる) ・書式はLinterで制御 ・bowerでライブラリ管理 ・モジュール単位で作成し、webpackで管理
  26. 26. JavaScriptルール JavaScript部分の重要度が 中 な理由 ・モジュール管理されていれば、リファクタリングはしやすい ・アサインされる人員は、一定のスキルが期待できる
  27. 27. ふぅ…ε-ヾ(´ε`;)ゝ
  28. 28. CSSルール ・Sassを採用 ・設計はFLOCSSを採用 ・覚えづらいルールは極力排除 ・書式はLinterで制御 ・命名規則はBEM ・スタイルガイドの作成
  29. 29. Sass
  30. 30. CSSルール / Sass ⃝ × 知識をそれほど必要としないもののみ使用 変数 ネスト 親セレクタの継承 コメント 関数 mixin/extend プレースホルダー 条件分岐 繰り返し 四則演算
  31. 31. 設計:FLOCSS https://github.com/hiloki/flocss
  32. 32. はじめに… FLOCSSの特徴を少し説明します
  33. 33. CSSルール / 設計:FLOCSS 大きく3つのレイヤーに分かれている ・Foundation ・Layout ・Object ━ ━ ━ 初期化などのベース 大枠・フレーム部分 コンテンツエリア
  34. 34. CSSルール / 設計:FLOCSS さらに、Objectの下に3つの子レイヤー ・Object  ・Component  ・Project  ・Utility ━ ━ ━ 再利用できるパーツ パーツの集合体 汎用クラス
  35. 35. CSSルール / 設計:FLOCSS Foundation + Layoutで作った下地に Objectを配置していくイメージ Componentを作って、Utility・Projectを うまく使って要素づくり
  36. 36. CSSルール / 設計:FLOCSS Foundation Layout Component Utility Project Object
  37. 37. CSSルール / 設計 すべての作業者に、FLOCSSの概念をキチンと理解し 運用してもらうのは難しい
  38. 38. CSSルール / 設計 すべての作業者に、FLOCSSの概念をキチンと理解し 運用してもらうのは難しい でも Componentベースの設計思想は活用したい
  39. 39. CSSルール / 設計 作業者に対するルールをスケールダウン ・Foundation ・Layout ・Object ・Component ・Utility ・Project 設計者が触る範囲 作業者が触る範囲
  40. 40. CSSルール / 設計 作業者に対するルールをスケールダウン ・Component ・Utility ・Project パーツはすべてココ 設計者が用意・作業者は使うだけ パーツとは無関係な独立ページ用
  41. 41. CSSルール / 設計 作業者に対するルールをスケールダウン ・Component ・Utility ・Project パーツはすべてココ 設計者が用意・作業者は使うだけ パーツとは無関係な独立ページ用
  42. 42. CSSルール / 設計 作業者に対するルールをスケールダウン Component + Utility で基本全てをまかなう ・Component ・Utility ・Project パーツはすべてココ 設計者が用意・作業者は使うだけ パーツとは無関係な独立ページ用
  43. 43. CSSルール / 設計 作業者に対するルールをスケールダウン Component + Utility で基本全てをまかなう ・Component ・Utility ・Project パーツはすべてココ 設計者が用意・作業者は使うだけ パーツとは無関係な独立ページ用 わかりやすい!
  44. 44. CSSルール / 設計 CSS設計は、運用/保守の開発スピードの要
  45. 45. CSSルール / 設計 CSS設計は、運用/保守の開発スピードの要 正確なComponent化には、 デザイナーとの密なコミュニケーションが必須
  46. 46. CSSルール / 設計 CSS設計は、運用/保守の開発スピードの要 デザイナー フロントエンド バックエンド 正確なComponent化には、 デザイナーとの密なコミュニケーションが必須
  47. 47. スタイルガイド
  48. 48. CSSルール / スタイルガイド .scssファイルから直接スタイルガイドを自動生成するように Gulpを使って開発環境を構築 src/*.scss dest/*.css styleguide/*.html 結合・圧縮などをした CSSファイル スタイルガイド (Component一覧)
  49. 49. 実際のフロント開発環境
  50. 50. *.js JS (modules) *.js JS (library) *.html スタイル ガイド *.scss CSS (source) *.min.css CSS (dest) *.min.js JS (entry point) lib.min.js JS (library minify) hologram sass webpack Gulp controller(php)Viewファイル *.volt(php)
  51. 51. *.js JS (modules) *.js JS (library *.html スタイル ガイド *.scss CSS (source) *.min.css CSS (dest) *.min.js JS (entry point) lib.min.js JS (library minify) hologram sass webpack Gulp controller(phpViewファイル *.volt(php) 作業者が触るファイル
  52. 52. 設計者(フロントエンドエンジニア)が管理をするために ・CSS import ・Webpack EntryPoint ・webpack.config.js ・package.json ・bower.json 管理用ファイルをキチンと作っておく ←結構大事だった
  53. 53. フロントエンドエンジニアの重要性とは!? まとめ
  54. 54. とにかくクソコードが減る!!!
  55. 55. とにかくクソコードが減る!!! ・メンテしやすい ・パフォーマンス高い ・バグが出にくい ・気持ちいい ・楽しい
  56. 56. メリットだらけ
  57. 57. Thank You !! 2015.11.26 DMM.Study Night
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×