Login

Viết pull request dễ review: mẹo để code được duyệt nhanh hơn

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Cùng một đoạn code, có pull request được duyệt trong vài giờ, có pull request nằm cả tuần với hàng chục bình luận qua lại. Sự khác biệt thường không nằm ở chất lượng code mà ở cách bạn trình bày và chia nhỏ thay đổi. Dưới đây là những mẹo giúp người review dễ làm việc hơn và giúp bạn nhận phản hồi nhanh hơn.

1. Giữ pull request nhỏ và tập trung

Đây là mẹo quan trọng nhất. Một PR vài trăm dòng thay đổi cho một mục đích duy nhất dễ review hơn rất nhiều so với PR hàng nghìn dòng đủ thứ trộn lẫn. Người review thường mất tập trung và chỉ lướt qua khi PR quá lớn, khiến lỗi lọt qua.

  • Một PR chỉ giải quyết một vấn đề hoặc một tính năng.
  • Tách riêng refactor, đổi tên, định dạng khỏi thay đổi logic.
  • Tính năng lớn thì chia thành chuỗi PR nhỏ, từng cái có thể merge độc lập.

2. Viết tiêu đề và mô tả rõ ràng

Tiêu đề nên nói được thay đổi gì, ví dụ "Thêm chức năng đặt lại mật khẩu qua email", không phải "update code" hay "fix". Phần mô tả nên có:

  1. Bối cảnh: vì sao cần thay đổi này (link issue, ticket).
  2. Nội dung thay đổi: những điểm chính, cách tiếp cận bạn chọn và lý do.
  3. Cách kiểm tra: các bước để người khác chạy thử, dữ liệu mẫu cần dùng.
  4. Ảnh chụp màn hình hoặc video ngắn nếu có thay đổi giao diện.
  5. Điều cần lưu ý: phần chưa làm, rủi ro, thay đổi cấu hình hoặc migration database.

Nhiều nhóm dùng mẫu (template) có sẵn để ai cũng điền đủ các mục này.

## Mô tảThêm chức năng đặt lại mật khẩu qua email (#128).## Thay đổi chính- Thêm route POST /password/forgot và /password/reset- Token hết hạn sau 60 phút## Cách kiểm tra1. Vào trang Quên mật khẩu, nhập email test2. Mở email, bấm link và đặt mật khẩu mới3. Đăng nhập lại bằng mật khẩu mới## Lưu ýCần chạy migration mới trước khi deploy.

3. Tự review trước khi nhờ người khác

Hãy mở chính PR của bạn và đọc diff như thể bạn là người review. Bạn sẽ bắt được nhiều lỗi vặt: code debug còn sót, comment thừa, file không liên quan bị thêm vào, tên biến chưa ổn, quên cập nhật test. Việc này tiết kiệm thời gian của cả hai bên và thể hiện sự chuyên nghiệp.

4. Đảm bảo kiểm tra tự động đã qua

Trước khi gọi người review, hãy chắc rằng test, linter và build đều xanh. Nhờ ai đó đọc code khi CI còn đỏ là phí thời gian của họ. Nếu có phần test không chạy được vì lý do chính đáng, ghi chú rõ trong mô tả.

5. Chia commit có chủ đích

Dù PR gộp lại thành một khi merge (squash), việc chia commit gọn gàng trong quá trình làm giúp người review xem theo từng bước. Mỗi commit một ý, message rõ ràng. Với PR lớn, bạn có thể gợi ý: "Nên xem theo từng commit, commit 1 là refactor, commit 2 mới là logic."

6. Chủ động chỉ ra chỗ cần chú ý

Bạn hiểu code của mình nhất, nên hãy dẫn người review đến chỗ quan trọng. Dùng bình luận ngay trong PR để chú thích: "Đoạn này mình chọn cách A vì B, bạn thấy hợp lý không?" hoặc "Phần này chưa chắc chắn, mong nhận ý kiến." Điều này giúp review tập trung vào chỗ có giá trị thay vì đoán ý bạn.

7. Phản hồi nhận xét một cách tích cực

  • Cảm ơn và xem phản hồi là cơ hội học hỏi, không phải chỉ trích cá nhân.
  • Nếu đồng ý, sửa rồi trả lời "Đã sửa" hoặc đẩy commit kèm ghi chú.
  • Nếu không đồng ý, giải thích lý do bình tĩnh và có dẫn chứng, hoặc đề nghị trao đổi trực tiếp.
  • Đừng im lặng cho đến khi bình luận bị lãng quên; đánh dấu "resolved" khi đã xử lý.
  • Khi cập nhật, ping người review biết là đã sẵn sàng xem lại.

8. Tôn trọng thời gian người review

Chọn đúng người review (người hiểu phần code đó), không gửi tràn lan cho cả nhóm. Tránh gửi PR lớn vào cuối ngày thứ Sáu. Nếu gấp, hãy nói rõ lý do và mức độ ưu tiên thay vì thúc giục chung chung. Ngược lại, khi bạn đang là người review, hãy cố gắng phản hồi trong thời gian hợp lý.

Danh sách kiểm tra trước khi mở PR

  1. PR chỉ làm một việc, kích thước vừa phải.
  2. Tiêu đề và mô tả đủ ngữ cảnh, có cách kiểm tra.
  3. Đã đọc lại diff, không còn code debug hay file thừa.
  4. Test, lint, build đều qua.
  5. Đã cập nhật tài liệu, changelog, cấu hình nếu cần.
  6. Đã gán đúng người review và nhãn (label).

Kết luận

Một pull request tốt là một món quà cho đồng đội: gọn, rõ ý định, dễ kiểm tra. Hãy đầu tư vài phút vào mô tả và tự review, bạn sẽ nhận lại phản hồi nhanh, chất lượng, và mối quan hệ tốt với cả nhóm.

Nếu bạn đang chuẩn bị bước vào môi trường làm việc nhóm, hãy tham khảo thêm các khóa học trên codebem.com để làm quen với quy trình thật.

author_photo
Nguyễn Đình Cường

0 comment