-
🏆 1. 칭찬할 때 (Giving Positive Feedback)
-
✅ "This is a clean implementation!"→ "코드 깔끔하게 잘 짰네!"
-
✅ "I like how you structured this."→ "코드 구조가 마음에 들어."
-
✅ "Nice use of [X]."→ "[X]를 잘 활용했네!"
-
⚡ 2. 개선점 제안할 때 (Suggesting Improvements)
-
✅ "Have you considered using [X] instead?"→ "[X]를 대신 쓰는 걸 고려해봤어?"
-
✅ "What do you think about breaking this into smaller functions?"→ "이거 함수를 더 잘게 나누는 건 어때?"
-
✅ "I think this could be optimized by …"→ "이거 … 방식으로 최적화할 수 있을 것 같아."
-
✅ "This logic seems a bit complex. Can we simplify it?"→ "이 로직이 좀 복잡한데, 더 단순하게 만들 수 있을까?"
-
📌 3. 요청할 때 (Making Requests)
-
✅ "Could you add a test case for this?"→ "이거 테스트 케이스 추가해줄 수 있어?"
-
✅ "Can you add a comment here for clarity?"→ "여기에 설명 주석 추가해줄래?"
-
✅ "Please refactor this part to improve readability."→ "이 부분 가독성을 위해 리팩토링해줘."
🏆 1. 칭찬할 때 (Giving Positive Feedback)
✅ "This is a clean implementation!"→ "코드 깔끔하게 잘 짰네!"
🔹 예문:
// PR에서 한 동료가 잘 정리된 유틸리티 함수를 작성했을 때
/**
* Formats a date string to 'YYYY-MM-DD'
*/
function formatDate(date) {
return date.toISOString().split('T')[0];
}
💬 "This is a clean implementation! Simple and easy to read."
✅ "I like how you structured this."→ "코드 구조가 마음에 들어."
🔹 예문:
class UserService {
constructor(private userRepository: UserRepository) {}
async getUserById(id: string) {
return this.userRepository.findById(id);
}
}
💬 "I like how you structured this! Separating concerns with a repository pattern makes the code more maintainable."
✅ "Nice use of [X]."→ "[X]를 잘 활용했네!"
🔹 예문:
// React에서 useMemo를 적절히 사용한 경우
const sortedUsers = useMemo(() => {
return users.sort((a, b) => a.name.localeCompare(b.name));
}, [users]);
💬 "Nice use of useMemo! This avoids unnecessary re-renders."
⚡ 2. 개선점 제안할 때 (Suggesting Improvements)
리뷰할 때는 단순히 "이거 고쳐"가 아니라 "이렇게 하면 더 좋을 것 같아"라는 톤이 중요
✅ "Have you considered using [X] instead?"→ "[X]를 대신 쓰는 걸 고려해봤어?"
🔹 예문:
# for loop을 쓰고 있는데 list comprehension이 더 적절한 경우
result = []
for num in numbers:
if num > 10:
result.append(num)
💬 "Have you considered using list comprehension instead? It might make the code more concise."
result = [num for num in numbers if num > 10]
✅ "What do you think about breaking this into smaller functions?"→ "이거 함수를 더 잘게 나누는 건 어때?"
🔹 예문:
// 긴 함수가 있어서 가독성이 떨어지는 경우
public void processOrder(Order order) {
validateOrder(order);
applyDiscount(order);
updateStock(order);
notifyCustomer(order);
}
💬 "What do you think about breaking this into smaller functions? It might improve readability."
✅ 리팩토링 후
public void processOrder(Order order) {
validateOrder(order);
processPayment(order);
finalizeOrder(order);
}
✅ "I think this could be optimized by …"→ "이거 … 방식으로 최적화할 수 있을 것 같아."
🔹 예문:
// 불필요한 `.map()`과 `.filter()` 중첩 사용
const activeUserNames = users
.filter(user => user.isActive)
.map(user => user.name);
💬 "I think this could be optimized by using reduce() to avoid multiple iterations."
const activeUserNames = users.reduce((acc, user) => {
if (user.isActive) acc.push(user.name);
return acc;
}, []);
✅ "This logic seems a bit complex. Can we simplify it?"→ "이 로직이 좀 복잡한데, 더 단순하게 만들 수 있을까?"
🔹 예문:
// 너무 복잡한 조건문
if ((user.Role == "Admin" || user.Role == "SuperAdmin") && user.IsActive && !user.IsBanned) {
grantAccess();
}
💬 "This logic seems a bit complex. Can we simplify it by using an early return?"
if (user.IsBanned || !user.IsActive) return;
if (user.Role == "Admin" || user.Role == "SuperAdmin") grantAccess();
→ 이렇게 하면 훨씬 읽기 쉽고 유지보수도 편해짐!
📌 3. 요청할 때 (Making Requests)
✅ "Could you add a test case for this?"→ "이거 테스트 케이스 추가해줄 수 있어?"
🔹 예문:
# 새로운 기능을 추가했는데 테스트 코드가 없음
def calculate_discount(price, discount_rate):
return price * (1 - discount_rate)
💬 "Could you add a test case for this? We should cover edge cases like a 0% or 100% discount."
✅ 추가된 테스트 코드
def test_calculate_discount():
assert calculate_discount(100, 0) == 100
assert calculate_discount(100, 1) == 0
✅ "Can you add a comment here for clarity?"→ "여기에 설명 주석 추가해줄래?"
🔹 예문:
// 복잡한 로직이 포함된 코드
func processTransaction(amount: Double, fee: Double) -> Double {
return (amount - fee) * 1.05
}
💬 "Can you add a comment here for clarity? It's not obvious why we're multiplying by 1.05."
// 5% 세금 추가
func processTransaction(amount: Double, fee: Double) -> Double {
return (amount - fee) * 1.05
}
→ 설명이 추가되면 리뷰어도 이해하기 쉬움!
✅ "Please refactor this part to improve readability."→ "이 부분 가독성을 위해 리팩토링해줘."
🔹 예문:
// 너무 긴 한 줄 코드
const result = data.map(d => d.value * 2).filter(v => v > 10).sort((a, b) => a - b);
💬 "Please refactor this part to improve readability. Maybe break it into multiple steps?"
const doubledValues = data.map(d => d.value * 2);
const filteredValues = doubledValues.filter(v => v > 10);
const sortedValues = filteredValues.sort((a, b) => a - b);
→ 이렇게 하면 유지보수할 때도 더 편리함!
🏆 1. 칭찬할 때 (Giving Positive Feedback)
✅ "This is a clean implementation!"→ "코드 깔끔하게 잘 짰네!"
🔹 예문:
// PR에서 한 동료가 잘 정리된 유틸리티 함수를 작성했을 때
/**
* Formats a date string to 'YYYY-MM-DD'
*/
function formatDate(date) {
return date.toISOString().split('T')[0];
}
💬 "This is a clean implementation! Simple and easy to read."
✅ "I like how you structured this."→ "코드 구조가 마음에 들어."
🔹 예문:
class UserService {
constructor(private userRepository: UserRepository) {}
async getUserById(id: string) {
return this.userRepository.findById(id);
}
}
💬 "I like how you structured this! Separating concerns with a repository pattern makes the code more maintainable."
✅ "Nice use of [X]."→ "[X]를 잘 활용했네!"
🔹 예문:
// React에서 useMemo를 적절히 사용한 경우
const sortedUsers = useMemo(() => {
return users.sort((a, b) => a.name.localeCompare(b.name));
}, [users]);
💬 "Nice use of useMemo! This avoids unnecessary re-renders."
⚡ 2. 개선점 제안할 때 (Suggesting Improvements)
리뷰할 때는 단순히 "이거 고쳐"가 아니라 "이렇게 하면 더 좋을 것 같아"라는 톤이 중요
✅ "Have you considered using [X] instead?"→ "[X]를 대신 쓰는 걸 고려해봤어?"
🔹 예문:
# for loop을 쓰고 있는데 list comprehension이 더 적절한 경우
result = []
for num in numbers:
if num > 10:
result.append(num)
💬 "Have you considered using list comprehension instead? It might make the code more concise."
result = [num for num in numbers if num > 10]
✅ "What do you think about breaking this into smaller functions?"→ "이거 함수를 더 잘게 나누는 건 어때?"
🔹 예문:
// 긴 함수가 있어서 가독성이 떨어지는 경우
public void processOrder(Order order) {
validateOrder(order);
applyDiscount(order);
updateStock(order);
notifyCustomer(order);
}
💬 "What do you think about breaking this into smaller functions? It might improve readability."
✅ 리팩토링 후
public void processOrder(Order order) {
validateOrder(order);
processPayment(order);
finalizeOrder(order);
}
✅ "I think this could be optimized by …"→ "이거 … 방식으로 최적화할 수 있을 것 같아."
🔹 예문:
// 불필요한 `.map()`과 `.filter()` 중첩 사용
const activeUserNames = users
.filter(user => user.isActive)
.map(user => user.name);
💬 "I think this could be optimized by using reduce() to avoid multiple iterations."
const activeUserNames = users.reduce((acc, user) => {
if (user.isActive) acc.push(user.name);
return acc;
}, []);
✅ "This logic seems a bit complex. Can we simplify it?"→ "이 로직이 좀 복잡한데, 더 단순하게 만들 수 있을까?"
🔹 예문:
// 너무 복잡한 조건문
if ((user.Role == "Admin" || user.Role == "SuperAdmin") && user.IsActive && !user.IsBanned) {
grantAccess();
}
💬 "This logic seems a bit complex. Can we simplify it by using an early return?"
if (user.IsBanned || !user.IsActive) return;
if (user.Role == "Admin" || user.Role == "SuperAdmin") grantAccess();
→ 이렇게 하면 훨씬 읽기 쉽고 유지보수도 편해짐!
📌 3. 요청할 때 (Making Requests)
✅ "Could you add a test case for this?"→ "이거 테스트 케이스 추가해줄 수 있어?"
🔹 예문:
# 새로운 기능을 추가했는데 테스트 코드가 없음
def calculate_discount(price, discount_rate):
return price * (1 - discount_rate)
💬 "Could you add a test case for this? We should cover edge cases like a 0% or 100% discount."
✅ 추가된 테스트 코드
def test_calculate_discount():
assert calculate_discount(100, 0) == 100
assert calculate_discount(100, 1) == 0
✅ "Can you add a comment here for clarity?"→ "여기에 설명 주석 추가해줄래?"
🔹 예문:
// 복잡한 로직이 포함된 코드
func processTransaction(amount: Double, fee: Double) -> Double {
return (amount - fee) * 1.05
}
💬 "Can you add a comment here for clarity? It's not obvious why we're multiplying by 1.05."
// 5% 세금 추가
func processTransaction(amount: Double, fee: Double) -> Double {
return (amount - fee) * 1.05
}
→ 설명이 추가되면 리뷰어도 이해하기 쉬움!
✅ "Please refactor this part to improve readability."→ "이 부분 가독성을 위해 리팩토링해줘."
🔹 예문:
// 너무 긴 한 줄 코드
const result = data.map(d => d.value * 2).filter(v => v > 10).sort((a, b) => a - b);
💬 "Please refactor this part to improve readability. Maybe break it into multiple steps?"
const doubledValues = data.map(d => d.value * 2);
const filteredValues = doubledValues.filter(v => v > 10);
const sortedValues = filteredValues.sort((a, b) => a - b);
→ 이렇게 하면 유지보수할 때도 더 편리함!