ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:実践編

アピリッツ コンテンツデザイン部の金井と申します。前回、前々回に引き続き、ソーシャルゲームにおけるミッション機能の話をしていきます。

関連：ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:問題編
関連：ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:思考編

前回までのあらすじ

　ソーシャルゲームにおけるミッション機能とは

• 構造的に改修し辛い
• 処理の時間が掛かり易い
• 問題が発生した場合それが大事になり易い

　加えて実装面でもミッション機能を構成する要素が複雑に絡み合う事が多々あり、クソコードになり易い。

　それらの問題を解消する為の自分の結論としては、API単位でミッションの処理を纏めるしかない。

実際にやってみた

　ええ、やりました。詳しくは言いませんが、出来る環境になった事があるので。
　そして目の前には、そこそこの期間付き合ってきた、さながら油でべたつく茶色にコーティングされた換気扇を思わせるようなコードがあったので。

　さて。綺麗に出来るタイミングにせよ、やるべき事は大量にありました。上記の仕組み以外にも、

• マスタ、ユーザーデータの構成が冗長である
• 過去のユーザー単位で1回しか通らないバッチ処理がそのまま残っている

　等々。
　それらも綺麗に出来るのならば、一気に綺麗にしてしまいます。どうせ、全体的にコードの差分が莫大になるのは明らかなのですから。
　ただ、しかし。マスタ、ユーザーデータの構成を変えてしまえば、もうそこから先に碌な休憩地点はありません。プロジェクトを健全に保つテストコードの文句を黙らせるまでは(え、テストコードが無い？　……ご愁傷様です)。

どの程度の時間的コストになったのか

　まあ、これの為には自分の経歴も多少書いておいた方が良いと思いますので。

• ソーシャルゲームサーバーエンジニア歴新卒4年目
• ソーシャルゲームの開発、リリース、運営を2度経験

　端的に書くとこんな感じです。まあ、入社して3年間でソーシャルゲームの全般を2度程経験した形ですね。
　そしてこの位の経験がある自分が、使い込まれたミッション機能を根本から作り直す事には、それだけに注力した状態で1~2ヶ月は掛かりました。

　また、実際のコードの差分は3500行、80ファイル以上でした。
　馬鹿でかいプルリクですが、基本的にここまででかいプルリクというのはマスタの構造の変更等で流し読み出来る部分が多かったりするものだと思います。
　しかし、このプルリクの中身は基本的にロジックの変更になります。要するに、大半が流し読み出来ないものです。
　更に言うならば、これだけ差分が大きくなる事が予見出来ようとも、自分の場合は途中でプルリクを出す事を出来ませんでした。自分が携わっていたそのコードを改善する為には、全体の挙動そのものの改善が必要だという事が途中で判明し、1APIだけを新挙動に書き換えて一旦プルリクを出す、というようなコンパクトな事もできなくなった為です。
　まあ、はい。コードレビュー等も必要に応じて行うべきかと思いますが、これだけのプルリクを見る事が出来る人が必要ですね！

精神的疲弊

　何日も何週間も同じ事柄へのリファクタリングを続けていると、流石に疲弊してきます。

　プランナーと掛け合い、無駄や冗長を削ぎ落としたミッションの仕様を新たに殆ど一から構築し直す。
　その為に既存のコード……仕様が追加、変更された事により、まるで後先考えずに違法増築を繰り返されて巨大地震でも来れば粉々に瓦解してしまいそうなそれを必死こいて読み直し、それらを綺麗に纏め上げる。
　纏め上げる最中に不必要になった変数や新たに必要となるユーザーデータなどが発生して来れば、それらの一つ一つが本当に不必要か、必要かを吟味した上で削除、追加をしていく。
　テストコードもそのままでは失敗を叫び続けるだけであり、その新たな規範に沿って作り直すところから始めなければいけない。

　……そんな作業の一つ一つを地道に、丹念に続けるにはかなりの労力が必要になります。更に続けていると、

　途中でどうしてこんな事に手を出してしまったのかという後悔が湧いてきたり。
　業務中に暫くぼーっとしたくなったり。
　業務終了後も帰りの電車の中でぼけーっとミッションの事を考えたり。
　夢の中でミッションのコードを弄っていたり。
　誰かのプルリクが飛んでくるとミッション以外のコードを見られる事に喜んですぐにレビューを飛ばし、そして同時にマージする時のコンフリクトの量がまた増えた事に辟易とし。

　ただ、それでも自分は精神的支柱があったからこそ出来たと思います。
　それは何かと言われると、まあ、はい。クソコードに対する憎悪、それに尽きます。

　以前はこのクソコードを根本的にどうにも出来る余裕がなかったから、余計にクソコードを追加して負荷や計算量を減らすしかなかった。
　このクソコードが分かりづらいから本番でエンバグを何度も引き起こした。
　このクソコードのせいで休日に出社する羽目になった。
　このクソコードを新しいプロジェクトでも残し続けていたらまた同じ目に遭う。
　クソコード……駆逐してやる！　このプロジェクトから……一行残らず！

　そんな意志が私の最大の精神的支柱でした。
　流石にソースの全体に及ぶ程に大きい改修するのは初めてでもあったりして、挑戦するような気持ちもあったのですが、そんなものは二の次で。
　お前は存在してはいけない生き物だ、と某生き恥ポップコーンさんに告げるような絶対なる意志を用いて滅しました。

改修は本当に価値があったか？

　はい。それは断言出来ます。
　少なくとも、

• 各所に散乱していた似たようなロジックや冗長な処理
• 殆ど実際に動く事は無いのに常に通ってクエリだけを投げていく処理

　は巻物を投げつけられたドラゴンの如くジェノサイドされ、

• 現状の仕様を満たす処理はそれぞれ端的に纏まった形で集約されている
• 仕様変更に対してもそれらのみを改修する事によって対応可能

　という状態にする事が出来ました。
　デイビークロケット並の予想だにしない仕様改修依頼が無い限りは、ミッションの処理はここに集約されたままに出来ると思える位には。
　勿論、まだ怪しい部分もあります。しっかりと負荷試験をして性能を数値として出してはいませんし、改修した中でも時間の掛かる冗長な処理がまだ残っているかもしれません。
　もしかしたらそんなデイビークロケットをパンジャンドラムに乗ったプランナーから渡される可能性もあります。
　しかし、まあ、そんな仕様は来ない事を信じたいなあ……。

最後に

　この巨大プルリクを半日掛けて見て下さった先輩に感謝します。