ソーシャルゲーム開発における運用とそのツール
DESCRIPTION
Frontrend-Nagoya 発表資料TRANSCRIPT
ソーシャルゲーム開発における運用とそのツール
2014/06/21 Frontrend in Nagoya
@ysugimoto
Introduction
•Yoshiaki Sugimoto
•Frontend Developer•HTML / CSS•JavaScript / Node.js•PHP•Linux
https://github.com/ysugimoto
Loving♡
Career
名古屋でWebシステム開発に従事
• フロントエンド特化したい
• 株式会社サイバーエージェント
• 東京こわい
Working...
JavaScript SDK
Perfomance
Any ServiceMaintainability
Pure JavaScript
Agenda
•ソーシャルゲームとチーム開発
•技術的負債とどう付き合っていくか
•運用フェーズの取り組み
•まとめ
ソーシャルゲームとチーム開発
TODO : 天クロの画像貰えたらもらう
天下統一クロニクル
•ご当地名物を題材にしたソーシャルゲーム
•2012/09 サービス開始
•会員数約250万人+ (2014/06/18現在）
•約30人くらいのチーム
(プランナー・エンジニア・デザイナ含）
うち、ディベロッパー6人
•週に一度くらいのリリースサイクル
天下統一クロニクル
レイドバトル
ギルドバトル
マラソン
ゲームループとイベント
メインループ +
プレイヤーグループ（ギルド）同士のバトル
ギルドバトル
プレイヤー同士が共闘するイベント
レイドバトル
プレイヤー個人で目標を達成し、順位を競う
マラソン
アプリケーションの特徴
•(Semi)SPAの形式
•非同期リクエスト+DOM書き換え多数
•JSよりもCSSが複雑
•アニメーション多数
Frontend-technology
•Pure JavaScript Core Framework
•Sass(SCSS)
•JsRender (Template Engine)
•Grunt
•CreateJS (Toolkit for CreateJS)
2012/09
2014/06
2012/09
2014/06
Technology
Architecture
Tool
フロントエンドの2年は
変化というよりも変革
新しいツールの登場
→ 便利そう！
新しいアーキテクチャの登場
→シンプルに書けそう！
新しい技術の登場
→ 夢がある！
理想と現実
新しいツールの登場
学習コストに見合うかな・・・
新しいアーキテクチャの登場
コアからのリプレイスは無理・・・
新しい技術の登場
端末サポートが・・・
数年先を見越した取捨選択、
現時点でのベストエフォート
技術的な負債と
どう付き合っていくか
コードと技術の賞味期限
導入ライブラリの 新版が取り込めない
APIが大幅に変わって追従できない
重要なSecurity FIXが取り込めない
古い端末のサポートのためのPolyfill
影響範囲が大きすぎて改修しづらい
APIのレガシー化
フロントエンドにおける
ライフサイクルは短い
増えるコードとステップ数
そしてファイルサイズ
このメソッドって使ってる所ある？
ここの処理って通過する？
if文ネストしすぎじゃ？
コードカバレッジの低下
レスポンスタイムへの影響
実行速度への影響
メンテナンス性への影響
画像・CSS
パフォーマンス担保領域の拡大
フロントエンドエンジニアは
やることが多い
ここの文言修正
してほしいんだけど
この要素間は
もう少しマージンが
欲しいです
APIレスポンス、
フォーマット
変わったんで
Android2.3で
この機能
動いてないので
調査して
コードの属人化
特定の人が永続的に
メンテする可能性
途中から別の人が
コードに触れる可能性
特定処理・コードの属人化
このライブラリ
便利だし入れよう
ライブラリの属人化
その人しか
使えなくない？
"この人しか分からない"
は危険信号
Case:アニメーション
タイムラインアニメーションを
スクリプティングするのは難しい
（素のCreateJS)
作った人以外は
動作がイメージしづらい
Toolkit for CreateJSの採用
Case:アニメーション
Flash IDE上で
アニメーションが作成可能
Flashがわかる人なら修正が可能
プレビューしながら修正が可能
Case:アニメーション
ヒューマンリソースの限界
切迫した状態でのコードは負債を大きくしやすい
→場当たり的なコードの生産
→コアFWから乖離したコード
精神衛生上良くない
残業して解決するのは本質ではない
技術的負債解消への
取り組み
古いコードの見極め
ツールで共通化・自動化
運用・改善フェーズ
ミクロな視点とマクロな視点
マクロな視点
「この画像減色されていませんね」
「CSSは共通化できるんじゃないですか」
「ここはスプライト化してください」
「ページのパフォーマンスが落ちています」
アプリケーション動作の
側面からの観測
•トータルパフォーマンスは？
•ユーザの体感速度は？
•画像サイズは？
•CSSサイズは？
•重複・冗長処理の削減・共通化
•新旧端末で発覚する不具合
•レガシーコードのリライト
•属人化の低減
ミクロな視点
コードベースの観測
•今よりもっと良い方法はないか?
•効率が上げられるポイントは?
•ツールで補えないか？
•このコード書いたの誰？
•API・ドキュメントの整備
•全体/細部のリファクタリング
•端末問題の検証と対策
•大きな変更は加えず、影響を 小限に
•テストを繰り返す
Defensive
安定稼働は最優先事項
新機能開発フェーズ
•現時点での流行・便利そうな技術への取り組み
•既存FWと著しく乖離しないポイントの見極め
•数年先も生きる/基礎となるようなものの選択
•温故知新
Offensive
新しい実装によるメンテナンス性は？
新しく書かれたコードはどこ？
既存コードへのリプレイスは？
20% offence
80% defence
運用での取り組みとツール
Webサーバ・DBの設定
サーバーサイドとの連携
フロントエンドが手を掛けるべき
ポイントではない
社内では「AeroMock」という
Javaプロジェクト向けツールを
導入しています
•軽量な起動
•APIレスポンスモック
•Tomcatの起動・再起動が不要
共通知としての
ライブラリ・ツール
このライブラリ
便利だし入れよう
ライブラリの属人化
その人しか
使えなくない？
とはいうものの
オンライン上に存在するドキュメント
特定APIの設計・実装の時短
技術・知識レベルの平坦化
ライブラリ導入による恩恵は大きい
みんなが使えるものを使う
必ず吟味する
必要であれば勉強会を開く
仕様ドキュメントを起こす
ドキュメンテーションはあって当たり前
実装引き継ぎの際のロスを低減させる
スタイルガイドを作ってデザイナーと共有
ソースコードレビュー
の文化
Enterprise
属人化するコードの低減
コードベースで議論する
なるべく偏らないレビュー指名
気軽に機能追加・改善を試せる土壌
SVNからGHEに移行して、
他のメンバーのコードを読むことが
増えました（32歳 男性）
テストを書く実行する
リファクタリングの副次効果
→メソッドの分割
→引数・戻り値の型の意識
→メンテナンス性の向上
精神衛生上良い
DOM周りのテストはやりづらい
DOMに癒着しすぎているメソッド
ロジック分離の意識
モデル・コンポーネント化
自動化する
特にマンパワーが必要な（面倒な）部分
•CSSスプライト生成
•画像減色 / チャンク削除
•PixelRatioイメージ自動生成
•JS結合とminify
•Sassコンパイル
•自動テスト
•etc...
統計情報に基づく改善
コードに関する統計情報を出し、
改善の指針にする
platoの出力例
まとめ
チーム開発のいいところ
スタープレイヤー
フルスタックエンジニア(?)
技術的な相談ができる
多様なチームメンバー
ゲームディベロップ
に必要なスキル
ProjectA
ProjectB
ProjectC
適応力
流行りに流されない
普遍的な技術
キャラ付け
1行の重み
1行の喜び
自分のコードで
数百万人が楽しんでくれる
自分のコードで
数百万人が遊べなくなる
コードに対する
責任感
終的に遊ぶユーザの気持ちで考える
・UI
・パフォーマンス
自ずと改善すべきポイントは見えてくる
パフォーマンスに
対する責任感
目に見える・
感じる部分が
フロントエンドの
担保領域
攻める部分と守る部分を明確に
メンバーの入れ替わりは結構頻繁にある
明日いなくなっても大丈夫なように
コミュニケーション力大事
一人よがりのコードを書かない
積極的にノウハウを共有していく
Thank you!!
https://flic.kr/p/d9K1Bc
https://flic.kr/p/bZw1ym
https://flic.kr/p/fYtrdY
https://flic.kr/p/njeKMd
https://flic.kr/p/5TEDDA
Any questions?