Description
エラーメッセージをreturn文中にハードコードしていた。複数言語対応などを考えるならば、一つのファイルにエラーメッセージを格納しておき、これを参照するほうが良さそうな気がする
よく考えると、collectionリスト中のIDはアイテムIDではなくcollectionのIDを記載するべきだった。アイテムIDで返却すると、コレクションリスト内から単一の要素について取得する必要が発生した場合に、コレクションリスト内からuserIDとアイテムIDを使用して絞り込むことになるが、コレクションIDを返しておけばPKで検索できるので速くできたはず？
issueを作って、そこに対して機能実装を行なっていたが、実装の前提で別の実装を行う必要が生じた時、sub issueなどを使わず同じブランチでついやってしまったので、もう少しタスク分割して進めたほうが良さそうかなと思った
bonus要件を満たすユニットテストとまでは行かなくても、e2eテストぐらい作ればよかった。レビュー中に手動でテストしていると時間がかかってしまい、レビューが中弛みする原因の一つになったと思う。
MakefileでmakeでAPIサーバ起動にしている点。実行ならallじゃなくてrunとかでもよかったのかも
slog.Timeしなくても、時間はデフォルトで登録されているようだったため、Timeが2個になっていた。ログはサーバの容量を圧迫する原因なので、この重複は不味かったかも
dmlで設定したガチャを一度に引ける数の上限値がデカすぎた時に負荷かけないよう、ハードコードで100に制限していた。一度に引ける数の上限値より大きく、100以下であった場合、ユーザに対して400じゃなく500が返却されていた。apiドキュメントにはエラー時のレスポンスについて記載はないが、ここは400が適切かも
キャッシュが存在しない場合、DBからデータを取得する処理まではまだよかったが、その後キャッシュに設定し直すべきだったかも
設定情報を1行1設定値で設定していた点。設定値を増減させると、テーブル構造に手を入れなくちゃいけなくなってあまりいい手法じゃないかもと思った
アイテムと設定以外はサーバーとDB間でやりとりしていたが、この辺のDB操作をキャッシュしておいて、あとで纏めてDBへのアクセスを行ったほうがより負荷を減らせたかも
負荷が今どれだけかかるのかをコードからの勘じゃなくて、定量的に理解する環境整備が必要だったかも、というかこれほしい
You can’t perform that action at this time.
