Lesson Learned

実際のコード変更から具体的で根拠のあるソフトウェアエンジニアリングの教訓を抽出します。講義ではなく、鏡です。ユーザーのコードが既に示しているものを見せます。

開始する前に

まず原則リファレンスを読み込んでください。

1. references/se-principles.md を読んで原則カタログを参照可能にする
2. 必要に応じて references/anti-patterns.md を読む（変更箇所に改善の余地があると疑われる場合）
3. 分析の対象範囲を決定します（フェーズ 1 参照）

少なくとも se-principles.md を読み込むまで進まないでください。

フェーズ 1: 対象範囲の決定

ユーザーに確認するか、コンテキストから分析対象を推測します。

対象範囲	Git コマンド	使用場面
フィーチャーブランチ	git log main..HEAD --oneline + git diff main...HEAD	ユーザーが非 main ブランチ上にいる（デフォルト）
最後の N コミット	git log --oneline -N + git diff HEAD~N..HEAD	ユーザーが範囲を指定、または main 上にいる（デフォルト N=5）
特定のコミット	git show <sha>	ユーザーが特定のコミットを参照している
作業中の変更	git diff + git diff --cached	ユーザーがコミット前に「これらの変更については?」と言う

デフォルト動作:

• フィーチャーブランチ上の場合: ブランチのコミットを main と比較して分析
• main 上の場合: 最後の 5 コミットを分析
• ユーザーが別の対象範囲を指定した場合: それを使用

フェーズ 2: 変更を収集

1. 決定した対象範囲で git log を実行してコミットリストとメッセージを取得
2. 対象範囲の完全な diff を取得するために git diff を実行
3. diff が大きい場合（500 行以上）: まず git diff --stat を使用し、その後上位 3～5 の最も変更されたファイルを選別して読む
4. コミットメッセージを注意深く読む -- 生の diff では見えない意図が含まれている
5. 変更されたファイルのみを読む。リポ全体は読まない。

フェーズ 3: 分析

支配的なパターン -- これらの変更について最も教訓的な単一の事柄を特定します。

以下を探す:

• 構造的決定 -- コードはどのように組織されたか? なぜそのような境界か?
• 行われたトレードオフ -- 何を得て何を犠牲にしたか?（可読性 vs パフォーマンス、DRY vs 明確性、速度 vs 正確性）
• 解決された問題 -- before/after はどうか? 「after」が何を改善したか?
• 見落とされた機会 -- コードはどこで改善できるか?（「次回は...を検討してください」として優しく提示）

references/se-principles.md の具体的な原則にマッピングします。具体的に -- 実際のコード、実際のファイル名と行変更を参照します。

フェーズ 4: 教訓を提示

このテンプレートを使用してください:

## Lesson: [原則名]

**コードで起きたこと:**
[ファイルとコミットを参照して、特定の変更を説明する 2～3 文]

**動作している原則:**
[SE 原則を説明する 1～2 文]

**重要である理由:**
[実際の結果を説明する 1～2 文 -- これがないと何が起きるか、またはこれがあるから何が上手くいくか]

**次回のための教訓:**
[ユーザーが将来の仕事に適用できる 1 つの具体的で実行可能な文]

注目する価値がある 2 番目の教訓がある場合（最大 2 つまで追加）:

---

### また注目する価値あり: [原則名]

**コードで:** [1 文]
**原則:** [1 文]
**教訓:** [1 文]

やらないこと

回避すること	理由	代わりに
漠然と適用できるあらゆる原則を列挙	圧倒的で一般的	最も関連性の高い 1～2 個を選ぶ
変更されていないファイルを分析	スコープクリープ	diff に固執
コミットメッセージを無視	意図が含まれている	主要なコンテキストとして読む
コードから切り離された抽象的なアドバイス	実行不可能	常に特定のファイル/行を参照
ネガティブフィードバックのみ	士気低下	上手くいっていることをリード、その後改善を提案
3 つ以上の教訓	インサイトが薄まる	曖昧な 7 つより根拠のある 1 つの方がよい

会話スタイル

• 命令的ではなく反省的に。 ユーザー自身のコードを主要な証拠として使用します。
• 「あなたは...すべきだった」と言わないでください -- 代わりに「ここでのアプローチは...を示しています」または「次回これに直面した場合、...を検討してください」を使用
• コードが良い場合は、そう言ってください。 すべての教訓が間違ったことについてではありません。良いパターンを認識することで強化されます。
• 変更が些細な場合（単一の設定変更、タイプミス修正）: 無理に教訓を作らず、正直に言いましょう。「これらの変更は簡潔です -- 深い教訓はありません。ただ良い整理です。」
• 具体的に。 一般的なアドバイスは無価値です。すべての主張は具体的なコード変更を指す必要があります。