ゲーム運営の中で気をつけようと思ったパターン

これはマイネットエンターテイメント Advent Calendar 4日目の記事です。

はじめに

初めまして。
簡単に自己紹介から入ります。

私は今年からプログラマーとして弊社に入社させていただきました。
去年までは大学の情報系の学部でぬるぬるとプログラミングのお勉強をしていました。

今ではソーシャルゲームの運営、開発を行っています。
入社し、研修を受け、現在までに3つのタイトルに関わりました。
まだまだ勉強途中で、自分の力不足を感じる時が多くありますが、出た不具合の修正や確認ツール作成、さまざまな業務の中で徐々に開発の体系やソースコードに触れています。

そんな私がタイトル運営の中で気をつけようと思ったパターンを書こうと思います。
同じような立場の方への共有や、運営に関わってる方に、何かプラスになれれば嬉しいです。

いろいろなパターン

1.プランナーの作業を観察してみる

プランナーの作業を観察してみると、無駄な工数を発見できる時がありました。
管理画面での各種KPI確認、取り込みツールでの新アイテムの設定、動作テストなど様々な面において、プランナーはプランナーが持っている知識で作業を進めています。

複数の画面の表示を組み合わせることで特定の数値を割り出すような「管理画面の裏ワザ」や、イベント期間内のみのアイテムの使用期限を設定していたり、他の項目の確認ができていればこの項目の確認は不要と思える箇所の確認・・・・・他色々

しかし、実装を知っているエンジニアから見てみればそれらの手間を省く事が可能であり、より実装の精度の向上にもつながる事があります。

バグを見つけて修正した時、それがエンジニア外の作業も絡む物であれば、その元を確認してみることで、原因の根本解決や、工数削減、機能改修、と幸せになれる事があります。
(そんな事やってる時間がない、というパターンがおおいですが・・・・)

2.ドキュメントを残す際は意図と目的も

過去に開催していたイベントを復刻しよう！→詳しいドキュメントは残ってない(そもそもない)→過去の状況を復元してみる→動かない→実装面はコミットログを追うしかない
という事がありました。

なんとかコミットログを遡り、このへんのコミットかと憶測をつけ、それっぽい物を見つけ、必要な物を判断する
これだけでかなりの工数です。コミットログ以外も確認しなければいけません。
実装の方針が記述してあるドキュメントがあれば、少なくともこの工数は大幅に削減されます。
1回限りのイベントでも、復刻イベントだとしても、それに必要だった作業の簡潔なドキュメントを残す事を意識しています。俗人管理だめぜったい。

しかし、日々の新規実装やリファクタリングの関係で、昔どおりに仕込んでも動かないこともあります。
そのため、ドキュメントには「何の定義をするために」「どこに」「ここでこういう形式で扱うため」「ここに注意しながら」を残しておくと、以後仕様変更があった場合でも、本来の意図がわかればそれが手掛かりになるケースもあります。

(特殊なケースですが定数ファイルに様々な定義を盛り込むケースでは、これがあってかなり助かりました)

3.実装を疑う

バグの発生コードを修正するだけでは修正しきれてないパターンがありました。
自分がテストしていたフローでは修正されているが、他の箇所では修正されていない・・・

同じ処理をしている同じ名前の関数が複数個存在しているパターン、オブジェクトのパラメータとインスタンスメソッド名が同じで呼び出し方で返り値が変わるパターン、直書きで補完してたパターン、いつのまにか定義がMysqlに保存されておりやばくなるパターン・・・

すでにある処理が動いているから正義で、合っている。と考えて修正や実装に当たる事は危険です。
一回修正した後にIDEなどで全体検索をかける、この処理を使っている他のページを見に行く、先人に聞くなどして適度に確認範囲を調整する事が必要です。

おわりに

経験が浅く、至らぬ箇所が多かったとは思いますが、ここまで読んでいただきありがとうございました。

何を書こうか、と考えている時に、技術的に有意義な物をかけるか怪しいので、１新人がこういう考えを持って取り組んでいる、というものを残せば、似た環境の方への共有や、偉い方から見た時におかしい箇所をおかしいと言っていただきやすいのかと考えてこういう内容になりました。
書いていて思い直す事が多くあり、そもそもこれって・・・？と考え直す機会になりました。
今後も業務の中で学び、技術的に有意義な事をかけたらいいなと思っています。