機能を問題解決の経験に変える
講義の1週目に従い、基準プロジェクトで問題状況を作り、数値化パターンで文章を書きます。
- [必須] 基準プロジェクトをdocker composeで立ち上げ、GET /api/studies リスト照会のように頻繁に呼び出される機能を1つ選び、正常動作を確認します。講義1週目の「問題を作らなければなりません」に従い、その機能でユーザーが増えた場合に何が先に壊れるかを予測します。
- [必須] 選んだ機能の現在の応答時間を同じ入力で3回以上測定し、resume/resume.mdの根拠範囲に記録します。講義1週目の"性能とは & 性能測定"の定義をそのまま使います。
- [必須] 講義1週目の「数値化パターン」に合わせて履歴書の文章を1つ作成し、その文章の各数値がどこから来たのかをリポジトリ内のパスでリンクします。まだ測定できていない数値は確認不可と表示します。
- [必須] src/test/ 配下にその機能の回帰テストを1つ追加し、以降の週の改善が機能を損なわないか確認できるようにします。
- [選択拡張] 問題状況の候補を3つまで増やし、優先順位と根拠を併記します。
提出証拠 ・ 選んだAPIパスとdocker compose実行・レスポンス確認記録 ・ 同一入力で3回以上測定した応答時間と測定条件 ・ resume/resume.mdの数値化パターン文章1つと各数値のリポジトリ内の根拠 ・ src/test/ 回帰テスト1つと合格出力 ・ 質問1〜4の回答
함께 답할 근거형 질문 4개
- この機能でユーザーが増えた場合、真っ先に何がボトルネックになると予想されますか?また、その根拠は何ですか?
- 測定した応答時間が実際の使用パターンをどの程度代表しており、どのような限界がありますか?
- 作成した職務経歴書の文章において、チームの成果と自身の貢献をどのような根拠で区別できますか?
- 現在の文章でまだ検証できていない主張と、それを補完する計画は何ですか?


