ソーシャルゲーム開発における運用とそのツール
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

ソーシャルゲーム開発における運用とそのツール

on

  • 2,651 views

Frontrend-Nagoya 発表資料

Frontrend-Nagoya 発表資料

Statistics

Views

Total Views
2,651
Views on SlideShare
1,887
Embed Views
764

Actions

Likes
14
Downloads
15
Comments
0

8 Embeds 764

http://nantokaworks.com 361
http://frontrend.github.io 165
http://blog.wnotes.net 140
https://twitter.com 70
http://localhost 11
http://feedly.com 10
http://s.deeeki.com 5
http://www.slideee.com 2
More...

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

ソーシャルゲーム開発における運用とそのツール Presentation Transcript

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