Frontrend-Nagoya 発表資料

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で
この機能
動いてないので
調査して

35. コードの属人化

36. 特定の人が永続的に
メンテする可能性
途中から別の人が
コードに触れる可能性
特定処理・
コードの属人化

37. このライブラリ
便利だし入れよう
ライブラリの属人化
その人しか
使えなくない？

38. "この人しか分からない"
は危険信号

39. Case:アニメーション
タイムラインアニメーションを
スクリプティングするのは難しい
（素のCreateJS)
作った人以外は
動作がイメージしづらい

40. Toolkit for CreateJSの採用
Case:アニメーション

41. Flash IDE上で
アニメーションが作成可能
Flashがわかる人なら修正が可能
プレビューしながら修正が可能
Case:アニメーション

42. ヒューマンリソース
の限界

43. 切迫した状態でのコードは負債を大きくしやすい
→場当たり的なコードの生産
→コアFWから乖離したコード
精神衛生上良くない
残業して解決するのは本質ではない

44. 技術的負債解消への
取り組み

45. 古いコードの見極め
ツールで共通化・自動化

46. 運用・改善フェーズ

47. ミクロな視点と
マクロな視点

48. マクロな視点
「この画像減色されていませんね」
「CSSは共通化できるんじゃないですか」
「ここはスプライト化してください」
「ページのパフォーマンスが落ちています」

49. アプリケーション動作の
側面からの観測

50. •トータルパフォーマンスは？
•ユーザの体感速度は？
•画像サイズは？
•CSSサイズは？

51. •重複・冗長処理の削減・共通化
•新旧端末で発覚する不具合
•レガシーコードのリライト
•属人化の低減
ミクロな視点

52. コードベースの観測

53. •今よりもっと良い方法はないか?
•効率が上げられるポイントは?
•ツールで補えないか？
•このコード書いたの誰？

54. •API・ドキュメントの整備
•全体/細部のリファクタリング
•端末問題の検証と対策
•大きな変更は加えず、影響を最小限に
•テストを繰り返す
Defensive

55. 安定稼働は最優先事項

56. 新機能開発フェーズ

57. •現時点での流行・便利そうな技術への取り組み
•既存FWと著しく乖離しないポイントの見極め
•数年先も生きる/基礎となるようなものの選択
•温故知新
Offensive

58. 新しい実装によるメンテナンス性は？
新しく書かれたコードはどこ？
既存コードへのリプレイスは？

59. 20% offence
80% defence

60. 運用での取り組みとツール

61. Webサーバ・DBの設定
サーバーサイドとの連携

62. フロントエンドが手を掛けるべき
ポイントではない

63. 社内では「AeroMock」という
Javaプロジェクト向けツールを
導入しています
•軽量な起動
•APIレスポンスモック
•Tomcatの起動・再起動が不要

64. 共通知としての
ライブラリ・ツール

65. このライブラリ
便利だし入れよう
ライブラリの属人化
その人しか
使えなくない？

66. とはいうものの

67. オンライン上に存在するドキュメント
特定APIの設計・実装の時短
技術・知識レベルの平坦化
ライブラリ導入による
恩恵は大きい

68. みんなが使えるものを使う
必ず吟味する
必要であれば勉強会を開く

69. 仕様ドキュメント
を起こす

70. ドキュメンテーションはあって当たり前
実装引き継ぎの際のロスを低減させる
スタイルガイドを作ってデザイナーと共有

72. ソースコードレビュー
の文化

73. Enterprise

74. 属人化するコードの低減
コードベースで議論する
なるべく偏らないレビュー指名
気軽に機能追加・改善を試せる土壌

75. SVNからGHEに移行して、
他のメンバーのコードを読むことが
増えました（32歳 男性）

76. テストを書く
実行する

77. リファクタリングの副次効果
→メソッドの分割
→引数・戻り値の型の意識
→メンテナンス性の向上
精神衛生上良い

79. DOM周りのテストはやりづらい
DOMに癒着しすぎているメソッド
ロジック分離の意識
モデル・コンポーネント化

80. 自動化する

81. 特にマンパワーが必要な（面倒な）部分
•CSSスプライト生成
•画像減色 / チャンク削除
•PixelRatioイメージ自動生成
•JS結合とminify
•Sassコンパイル
•自動テスト
•etc...

82. 統計情報に基づく改善

83. コードに関する統計情報を出し、
改善の指針にする

84. platoの出力例

85. まとめ

86. チーム開発のいいところ

87. スタープレイヤー
フルスタックエンジニア(?)
技術的な相談ができる
多様なチームメンバー

88. ゲームディベロップ
に必要なスキル

89. ProjectA
ProjectB
ProjectC

90. 適応力

91. 流行りに流されない
普遍的な技術

92. キャラ付け

93. 1行の重み
1行の喜び

94. 自分のコードで
数百万人が楽しんでくれる

95. 自分のコードで
数百万人が遊べなくなる

96. コードに対する
責任感

97. 最終的に遊ぶユーザの気持ちで考える
・UI
・パフォーマンス
自ずと改善すべきポイントは見えてくる

98. パフォーマンスに
対する責任感

99. 目に見える・
感じる部分が
フロントエンドの
担保領域

100. 攻める部分と守る部分を明確に
メンバーの入れ替わりは結構頻繁にある
明日いなくなっても大丈夫なように
コミュニケーション力大事
一人よがりのコードを書かない
積極的にノウハウを共有していく

101. 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?