2nd/10_Wiki/Topic_Programming/Coding/Quality_Code_Review_Modern.md

id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases

id	title	category	status	source_trust_level	verification_status	created_at	updated_at	tags	tech_stack	applied_in	aliases
quality-code-review-modern	Code Review Modern — AI-assisted / async / culture	Coding	draft	B	conceptual	2026-05-09	2026-05-09	quality review vibe-coding	language applicable_to process Engineering		code review AI review CodeRabbit Greptile async review review culture small PR

Code Review Modern

AI-assisted + culture-aware. CodeRabbit / Greptile (AI), small PR, async-first, blameless.

📖 핵심 개념

• AI 가 first-pass.
• Human = critical 만.
• Small PR culture.
• Async + thread-based.

💻 코드 패턴

AI review (CodeRabbit)

# .coderabbit.yaml
language: en
reviews:
  profile: chill   # or 'assertive'
  request_changes_workflow: false
  high_level_summary: true
  poem: false

PR open → CodeRabbit 가 review.
- Bug detect.
- Style suggestion.
- Test coverage.
- Documentation.

→ Human 가 critical 만 review.

Greptile / Sourcery

- Greptile: codebase-aware (큰 PR 친화).
- Sourcery: 매 commit refactor.
- Cursor / Copilot: inline.

→ 매 tool 의 different focus.

Self-review (먼저)

PR open 전:
1. Diff 검토.
2. Test 실행.
3. Self-comment ("이 가 의도?").
4. Description 작성.

→ 매 reviewer 의 시간 절감.

PR description

## Why
[motivation]

## What
[change list]

## Testing
- [x] Unit test added.
- [x] Manual test.

## Screenshot / Loom
[image]

## Out of scope
[what NOT done]

Small PR culture

< 100 LOC: ideal.
100-400: OK.
400+: split.

→ 작은 PR = 빠른 review = 빠른 feedback.

PR size 측정

# GitHub
- name: PR size check
  run: |
    LOC=$(gh pr diff ${{ github.event.pull_request.number }} | wc -l)
    if [[ $LOC -gt 1000 ]]; then
      gh pr comment --body 'Large PR — consider split.'
    fi

Review SLA

Target:
- First review: < 4 hour.
- Approve / changes: < 1 day.
- Merge: < 2 day.

→ Long PR = lead time ↑.

Blameless culture

"이 code 가 잘못" — focus on code.
"You wrote bad code" — personal.

→ "이 가 의도?" 보다 "왜 이 approach?" 가 좋음.

Comment 의 levels

Nit: trivial (skippable).
Suggestion: optional improvement.
Question: clarify.
Required: must fix.

→ 명시적 prefix.

nit: extra space here.
suggestion: consider extracting.
question: why this approach?
required: race condition here.

Conventional Comments

@<level>: <subject>

praise: nice abstraction!
nitpick: extra newline.
suggestion: extract to helper.
issue: null pointer possible.
question: why X?
todo: handle error case.
chore: rebase main.

→ 명시적 + structured.

Approval criteria

Don't block on:
- Subjective style.
- Out of scope.
- Future improvement (별 PR).
- Opinion (vs author).

Block on:
- Bug.
- Security.
- Test missing.
- Performance regression.

"Approve with comments"

Critical 가 없 가, suggestion 만:
- Approve (merge OK).
- Comments 가 author 의 discretion.

→ Author 가 ignore OK.
Reviewer 가 trust.

Pair review (paired)

2 reviewer 가 같은 PR.
- Different perspective.
- 1 가 OK, 1 가 changes.
- Critical PR.

Review rotation

Team 의 round-robin:
- Avoid 1 사람 burnout.
- 매 사람 의 codebase 익숙.
- Knowledge spread.

→ GitHub team review (auto round-robin).

Stale PR

- 7 day no activity = warning.
- 14 day = bot reminder.
- 30 day = auto-close.

→ Backlog hygiene.

Pre-commit (catch first)

# .husky/pre-commit
npm run lint
npm run typecheck
npm test

→ Local catch = review 전.

Conventional commit

feat: add OAuth login
fix: resolve race condition in cart
chore: update dependencies
refactor: extract user service
test: add integration tests for checkout
docs: update README
perf: optimize search query

→ Auto changelog + semantic versioning.

Review templates

### Functional review
- [ ] Code does what it claims.
- [ ] Edge cases.
- [ ] Error handling.
- [ ] Performance.
- [ ] Security.

### Code quality
- [ ] Readable.
- [ ] DRY (no duplicate).
- [ ] Tests.
- [ ] Comments where needed.

Type of review

Architectural: design, structure.
Functional: behavior, correctness.
Style: format, naming.
Performance: complexity.
Security: vuln.

→ 매 PR 의 focus 따라.

Reviewer fatigue

1 일 5+ PR = quality ↓.

→ Limit. Pair.

LLM-assisted human review

Cursor / Copilot 가:
- Diff summary.
- Specific concern (security, perf).
- Refactor suggestion.

→ Human 가 critical 만 + LLM 가 noise.

Code review 의 ROI

Pros:
- Bug catch.
- Knowledge transfer.
- Code quality.
- Mentor.

Cons:
- Time (1 hour / day / dev).
- Bottleneck.
- Conflict.

→ Process 의 efficiency 가 key.

Pair programming (review alternative)

2 사람 가 real-time:
- 매 commit 가 already reviewed.
- 빠른 feedback.
- 작은 work 의 sweet.

→ Critical / 어려운 task 만.

Review metric

- Time to first review.
- Iterations per PR.
- LOC per PR.
- Approval rate.
- Bug rate (post-merge).

→ DORA-style metric.

→ Quality_Engineering_Excellence.

Tools (modern)

- GitHub PR (default).
- Reviewable / Pull Reviewers (3rd party).
- CodeRabbit / Greptile (AI).
- Graphite (stack-based PR).
- Sapling (Meta).

Stack-based PR (Graphite)

1 feature = 5 작은 PR (stack).
- 매 PR = 작은.
- Sequential merge.
- Big feature = manageable.

→ 큰 feature 의 답.

Best practice

1. Self-review 먼저.
2. Small PR (<400 LOC).
3. PR description 의 why.
4. AI assist (CodeRabbit).
5. Async + threaded comment.
6. Conventional comments.
7. Approve with comments OK.
8. Don't block on opinion.

🤔 의사결정 기준

작업	추천
AI first-pass	CodeRabbit / Greptile
Small PR	< 400 LOC
Big feature	Stack (Graphite)
Critical	Pair review
Fast feedback	Pair programming
Async team	Threaded comment

❌ 안티패턴

• Big PR (1000+): slow review.
• No description: 시간 낭비.
• Block on opinion: morale.
• Personal attack: blameless.
• No SLA: lead time ↑.
• Manual everything: AI 의 가치.

🤖 LLM 활용 힌트

• AI review (CodeRabbit) 가 first-pass.
• Small PR + async + blameless.
• Conventional comments 가 structured.
• DORA metric 의 lead time.

🔗 관련 문서

• Productivity_Code_Review
• Productivity_PR_Template
• Quality_Code_Ownership_CODEOWNERS