前回までのあらすじ
ボックスガチャのサーバーサイドのコードの実装が完了しました。
また、テストコードの実装及びに、新規マスタのインポート処理も完了し、残るはクライアントとの繋ぎ込みのみです。
クライアントとの繋ぎこみ
くらいあんとえんじにあ「追加されるAPIのパスとかはもう共有されてるけど、まだパラメータとレスポンスの形ちゃんと貰ってないよ」
さーばーえんじにあ「あ、忘れてました......。纏めて返します」
ボックスガチャを引く POST: gachas/draw
parameter
{
gacha_code: integer, #対象ガチャコード
draw_count: integer #引く回数
}
response
{
characters: [ #引いたキャラクター達の情報
{
character_id: integer, #キャラクターID
character_code: integer, #キャラクターコード
level: integer, #レベル
.....
}
]
}
パラメータ、レスポンスは既存から変更なし
現在のボックスの中身を確認 GET: gachas/current_box_contents
parameter (クエリパラメータ)
{
gacha_code: integer # 対象のガチャコード
}
response
{
stage: integer, # 現在のボックスガチャのステージ
total_count: integer, # 現在のボックスガチャの中身の総数
remain_count: integer, # 現在のボックスガチャの残りの総数
contents: [ # ボックスの中身
{
character_code: integer, # キャラクターコード
total_count: integer, # 中身の総数
remain_count: integer # 残りの総数
}
]
}
ボックスガチャのリセット POST gachas/reset_box ......
各ステージでのボックスの中身の確認 GET: gachas/all_box_contents ......
さーばーえんじにあ「取り敢えずこんな感じですけど問題ありますか？」
くらいあんとえんじにあ「うーん、まあ、現状のUIで表示するものだと、これとこれとこれが足りないから追加して」
さーばーえんじにあ「了解です、改修終わったらAPI定義書に纏めておきますね」
※ APIのパラメータなどに限らず、仕様書とは別に定義書があると何かを調べる時にとても役立ちます。改修の度にきちんと更新されている事を前提として。
1時間後
さーばーえんじにあ「で、ソースと定義書の更新終わったからまたテストして......開発環境に反映！」
くらいあんとえんじにあ「不具合あったら報告するね」
さーばーえんじにあ「入念にテストしたから基本的に大丈夫だと思うけど、まあ、完璧な自信は無いので」
数時間後
くらいあんとえんじにあ「ボックスガチャだったら、引いた後の中身のレスポンスも同時に返してくれない？ 続けて引く時にさ、ガチャ結果からクライアントが判断してボックスの中身を減算するとかするより、サーバーからその時点の結果一緒に貰っちゃった方が良いと思うんだ」
さーばーえんじにあ「ボックスガチャの時だけそういうレスポンスを返すって感じですか？」
くらいあんとえんじにあ「そういう事」
さーばーえんじにあ「ボックスガチャでない時は空配列を返す形で良いですか？」
くらいあんとえんじにあ「おk」
さーばーえんじにあ「分かりました(バグは起きてないっぽいかな。良かった)」
くらいあんとえんじにあ「あ、Internal Server Error」
さーばーえんじにあ「ふぇっ！？」
その後、クライアントとの擦り合わせやバグの解消をして
くらいあんとえんじにあ「一通り見ましたが、これで基本的に問題ないです」
さーばーえんじにあ「確認ありがとうございますー」
実装は完了しましたがまだ終わりではありません
さーばーえんじにあ「じゃあ、後はコードレビューとか仕様の認識合わせとかして終わりか。レビューする前に自分のコード一回見直そう。
......変数名ちょっと分かりづらいやここ。直しておこう。あ、後、ここのレスポンスの追加、定義書に書いてないや。こうして......」
※ コードレビューは大事。動くだけの汚いコードは後々の全てに悪影響を与えます。ただ、そのレビューをする前にちゃんと自分のコードは見直して、気付いた点は直しておきましょう。そしてその修正でエラーが発生しないようにしましょう。
※ また、実装が完了した後での仕様の認識合わせも重要です。口答だけで追加された仕様などが抜け落ちている可能性などをしっかりと排除しておきましょう。
