PR 설명 + 이해 확인 퀴즈
AI 기반 코딩을 통해 이해하지 못한 코드를 쉽게 승인할 수 있습니다. 이 스킬은 리뷰어가 필요한 수준으로 변경 사항을 설명한 다음 몇 가지 핵심 질문으로 이해도를 확인합니다. 그래야 'LGTM'이 진정한 의미를 가지게 됩니다.
1. 변경 사항 수집
해당되는 것 중 선택하세요:
gh pr view <num> --json title,body,baseRefName,headRefName,files # GitHub PR
gh pr diff <num>
git diff <base>...<head> # 브랜치
git show <sha> # 단일 커밋
PR 설명과 연결된 이슈(있는 경우)를 읽으세요. 그런 다음 변경된 함수의 주변 코드(호출자, 피호출자, 테스트)를 읽으세요. diff만으로는 중요한 컨텍스트를 알 수 없습니다.
2. 다음 순서로 설명
- 한 문단 요약: 사용자나 호출자에게 어떤 동작이 변경되는지 설명합니다. 파일 목록이 아닙니다.
- 이유: 해결하려는 문제를 설명/이슈/커밋 메시지에서 찾습니다. 이유가 명시되지 않은 경우 그 사실을 말하세요. 이것은 리뷰 결과입니다.
- 다이어그램: 새로운 흐름에 대한 Mermaid
sequenceDiagram또는flowchart로, 새롭거나 변경된 부분을 강조 표시(노트나:::changed클래스 사용)합니다. 약 15개 노드 이하로 유지하고 핵심 경로만 나타냅니다. - 개념별로 설명, 파일별로 설명하지 않음: 관련된 hunk를 그룹화합니다("재시도 로직", "새로운 구성 플래그"). 각각에 대해: 무엇을 하는지, 그리고 명확하지 않은 점(동시성, 오류 처리, 에지 케이스, 성능)을 설명합니다.
- 위험 노트: 리뷰어가 가장 집중해서 봐야 할 사항 — 변경된 공개 인터페이스, 마이그레이션, 삭제된 테스트, 무시된 오류 경로, 보안에 민감한 코드, 새로운 분기에 대한 누락된 테스트.
파일:줄형식으로 구체적으로 명시하세요.
3. 퀴즈
3-5개의 질문을 한 번에 하나씩 제시하고, 각 답변을 기다린 후 다음 질문을 제시합니다. 좋은 질문은 이해를 요구하며 단순 암기를 요구하지 않습니다:
- "
<작업>중<의존성>이 타임아웃되면 이제 어떻게 되나요?" - "서명 변경에 영향을 받는 기존 호출자는 무엇이며, 어떻게 영향을 받나요?"
- "
<줄>이<줄>앞에 와야 하는 이유는 무엇인가요?" - "마이그레이션 실행 후 이 변경을 롤백하면 무엇이 깨지나요?"
사소한 질문(예: "새 함수 이름은 무엇인가요?")은 피하세요. 적어도 하나는 실패/에지 케이스에 관한 것, 하나는 설계 선택 이유에 관한 것을 포함하세요.
각 답변 후: 맞는지 여부를 알려주고 코드 참조와 함께 1-3문장으로 정확한 설명을 제공하세요. 중요한 부분에서 틀린 경우, diff의 어느 부분을 다시 읽어야 할지 제안하세요.
4. 마무리
점수(예: 4/5)와 짧은 평가: "리뷰 준비 완료", 또는 "승인 전에 X를 다시 읽으세요". 발견된 위험에 대한 리뷰 코멘트 초안을 작성해 드릴 수 있습니다.
요청 범위에 맞게 조정
전체 흐름(요약 → 이유 → 다이어그램 → 설명 → 위험 → 퀴즈)은 "이것에 대해 설명해줘" 또는 "리뷰 도와줘"의 기본값입니다. 사용자가 요청을 좁히면 그에 따릅니다:
- "퀴즈 없음" / "퀴즈 스킵": 퀴즈 없이 1-2단계만.
- "요약과 위험만": 한 문단 요약과 위험 노트만. 다이어그램이나 설명은 제공하지 않음. 나머지는 마지막 한 줄로 제공합니다.
- "다이어그램만": 다이어그램과 두 문장의 설명문.
첫 번째 위험은 사용자나 금전적 동작을 변경하는 위험(예: 조용한 잘못된 청구)을 나열해야 하며, 기술적으로 가장 흥미로운 것이 아니어야 합니다.