twentyTwo/skill-hub — 코드 리뷰

코드 리뷰

사용자가 지정한 변경 사항(diff, 브랜치, PR 또는 커밋되지 않은 작업 트리)을 검토합니다. 사용자가 따로 지정하지 않으면 커밋되지 않은 변경 사항을 검토한 후, 현재 브랜치와 베이스 브랜치를 비교합니다.

검토 방법

1. 먼저 의도를 이해하세요. PR 설명, 커밋 메시지, 연결된 이슈를 읽으세요. 변경 사항이 무엇을 하려는지에 비추어 잘못된 것인지 판단할 수 있습니다.
2. 전체 diff를 읽은 후 주변 코드를 읽으세요. 변경된 함수와 해당 함수를 호출하는 쪽을 열어보세요. 대부분의 실제 버그는 새 코드와 기존 코드의 경계에서 발생합니다.
3. 다음 순서로 확인하세요.
   • 정확성: 논리 오류, off-by-one, 잘못된 조건, 처리되지 않은 null/빈 값/오류 케이스, 경쟁 조건, 리소스 누수, 잘못된 오류 전파.
   • 동작 변경: 마이그레이션 또는 메모 없이 변경된 public API, 파일 형식, 기본값, 데이터베이스 스키마.
   • 보안: 신뢰할 수 없는 입력이 쿼리, 셸, 파일 경로, HTML 또는 역직렬화기에 도달하는 경우; 코드나 로그에 비밀 값이 포함된 경우; 누락된 권한 확인.
   • 테스트: 변경 사항을 되돌리면 테스트가 실패합니까? 경계 케이스가 포함되어 있습니까?
   • 가독성: 오해를 불러일으키는 이름, 두 가지 일을 하는 함수, 코드와 모순되는 주석, 죽은 코드.
4. 보고하기 전에 검증하세요. 의심되는 각 버그에 대해 구체적인 입력 값을 추적하여 트리거되는지 확인하세요. 구체적으로 입증할 수 없는 것은 제외하거나 질문으로 표시하세요.

보고 방법

• 한 줄 평결로 시작하세요: 병합 준비 완료(ready to merge), 수정 후 병합(merge after fixes), 또는 재작업 필요(needs rework).
• 가장 심각한 결과부터 나열하세요. 각 항목에 대해 파일:라인, 무엇이 잘못되었는지, 구체적인 실패 시나리오, 제안 수정을 포함하세요.
• 반드시 수정해야 할 항목은 제안 및 질문과 분리하세요.
• 포매터나 린터가 잡아낼 스타일상의 사소한 문제로 리뷰를 늘리지 말고, diff가 무엇을 하는지 다시 설명하지 마세요.
• 주목할 만한 점(명확한 테스트, 신중한 마이그레이션)이 있으면 칭찬하세요. 한 줄로 유지하세요.