Antigravity Agent
6.5 KiB
6.5 KiB
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 |
|
|
|
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.