Go 코드 리뷰은(는) 무엇을 하나요?
목표: 변경 사항이 코드베이스를 더 건강하게 만드는 것입니다. 완벽할 필요는 없습니다. 개인적인 취향 때문에 변경을 막지 마십시오.
1단계: 변경 사항 확인
- 사용자가 diff, PR 또는 파일을 제공했다면 그것을 사용하세요.
- Git 저장소인 경우:
git diff --stat main...HEAD, 그다음git diff main...HEAD(main이 없으면master또는origin/main시도). 커밋되지 않은 작업의 경우:git diff및git diff --staged. - 변경 목적이 불분명하면 한 줄로 간단히 물어보세요.
2단계: 컨텍스트 읽기
- diff 라인뿐만 아니라 변경된 모든 함수 주변의 전체 파일을 여세요.
- 변경된 exported 함수의 호출자를 찾으세요:
grep -rn "FuncName(" --include=*.go go.mod에서 Go 버전을 확인하세요. 일부 조언은 이에 따라 달라집니다 (Go 1.22부터 루프 변수는 반복마다 새로 생성됩니다).
3단계: 도구 실행 (명령어를 실행할 수 있는 경우)
go build ./...
go vet ./...
go test -race ./... # 저장소가 느리면 변경된 패키지만
golangci-lint run ./... # 설치되어 있거나 저장소에 설정이 있는 경우에만
실제 실패를 보고하세요. 포매팅에 대해서는 "gofmt 실행"을 한 번만 말하고 모든 줄을 나열하지 마십시오. 명령어를 실행할 수 없으면 한 줄로 말하세요.
4단계: 다음 순서로 리뷰
큰 것부터 먼저. 설계가 잘못되었다면 먼저 말하고 사소한 것은 건너뛰세요.
- 설계 – 이 변경 사항이 여기(이 패키지, 이 서비스)에 속합니까? 나머지 시스템에 적합합니까? 지금이 적절한 시기입니까?
- 기능 – 작성자가 의도한 대로 작동합니까? 그것을 사용하는 사람들(최종 사용자와 미래 개발자)에게 좋은가요? 엣지 케이스와 동시성을 고려하세요.
- 복잡성 – 독자가 빠르게 이해할 수 있습니까? 과도한 엔지니어링(오늘의 문제 대신 상상된 미래를 위해 작성된 코드)을 주의하세요.
- 테스트 – 동일한 변경 사항에 테스트가 있습니까? 코드가 손상되면 테스트가 실패합니까? 간단한가요?
- 명명 – 명확하고, 너무 길지 않으며, Go 스타일을 따릅니다.
- 주석 – 무엇이 아니라 이유를 설명하세요. 오래된 주석과 완료된 TODO는 제거하세요.
- 스타일 – gofmt, 스타일 가이드. 개인적 선호 = Nit만.
- 일관성 – 스타일 가이드가 주변 코드보다 우선합니다. 가이드에 언급이 없으면 주변 코드를 따르세요.
- 문서화 – README, godoc, 구성/env 변수, 마이그레이션이 동작 변경 시 업데이트되었는지 확인하세요.
- 모든 라인 – 모든 사람이 작성한 코드를 읽으세요. 생성된 코드(
*.pb.go, mock, sqlc 출력)는 훑어볼 수 있습니다. - 코드 건강 – 이 변경으로 전체 시스템이 더 좋아지나요 나빠지나요?
- 좋은 점 – 실제로 보이는 좋은 점을 언급하세요.
각 영역에서 Go 특화 검사를 위해 references/go-checklist.md를 읽으세요.
항상 오류, 동시성 및 리소스 섹션을 확인하세요. 대부분의 Go 버그가 여기에 있습니다.
심각도 레이블
- 차단기 – 버그, 데이터 경쟁, 고루틴 누수, 보안 문제, 깨진 테스트, 잘못된 설계. 병합 전에 반드시 수정해야 합니다.
- 수정 권장 – 실제 문제이지만 긴급하지 않습니다. 작성자가 논쟁할 수 있습니다.
- Nit – 작고 선택적인 개선 사항. 항상 "Nit:"으로 댓글을 시작하세요.
- 질문 – 이해하지 못하는 부분. 이해할 수 없다면 다른 사람도 이해하지 못할 것입니다. 더 명확한 코드를 요청하세요.
문제를 만들어 내지 마십시오. 좋은 변경 사항은 짧은 리뷰를 받습니다. 버그인지 확실하지 않으면 차단기 대신 질문을 사용하세요. 일부 파일이나 측면만 리뷰하라는 요청을 받으면 어떤 부분을 리뷰했는지 말하세요.
출력 형식
## 요약
1-2문장: 변경 사항이 무엇을 하는지. 평결: 승인 / 의견과 함께 승인 / 변경 필요.
## 차단기
- `path/file.go:42` – 무엇이 잘못되었고 왜 중요한지.
```go
// 제안된 수정
```
## 수정 권장
## Nits
## 질문
## 좋은 점
## 확인한 내용
실행된 도구와 결과, 검토된 파일, 건너뛴 항목.
빈 섹션은 제외하세요. 각 댓글: 문제, 이유, 수정. 간결하게 유지하세요.