こんにちは。
株式会社アカツキゲームスで ATLAS というチームに所属してゲーム内通貨管理基盤の開発及び運用を行っています、なかひこくん (@takanakahiko) です。 最近は、某メカアクションゲームの発売が待ち遠しくてたまりません。
私の担当するゲーム内通貨管理基盤の開発現場で、インターン生を受け入れました。 ありがたいことに、匿名ではありますが、そのインターン生がブログ向けに参加レポートを書いてくれたので私の方から代理投稿させていただきます。
上記の通り、この記事は代理投稿となります。 投稿者と執筆者は異なるのでご承知ください。
匿名で投稿させていただきます。
2023/07/10〜2023/07/28の3週間、アカツキゲームスのサマーインターンシップに参加させていただきました。今回はインターンシップで取り組んだこと、学んだことについてまとめていこうと思います。
自己紹介
私は大学入学時からプログラミングを勉強し始め、個人開発やインターンシップの経験を通じてWebサービスを開発してきました。現在メインで使用しているのはGo言語です。
私が今回アカツキゲームスのインターンシップを志望した理由は2つあります。1つ目はゲーム業界のバックエンドエンジニアの仕事内容を理解したいと思ったためです。2つ目はゲームの共通基盤、特にゲーム内通貨の管理基盤にインターンシップの時点で触れることができるのはアカツキゲームスだけだと思ったためです。以上の理由より、アカツキゲームスのインターンシップを志望しました。
取り組んだ内容
私がゲーム内通貨管理基盤のチームに配属され、3週間で取り組んだのは以下のタスクです
- 使用されていないAPIの削除
- ルーティングモジュールの変更
- テストケースの修正
使用されていないAPIの削除 (2.5日)
取り組んだこと
- 使用されていないAPIのルーティング情報の削除
- テストコード・Swaggerの修正
この課題はキャッチアップ課題として、メンターの方から初めに渡されました。該当のAPIのルーティング情報とそれに関連するドメイン処理を削除すれば良いのですが、このAPIやドメイン処理は、他のテストコードやAPIのドメイン処理で使用されていたため、一筋縄ではいきませんでした。
テストコードで該当のAPIを使用しているものに関しては、それと同等の情報を取得できる別のAPIを使用するようにテストコードを修正しました。ドメイン処理に関しては、このAPIで使用されているドメイン処理が他のAPIで使用されていることもあり、削除しない方針で進めました。
他にも、API仕様書としてSwaggerを使用しているためSwaggerの概要箇所を削除し、API仕様書の変更も行いました。
外見的にはエンドポイントを削除するというシンプルなタスクであっても修正が必要な箇所は多く、テストコード、Swagger等の依存を修正してはじめて、修正ができるという事を忘れてはならないと感じました。
ルーティングモジュールの変更 (7.5日)
取り組んだこと
- 乗り換え先のモジュール選定
- 実装
- テストコード修正
- パフォーマンス測定
この課題は、自分から提案して挑戦したメインの課題でした。ゲーム内通貨管理基盤はGo言語を使用していますが、その中でもルーティングモジュールとしてGorilla/Muxが使用されていました。
Gorilla/Muxは2022年12月10日にプロジェクトがアーカイブ化され、メンテナンスがストップしていました。(2023年7月28日時点ではメンテナンスが再開されています。モジュールの変更作業を行なっている間に、メンテナンスが再開するというタイムリーな事件もおきました)
メンテナンスがストップしているため、今後不具合や脆弱性が発見された際に修正が行われない可能性があります。安全なプロダクトを作るためにもゲーム内通貨管理基盤Gorilla/Muxへの依存をやめる必要があると考えました。結果として、モジュール選定・実装・テストコード修正・パフォーマンス測定を一貫して行うことになりました。
モジュール選定で考えたこと
ここからは、作成したスライドの内容も合わせてみるとわかりやすいと思います
モジュール選定で考えたことは主に４つあります
- メンテナンスされているモジュールに変える
メンテナンスされていないモジュールを使い続けると、将来的に不具合や脆弱性を抱え、セキュリティの問題を発生させます。コミット履歴やStarの数から、モジュールがメンテナンスがされているか、今後もメンテナンスが継続するのか判断しました - 依存を剥がしやすい
万が一、今後同様の事態が発生した際に即座にモジュールを乗り換えることができるようにすることは大切です。モジュールのドキュメントやソースコードを読んで、移行先のモジュールが依存を剥がしやすいかどうか判断しました - 大幅な変更を行わないで済む
大幅な変更を生む作業は時間や労力を多く使います。開発チームに影響が出ないレベルで(domain層以下の書き換えが発生するモジュールは使用しない)修正できるモジュールを選ぶようにしました - ユーザー体験を損なわせない
ユーザー目線で見ればゲームの課金がスムーズに行われることが大事です。レスポンスが低下しないモジュールを使用するようにしました
モジュールの移行先
上記の条件でモジュールの候補を挙げた結果、最終的にはnet/http・go-chi・Ginの三つまで絞りました。そこからミーティングを通じてモジュールの比較と検討を行い最終的にはgo-chiを使用することに決定しました。
Gorilla/Muxとgo-chiの書き方の比較
Gorilla/Muxをgo-chiに置き換えるにあたって実際に書いたコードをお見せすることはできませんが、細かな記述を修正するだけでルーティングモジュールを移行することができました。
パフォーマンス測定
移行したルーティングモジュールがユーザー体験を損っていないかどうか確かめるために、パフォーマンス測定を行いました。今回はローカル環境で計測を行い、Gorilla/Muxとgo-chiをルーティングモジュールとして使用した際の起動時間・レスポンスタイムを計測しました。テストコードの実装には Python言語で負荷試験を測定することができるlocustを使用しました。
結果として起動時間・レスポンスタイムが低下するということはなく、Gorilla/Muxよりもgo-chiの方が安定してレスポンスを返すことがわかりました。
自分から提案して課題に挑戦し、1.5週間でモジュールの選定・実装・テスト修正・パフォーマンス測定までやり切ったというのは、自分の中でも大きな経験と自信につながりました。課題をこなす中でもGo言語やモジュールのソースコードを読んでいくことも心がけ、Go言語に対する理解が深まったと感じました。
テストケースの修正 (1時間)
取り組んだこと
- テストコードの修正
こちらは1時間で修正〜マージの流れに持っていったので軽く説明します。テストコードを読んでいる最中に、テストケースが網羅されていない箇所があったので修正しました。不具合を発見した際に、即座に修正し、マージすることのできる環境が整っているのは良いと思いました。
その他
上記の取り組んだ課題には記載しませんでしたが、キャッチアップのための開発環境構築の資料を作成したり、パフォーマンス測定に関しては結果を記事として社内で公開するなど、アウトプットも欠かさず行いました。また、私の配属されたチームでは毎日のデイリーミーティングと、2週間に1回のスプリントレビューが行われており、毎日やったことと次にやることを常に共有していました。
3週間を通した感想
どのようにすれば短い期間でチームに貢献できるのか考えた3週間でした。貢献するためにはキャッチアップをした上で、メンターの方から与えられる課題だけではなく自分からも提案を行い、高難易度なタスクにも挑戦していくことが大切だということがわかりました。また、何をするのか迷うよりも、できることをできる限りやるという心持ちの大切さも学びました。特に、自分の書いたコードがマージされた瞬間・本番環境に反映された瞬間はとても感動しました。私もチームの一員として、貢献できたと実感しました。
今回の3週間では、機能実装・追加よりも、修正・リファクタリングの業務がメインでしたが、この流れはおそらく、入社後にすでに開発されているプロジェクトに配属され、そこで積む経験と同じなのだろうなと感じました。結果として、これまでは新規作成中心だった個人開発やインターンとはまた別の新鮮な経験を積むことができました。
チームに配属された感想ですが、「素晴らしい」と褒めてくれる環境がすごく素敵だと感じました。また、相手を否定しないということが、チームで活動する上では大切だと思いました。チームメンバーはリモートワークがメインのため、自身もリモートワークに慣れる必要がありました。私は1週目と3週目は出社し、2週目はリモートで参加しました。出社している最中でも会議室に移動したり、ラウンジに移動したり等、働く場所を変えることで気分転換に繋げたり、効率よく働くことができたと感じています。
個人的な工夫
3週間のインターンシップに取り組むにあたって、個人的に工夫・努力したことです。
GitHubのProjectsでタスク管理
GitHubのプロジェクト機能を使用して細かくタスクを管理していました。GitHub上でタスクを管理することで、現在自分が取り組んでいるタスクを把握し、チームメンバーと容易に共有することができました。また、1日の中で取り組むタスクの量を制御することで、無理をせず夜遅くまで残業しないということができました。
頭の中の思考を可視化する
常に自分が考えていることをSlackのtimesチャンネルで呟いていました。自分が困ったことをすぐに相談することができたり、問題が解決したりタスクが終わったりした時には、メンションやリアクションをすぐにつけてくださる環境が良いと思いました。
コードベースの議論
GitHub上ではコードベースの議論を心がけました。 Gorilla/Muxからgo-chiにモジュールを変更するため、使用されているVars関数について調べた際、モジュール自体のソースコードを読みながらコメントを入れていくことで、Gorilla/Muxとgo-chiでContextの使い方が異なることにすぐに気づくことができたり、テストコードの網羅についても「このミドルウェアの実装はこうなっているのに、このテストコードの実装はこうなっていて、この部分のテストケースの実装が抜けているよね」(抽象的ですみません...) という説明を、具体的なコードを示しながら作業することで、周りの理解を早くした状態で修正に取り掛かることができました。
最後に
3週間はあっという間でしたが、その中でも支えてくださったATLASチームの皆さん、メンターの方、インターンシップに参加する機会をいただいたアカツキゲームスの人事の方など、すべての方に感謝します。3週間ありがとうございました！
