Code Review — Cho Và Nhận Feedback Như Một Senior Developer

Code review là kỹ năng kỹ thuật lẫn kỹ năng giao tiếp. Một comment viết tệ có thể gây conflict không cần thiết, trong khi comment tốt vừa cải thiện code vừa dạy được gì đó cho người được review.

Mục Đích Thực Sự Của Code Review

• Bắt bugs trước khi vào production
• Chia sẻ kiến thức trong team
• Đảm bảo consistency trong codebase
• Mentor developer junior
• KHÔNG phải để thể hiện mình thông minh hơn

Reviewer — Cách Viết Comment Hiệu Quả

# Xấu — phán xét, không giải thích
"Đây là code xấu."
"Sai rồi."
"Tại sao lại làm vậy???"

# Tốt — cụ thể, giải thích, đề xuất
"Hàm này có thể trả về None nếu list rỗng.
Xem xét thêm guard clause ở đầu hoặc trả về default value.

Ví dụ:
    if not items:
        return []
"

# Phân biệt mức độ
# 🚨 Blocking: Bug thực sự, security issue, breaking change
"🚨 SQL injection vulnerability — user_input phải được escape"

# 💡 Non-blocking: Gợi ý cải thiện, có thể làm sau
"💡 Có thể dùng list comprehension ở đây cho ngắn gọn hơn, nhưng không bắt buộc"

# ❓ Question: Tìm hiểu, không phán xét
"❓ Tại sao chọn cách này thay vì X? Muốn hiểu trade-off."

Nguyên Tắc Comment

• Comment về code, không về người: "Function này..." thay vì "Bạn đã..."
• Giải thích WHY: "X có vấn đề vì Y, hãy thử Z" — không chỉ "Sai"
• Phân biệt blocking/non-blocking: Không phải mọi comment đều phải fix trước khi merge
• Khen ngợi code tốt: Review không chỉ là chỉ lỗi

Reviewer — Checklist Khi Review

# Ưu tiên cao — luôn check
□ Logic có đúng không? (Happy path và edge cases)
□ Security: SQL injection, XSS, auth bypass?
□ Performance: N+1 queries, missing index?
□ Error handling có hợp lý không?

# Ưu tiên vừa
□ Tests đã cover cases quan trọng chưa?
□ Code có readable không?
□ Có duplicate code có thể refactor không?

# Nice-to-have
□ Style/convention nhất quán?
□ Comments/docstring có hữu ích không?

Author — Cách Tiếp Nhận Feedback

# Khi nhận comment:
# ✓ Đọc và hiểu trước khi phản hồi
# ✓ Nếu đồng ý: fix và reply "Done" hoặc "Fixed in latest commit"
# ✓ Nếu không đồng ý: giải thích reasoning, không defensive

# Xấu
"Cách tôi làm đúng rồi, không cần sửa."

# Tốt
"Tôi hiểu concern của bạn. Tôi chọn cách này vì [lý do cụ thể].
Bạn thấy cách X có ưu điểm gì trong trường hợp này không?
Nếu thuyết phục tôi sẽ sửa."

Review Nhanh Và Hiệu Quả

• PR nhỏ: <400 dòng thay đổi — dễ review hơn, ít bugs hơn
• Description rõ ràng: PR description giải thích WHY, không phải WHAT
• Self-review trước: Author đọc lại diff của mình trước khi assign reviewer
• Respond nhanh: Review trong 24h — không để block người khác

Code review tốt nhất là khi cả reviewer lẫn author đều học được gì đó. Reviewer học cách tác giả giải quyết vấn đề; tác giả học perspective mới từ reviewer.

Kết Luận

Code review là investment vào chất lượng dài hạn và văn hóa team. Bắt đầu bằng việc nhớ một nguyên tắc: comment về code, không về người. Phần còn lại sẽ tự nhiên tốt hơn theo thời gian.