Code Review 영어 표현 완벽 가이드 — PR 리뷰에서 바로 쓰는 실전 표현 100+

# 명확한 변경 요청
- "Please rename this variable to something more descriptive."
- "This should be extracted into a separate function."
- "We need to add error handling here."
- "Please add a comment explaining why this is necessary."
- "This constant should be defined at the module level."

# "I wonder..." 패턴 — 부드럽게 제안
- "I wonder if we could simplify this by using a list comprehension."
- "I wonder if this would be clearer as a named function."

# "What do you think about..." 패턴
- "What do you think about extracting this into a helper function?"
- "What do you think about using a dataclass here instead?"

# "Consider..." 패턴
- "Consider using `defaultdict` here to avoid the key check."
- "Consider adding a timeout to this HTTP call."

# "It might be worth..." 패턴
- "It might be worth adding a docstring to this class."
- "It might be worth caching this result since it's called frequently."

# 사소한 것은 "nit:" 접두사로 표시 (non-blocking)
- "nit: trailing whitespace on line 42"
- "nit: this could be a one-liner: `return x if x > 0 else 0`"
- "nit: inconsistent naming — other functions use snake_case"
- "nit: missing newline at end of file"

# 왜 이렇게 했는지 물을 때
- "Could you explain why we need this check here?"
- "What's the reasoning behind using a raw SQL query instead of the ORM?"
- "Is there a specific reason for choosing `threading` over `asyncio`?"
- "I'm curious — why did you go with this approach?"

# 코드가 어떻게 동작하는지 확인할 때
- "What happens if `user` is None here?"
- "How does this behave when the list is empty?"
- "Does this handle the case where the API returns a 429?"
- "Will this work correctly with concurrent requests?"

# 테스트 관련 질문
- "Do we have test coverage for the error path?"
- "Have you considered adding a test for the edge case where input is empty?"
- "How was this tested? I couldn't find a corresponding test file."
- "Could you add a regression test for this fix?"

# 구체적으로 칭찬하기 (구체적일수록 좋음)
- "Nice refactoring! This is much more readable now."
- "Great use of the Strategy pattern here."
- "Love the comprehensive error handling."
- "This is a really elegant solution. Well done!"
- "Excellent test coverage — especially the edge cases."
- "Good catch on that race condition!"
- "TIL about this API — thanks for introducing it!"
- "This abstraction is going to save us a lot of time."

# 코드와 함께 대안을 제시하는 예시

# 기존 코드:
# for item in items:
#     if item.status == 'active':
#         result.append(item.name)

# 리뷰 코멘트:
# "We could simplify this with a list comprehension:
# `result = [item.name for item in items if item.status == 'active']`"

# 대안 제시 표현들
- "An alternative approach would be to use..."
- "You might want to look into using X instead."
- "One option is to..., which would give us..."
- "Have you considered using X? It handles Y automatically."
- "A simpler way to achieve this would be..."

# 성능 이슈 지적
- "This creates a new list on every iteration. Consider moving it outside the loop."
- "This O(n²) approach might be slow for large datasets. A set-based lookup would be O(n)."
- "We should use `str.join()` instead of string concatenation in a loop."

# 안전성 이슈 지적
- "This looks like it could be vulnerable to SQL injection."
- "We should validate the input before passing it to the shell command."
- "This secret should not be hardcoded — let's use environment variables."

# LGTM (Looks Good To Me) 변형들
- "LGTM! 🚀"
- "LGTM — just one minor nit, but nothing blocking."
- "Looks good to me! Nice work."
- "Approved! Clean implementation."
- "LGTM with the suggested change. Feel free to merge after."
- "Ship it! 🛳️"

# 조건부 승인
- "LGTM once the test is added."
- "Approved with minor suggestions — up to you whether to address them."
- "Looks good overall. Just the one blocking comment about error handling."

# 코드 리뷰에서 자주 쓰이는 약어
LGTM  = Looks Good To Me (승인)
PTAL  = Please Take A Look (리뷰 요청)
WIP   = Work In Progress (작업 중)
RFC   = Request For Comments (의견 요청)
TIL   = Today I Learned (오늘 배운 것)
IIRC  = If I Remember/Recall Correctly (기억이 맞다면)
AFAIK = As Far As I Know (내가 알기로는)
IMO   = In My Opinion (내 의견으로는)
IMHO  = In My Humble Opinion (겸손한 의견으로는)
FYI   = For Your Information (참고로)
WDYT  = What Do You Think? (어떻게 생각해?)
ACK   = Acknowledged (확인함)
NACK  = Negative Acknowledgment (반대)

# Conventional Commits 스타일
feat: add user authentication via OAuth2
fix: resolve race condition in cache invalidation
refactor: extract payment logic into separate service
docs: update API documentation for v2 endpoints
perf: optimize database queries for user dashboard
test: add integration tests for payment flow
chore: upgrade dependencies to latest versions

## What

Brief description of what this PR does.

## Why

Explain the motivation. Link to issue/ticket if applicable.

## How

Describe the approach taken and any important design decisions.

## Testing

- [ ] Unit tests added/updated
- [ ] Integration tests pass
- [ ] Manual testing done (describe what was tested)

## Screenshots (if applicable)

Before / After screenshots for UI changes.

## Notes for Reviewers

Any specific areas where you'd like focused feedback.

# 정중하게 반대 의견 표현
- "I see your point, but I think X might be more appropriate here because..."
- "I respectfully disagree — here's my reasoning: ..."
- "That's a valid approach, but I have concerns about..."
- "I understand the trade-off. Let me explain why I went this route..."

# 솔직하게 모른다고 할 때
- "I'm not familiar with this pattern — could you point me to a reference?"
- "I'm not sure I understand this part. Could you walk me through it?"
- "This is a bit over my head. Can you add a comment explaining the logic?"

# 리뷰 지연에 대해
- "Sorry for the delayed review — I'll take a look today."
- "Apologies, this slipped through my notifications. Reviewing now."
- "I need a bit more time to review this thoroughly. ETA: tomorrow morning."

# 리뷰 대상 코드:
def get_user(user_id):
    response = requests.get(f"https://api.example.com/users/{user_id}")
    return response.json()["data"]

# 좋은 리뷰 코멘트:
"What happens if the API returns a non-200 status code?
We should add error handling here. Something like:

response.raise_for_status()  # Raises HTTPError for 4xx/5xx

Also, `response.json()["data"]` will raise a KeyError
if the response doesn't contain a "data" field.
Consider using `.get("data")` with a sensible default."

# 리뷰 대상 코드:
def find_duplicates(items):
    duplicates = []
    for i in range(len(items)):
        for j in range(i + 1, len(items)):
            if items[i] == items[j] and items[i] not in duplicates:
                duplicates.append(items[i])
    return duplicates

# 좋은 리뷰 코멘트:
"This has O(n²) time complexity, which could be a problem
for large lists. Here's a more efficient approach using
Counter from collections:

from collections import Counter
def find_duplicates(items):
    return [item for item, count in Counter(items).items() if count > 1]

This runs in O(n) time. WDYT?"