この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
もはや味噌カツではない
前回までのあらすじ
以下のゲームで、
牧場経営ソーシャルゲーム:
ユーザーは牧場を経営する。また、牧場などで育てたものを調理し、食べる事が出来る。
ユーザーにはステータスが存在し、様々な行動によってステータスが変動する。ある一定のステータスを伸ばすと出来る事が増える。
ステータスは割合で決定されており、どれかのステータスを上げると他のステータスが落ちる。
一度得た能力は消えない。
味噌カツを作る事が決定しました。
提示された仕様書を読み込み、それに対して曖昧な点や改善すべき点を会話して解消した後に、サーバーエンジニアがすべき事は以下のように明確になりました。
・味噌カツを消費する事でユーザーのステータスのナゴヤ成分が上昇する、は既存のコードで対応可能か確認する
=>変わらず
・味噌カツを作るAPIは既存の調理APIとは別として新規に作成する
=>既存の調理APIとはかけ離れた部分が多くなった為
・味噌カツトップ画面の為のAPIを作成する
=>クライアント側で持っていない情報を表示する必要が確定した為
返すものは
・味噌カツを作成する為に必要な素材種別群
※実装する事が複雑でなくとも設計書として纏めて共有しておくとベターです。
仮実装までの想定日数は2日と定めました。
仮実装
実装に対して何から始めていくのかはどのような開発手法を取っているかによって違ってくるかと思いますが、ゲーム開発においての最優先事項は実機で確認出来る状態を作る、という事だと思いますので、それに沿って仮実装を行います。
さーばーえんじにあ「まあ、軽いやつからやっていくか」
味噌カツを消費する事でユーザーのステータスのナゴヤ成分が上昇する、は既存のコードで対応可能か確認する
さーばーえんじにあ「料理を消費する事でユーザーのステータスが上昇する仕組みはもうあって、料理には出来の良さの値も保存されていて、それに依存してステータスの上昇度合いが変動する仕組みもある。
だから、それが味噌カツだろうと味噌カツじゃなかろうと、特に何もする必要はやっぱり無いな」
味噌カツトップ画面の為のAPIを作成する
さーばーえんじにあ「やるべき事は、あれ……これ、調理トップ画面もいじらないといけないか。
味噌カツ以外にもそういう風に調理できるものが増えた場合、調理トップ画面からの遷移先が複数になるかもしれない。その複数の遷移先を判別出来る情報を調理トップ画面でも渡さなきゃいけないか。
クライアントエンジニアさん、そんな感じで良いですか？」
くらいあんとえんじにあ「りょーかい。今回は取り敢えず遷移先1個だけだけど、レスポンスの形は、今回は配列じゃなくて良いかな？
遷移先が複数になったらUIもそういう風に対応しなきゃいけないだろうからさ」
さーばーえんじにあ「分かりましたー」
さーばーえんじにあ「じゃ、味噌カツトップ画面では、クライアントから受け取った値を参照して、対応するマスタの情報を返す。
レスポンスの形はクライアントエンジニアと相談する必要あるな」
くらいあんとえんじにあ「素材の種類が最大6つって決まっているなら、配列じゃなくて、それぞれ別のキーとして返して欲しい」
さーばーえんじにあ「りょーかい。現状だとそれだけだか。すぐ終わる」
味噌カツ作成のAPIを作成する
さーばーえんじにあ「えーっと、普通の調理APIをコピって、違う部分を変えていけばいいな。
パラメータは味噌カツの素材群と味噌カツを作るという宣言が必要。
通常の調理の時の素材存在確認とかのアサーションに加えて、本当にその素材で味噌カツが作れるかを確認。
マスタを参照してどの味噌カツが作られるかを決定。ユーザーのステータスに加えて、そのマスタのデータを基にして味噌カツの出来の良さを決定。
…………。
まあ、取り敢えずそこあたりは仮実装だから適当にやっておこう。また後で必要なアサーションをリスト化したりしよう。
レスポンスは作られた味噌カツでいいのかな？」
くらいあんとえんじにあ「そーだな、調理完了演出はそんなに普通の調理と変わらないから、多分それで事足りる」
さーばーえんじにあ「おっけ。後は必要なマスタのテーブルを作る処理とか、CSVからインポートする処理とか入れて……。
明日には仮実装反映出来そうです」
くらいあんとえんじにあ「わかりました」
さーばーえんじにあ「APIのURLと必要なパラメータ、返されるレスポンスはこっちに書いておきました。後、調理APIでの追加パラメータはこんな感じです。これでいいですか？」
くらいあんとえんじにあ「……多分」
さーばーえんじにあ「追加で欲しいものあったら言ってください」
さーばーえんじにあ「で、後はマスタ待ちか。
適当に作ってあるところしっかりと作ったり、テストコード書いたり、影響範囲纏めたり、そういう事しておこう」
仮マスタが来ました
ぷらんなー「マスタ、仮で出来たよ」
さーばーえんじにあ「入れてみますー。あ、ミスった、直して……ん？ ちょっといいですか？」
ぷらんなー「ん？」
さーばーえんじにあ「何でも良い部分の素材アイテムコードって、0を入れるんですっけ？」
ぷらんなー「あ、それじゃまずい？」
さーばーえんじにあ「まー、どっちでも良いです。えーっと、既存コードに合わせるとして、他の部分どうだったっけ……基本的に0だけどnullの部分もある……あー、うー、えー……。0の方が多いか……。こっちが対応します」
※既存のクソコードは影響範囲が大きくなるのならばそっとしておいた方が良いかもしれません
ぷらんなー「わかった」
さーばーえんじにあ「後は問題なさそうですね」
ぷらんなー「りょうかい」
さーばーえんじにあ「APIの確認もして……あ、getだとパラメータは全部文字列か……直して……出来た、反映出来る」
仮実装反映後〜補強して本実装
実機確認
さーばーえんじにあ「開発環境に反映しました」
くらいあんとえんじにあ「りょーかい、確認しておく」
くらいあんとえんじにあ「なんかInternal Server Error起きた」
さーばーえんじにあ「えっ、確認します」
さーばーえんじにあ「あー……さっきの確認の時、この条件の時の事漏れてたな……」
さーばーえんじにあ「修正反映しました」
※仮実装でもこういう事を頻発させるとエンジニアとしての信頼度が落ちていきます
くらいあんとえんじにあ「りょーかい……大丈夫、取り敢えず後は問題無さそう」
さーばーえんじにあ「りょーかいです」
くらいあんとえんじにあ「こっちも後で確認出来る状態のもの上げておくから、上げたらそっちでも確認してみてね」
さーばーえんじにあ「わかりましたー」
仮実装から本実装へ
さーばーえんじにあ「さて、アサーションとかちょっと適当にやってた部分ちゃんとやるか。
今回でやるべきなのは……普通の調理と比較した場合……まあ、この位だな。
コード修正、書き加えて、その分のテストコード書いて。
味噌カツ作りが失敗する。
条件1:味噌カツなのに豚肉ではなく牛肉を選んだ
条件2:味噌カツなのに味噌が無い
条件3:味噌カツを作る為のお金が無い
条件4:味噌カツを作る為に選んだ素材が既に存在しない
条件5:味噌が賞味期限切れ
……
味噌カツ作りが成功する。
判定1:味噌カツを作ったので豚肉、味噌、パン粉等が消費される
判定2:味噌カツを作ったので味噌カツが増えている
判定3:味噌カツを作ったのでお金が減っている
判定4:この材料で味噌カツを作ると名古屋コーチンという名の味噌カツが作られ、また、出来栄えは乱数を鑑みた上でこの範囲内に絶対に収まり、その作成情報がログとして保存される
判定5:この材料で味噌カツを作るとマスタ内のどのレコードの条件も満たせないので、平凡な味噌カツが出来る
判定6:味噌カツを合計1000個作るとそのアチーブメント”最早名古屋”が達成される
判定7:神聖なる新生味噌カツ新星を作るとアチーブメント”新しい名古屋”が達成される
……
……え、単純に箇条書きしたら20件ほど必要なテストが出てきたんだけど、これ全部テストコード書くの？」
※そうです。書かないと改修が必要になった時の既存コードの保証が出来ません。
さーばーえんじにあ「ダミーユーザー作ってダミーマスタ作ってダミーユーザーデータ作って……今日の昼はコ●ダで味噌カツサンド食べよう……。
マスタの準備さえ出来れば後は似たようなコードコピーして判定部分だけ変えていけばいいはずだから……」
数時間後
さーばーえんじにあ「あー、終わった。まあ、ちょっとバグも直せたし、これで一旦大丈夫か……じゃあ後は、影響範囲纏めて、QAに提出する確認すべき範囲も纏めて、コードレビューして、終わり、か。
ちょっと遅くなったけどコ●ダ行こう」
くらいあんとえんじにあ「ちょっと良い？」
さーばーえんじにあ「えっ」
