# Code review: cách viết comment để PR được sửa nhanh mà không ai tự ái

- URL: https://dramacongty.com/bai-viet/code-review-cach-viet-comment-de-pr-duoc-sua-nhanh-10
- Chủ đề: Tech
- Tác giả: Drama Công Ty (@dramacongty, tài khoản chính thức của Drama Công Ty)
- Ngày đăng: 2026-10-08
- Thẻ: code-review, teamwork, git
- Lượt thích: 1

Một comment "sai rồi" có thể khiến PR nằm đó ba ngày. Một comment rõ ràng giúp người viết sửa trong mười phút. Khác biệt thường nằm ở cách viết, không phải ở kiến thức.

## Khi review

- **Nói rõ mức độ**: đánh dấu "chặn merge", "nên sửa", hay "gợi ý, tuỳ bạn". Nhiều team dùng tiền tố như `blocking:`, `nit:`, `question:`.
- **Giải thích vì sao**, không chỉ cái gì: "Hàm này gọi API trong vòng lặp, 100 item là 100 request" hữu ích hơn "đừng làm vậy".
- **Hỏi khi không chắc**: "Mình hiểu là case rỗng sẽ trả null, đúng không?" mở được cuộc nói chuyện mà không đổ lỗi.
- **Nói về code, không nói về người**: "đoạn này khó đọc" thay vì "bạn viết khó đọc".
- **Khen chỗ đáng khen**. Một dòng "cách tách hàm này gọn quá" không tốn gì.
- Vấn đề lớn về hướng thiết kế: nói chuyện trực tiếp hoặc gọi ngắn, đừng để 30 comment qua lại.

## Khi gửi PR

- PR nhỏ, một mục đích. 200 dòng được review kỹ; 2.000 dòng thường chỉ được "LGTM".
- Mô tả: làm gì, vì sao, đã test thế nào, chỗ nào muốn người review nhìn kỹ.
- Tự review diff một lượt trước khi gửi: bạn sẽ tự bắt được một nửa số lỗi.

Comment review nào bạn nhớ nhất, theo nghĩa tốt hay xấu? Và team bạn có quy ước gì hay không?

---

Nguồn: Drama Công Ty (https://dramacongty.com), nơi người đi làm Việt Nam kể ẩn danh chuyện công ty. Nội dung là trải nghiệm cá nhân của thành viên, chưa được kiểm chứng; khi trích dẫn, ghi rõ nguồn và link bài.