自己紹介
合同会社Muclaseのインターンとして働いているタコと言います！(会社のサイトは現在制作途中です)
弊社は主にMinecraft統合版のサーバー運営・開発を行っていて、現在は PararouteRPG というゲームを制作しています！
ありがたいことに、Minecraft統合版のサーバーとしては日本トップクラスの売上を誇っています！
僕自身のプログラミングの経験は、N高の通学プログラミングコースで2年間Web系の開発を主に学んできました！
これまでは、緩～く楽しく作りたいものをその都度調べながら手探りで作っていました。
主にJS, TSがメインでJSDocもclassもほとんど使わず、関数だけでゴリ押してたレベルです笑
インターンについて
ここからはインターンとして働いていくうちに起きたことについて書いていきます。
尚、弊社の環境は特殊で、現在、開発は僕と社長、そしてもう一人のみでやっています。
俗に言うベンチャー企業というやつで、ひとつひとつのタスクが想像以上に大きな責任をもっています。
そんな環境だからこそ、作業の遅れがそのままプロジェクト全体に響きます。
ここでは、その中でも特に印象に残っている出来事を紹介します。
仕事としての開発に触れた瞬間
最初の頃は、顧客を探すためのツール作成や、過去に作成された bot, utility 系のリファクタリングなどを任されていました。
それらの作業にはあまり手こずらず、少しずつ仕事にも慣れてきた頃、次のタスクとして メインのMinecraft Addonを動かしているScriptのリファクタリング を任されました。
RPGという特性上、頻繁にステータスや各種パラメータを変更します。
もし自分の変更でバグが出れば データの不整合 が起き、データ修正・補填などが必要になる部分です。
つまり、数百〜数千人規模のユーザーの体験に直接影響が出ます。
今まで "自分で動けばOK" だった開発とは違い、
「安全に動くこと」
「他人が読めること」
「壊さないこと」
これらすべてが前提になる "仕事としてのコード" と本格的に向き合うことになりました。
更に統合版は、スマホやSwitchなどのコンシューマー機で遊ぶプレイヤーも多いため、
最適化も必須になります。
これまでの開発とは全く違う視点や責任を意識しながら進める必要がありました。
仕事のリファクタリングでつまずいたポイント
先述で記述した通り、僕は当時JSDocもclassもほとんど使わず、関数だけでゴリ押してたレベルです。
過去の仕様や、当時の実装者の意図を読み取る必要があり、
“読み、理解するまでに半日がかかる” みたいなことが普通に起きました。
そんな中、playerApとplayerSpクラスで直接操作されているものをplayerStatusというクラスに内包する。というタスクを任されました。
今思い返すとバカだな～と思うのですが、最初実装するとき、
static classにすれば楽じゃね？
「インスタンス管理むずいし、とりあえず static ならどこからでも呼べるし便利じゃん！」という浅い発想で実装してプルリクを出しました。
もちろんレビューの段階でやり直しをもらい、
「これ何の意味があるの？”class内に内包して。”というままの意味でなく意図をくみ取って。」と言われました。
まぁ当たり前ですね。
そのあとも、自分なりに考えて実装してプルリクを送ってはレビューで何度もやり直しをしたのですが、
関数名以上の処理 をしてしまっている。
関数名以上の責任をその関数が持っていて、可読性が低いなど。いろいろ改善点をもらい
その都度、「どこが悪いのか」「どう実装すべきなのか」
を聞き、メモに残し学びながら修正していました。
僕はよくTwitterを見るのですが、当時は悔しくて、鍵垢の固ツイのリプに何が悪かったかメモ兼、戒めとして残して何度も見返していました。
出したプルリクが初めてrelease branchにmergeされたときはお昼にモスバーガーを食べた帰り道で若干感動して小さくガッツポーズをしたのを覚えています。
責任を実感した瞬間
初めてrelease branchにmergeされたときは嬉しかったのですが、それはつまり、ぼくの書いたコードが、本番環境で動き、数百のプレイヤーが、”そのコードの上で遊び始める”ということでした。
もしバグがあれば、ステータスの不整合が起きたり、データが飛んだり、補填作業が発生したり...
その影響は、僕の想像をはるかに超える規模です。
今までやってきた「あ、ここバグあるやん。直そ〜」とは全く違う。
“自分の作業には、他人の時間や体験が乗っかっている”
それにより莫大なお金が動いている
ということを、改めて実感した瞬間でした。
そしてやらかし
そして僕はやらかしました。
PararouteRPGではシーズンごとに大型アップデートを行い、ワイプ（リセット）を挟んで新シーズンを開始します。
その新シーズンのリリース直後、とんでもないバグが見つかりました。
特定のjobでリログするたびに、maxMpの上限が増えていく。
といったものでした。
幸いそのjobへの転職条件は厳しく、そこまでの影響はなかったのですが僕はその報告を受け、エラーを調べプルリクをだします。
そのプルリクが問題でした。
詳細なコードは守秘義務云々で載せることはできませんが、もともとMp, Sp, Hp, ApのManagerはだいぶ複雑なことになっています。
僕はそんな焦りの中
”Mpなどのデータをdbに保存するタイミングでステータス初期値を保存する”
というやらかしをします。
そのせいでリログするとHpが増えるアイテムを使ってももとに戻っている。というやばすぎるやらかしをします。
statusのManager当たりの実装はややこしくなっているとはいえ、絶対にやってはいけないミスでした。
「バグを早く直さないと。」
「とにかくこれ以上影響がでないように止めなきゃ」
という焦りのままプルリクを出し、ほかの人もほかのバグ対応などなど...に追われていてレビューが十分に行われずにmergeされてdeployしてしまいました。
その後そのやらかしにユーザーからの報告で社長が10分ほどで気づいて、Revert + jobのmaxMpの上限が増えていく場所をコメントアウトし、事態は落ち着いたのですがその時はあまり生きてる心地がしなかったです。
インターンでの経験を通して
僕は仕事としての開発で大切なことを身にもって学びました。
まず１つ目は、焦らず理解してから実装することの重要性です。
複雑なコードを浅く理解したまま修正した結果、余計に大きなバグを生んでしまう。ということを何度もしてしまいました。
それを通して、コードの見直し、動作チェック、既存の設計意図は何かを必ず確認してから作業するようになりました。
そして２つ目は、責任感とユーザー視点の意識です。
自分のコードがユーザー体験やプロジェクト全体に直接影響することを経験したことで、
「動けばいい」ではなく「安全で、読みやすく、最適化されている」コードを書くことが、エンジニアとしての最低条件だと理解しました。
この経験を経て、僕は単にコードを書くスキルだけでなく、
責任感・チームとのコミュニケーション力も身につけることができました。
これからも常に安全性・可読性・最適化を意識した実装を心がけています。
（上流工程をやり、要件定義書などを書いたり、貴重な学びにつながる体験をたくさんさせていただいたのですが、書くことがあまりには多すぎるので本当に印象に残っているものを抜粋しました）
ちょっとした宣伝
インターンではGitLabを使っていて、GitHubでContributionのGraphを見たときハゲまくっていたのでGitHubのプロフィールのREADMEなどで使えるGitHubとGitLabのcontributionを統合して画像として返すアプリを作りました。
よかったら使ってみてください！！