Login

Code review hiệu quả: cách làm người review tử tế và có giá trị

  • author-image

    Nguyễn Đình Cường

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

Code review là hoạt động mà một đồng đội đọc code của bạn trước khi gộp vào dự án. Làm tốt, nó nâng chất lượng code và giúp cả nhóm học hỏi lẫn nhau. Làm kém, nó thành nơi tranh cãi hoặc chỉ là thủ tục "LGTM" cho xong. Bài này nói về vai trò của người review.

Mục tiêu thực sự của code review

  • Bắt lỗi sớm: logic sai, thiếu xử lý ngoại lệ, vấn đề bảo mật.
  • Giữ code dễ đọc, dễ bảo trì theo chuẩn chung của nhóm.
  • Chia sẻ kiến thức: người review hiểu thêm về phần code mới, tác giả học thêm cách làm tốt.
  • Đảm bảo thay đổi đúng yêu cầu và không gây ảnh hưởng ngoài ý muốn.

Mục tiêu không phải chứng minh ai giỏi hơn ai, cũng không phải bắt lỗi chính tả để thể hiện.

Nên kiểm tra những gì (theo thứ tự ưu tiên)

  1. Thiết kế và ý đồ: thay đổi này có giải quyết đúng vấn đề không? Cách tiếp cận có hợp lý, có đi lệch kiến trúc chung không?
  2. Tính đúng đắn: logic có xử lý được các trường hợp biên (rỗng, null, số âm, đồng thời)? Có lỗi off-by-one không?
  3. Bảo mật và dữ liệu: có kiểm tra đầu vào, chống SQL injection, XSS? Có lộ khóa bí mật trong code?
  4. Test: có test cho hành vi mới không? Test có kiểm tra điều quan trọng thực sự?
  5. Dễ đọc và bảo trì: tên rõ nghĩa, hàm gọn, không lặp lại thừa, comment giải thích được "vì sao".
  6. Hiệu năng (khi liên quan): truy vấn N+1, vòng lặp lồng nhau trên dữ liệu lớn.
  7. Phong cách và định dạng: ưu tiên giao cho formatter và linter làm tự động, đừng mất công người.

Cách viết nhận xét tốt

Cùng một ý, cách nói khác nhau tạo ra phản ứng hoàn toàn khác:

Kém hiệu quảTốt hơn
"Code này tệ quá.""Đoạn này khá dài, bạn thử tách phần tính phí ra hàm riêng được không? Sẽ dễ test hơn."
"Sao lại làm thế này?""Mình chưa rõ lý do chọn cách này. Bạn giải thích giúp để mình hiểu thêm nhé?"
"Sai rồi.""Nếu danh sách rỗng thì dòng 42 sẽ ném lỗi. Bạn kiểm tra thêm trường hợp này nhé."
  • Nhận xét về code, không về con người. Dùng "đoạn code này", thay vì "bạn viết ẩu".
  • Đặt câu hỏi thay vì ra lệnh khi chưa chắc: "Có phải ... không?"
  • Giải thích lý do và, nếu được, gợi ý cách sửa hoặc đoạn code mẫu.
  • Phân loại mức độ: ghi rõ đâu là bắt buộc sửa, đâu là gợi ý (đánh dấu "nit:" hoặc "optional:").
  • Khen những điều làm tốt. Review không chỉ để tìm lỗi.

Thói quen tốt của người review

  1. Review nhanh: đừng để pull request chờ nhiều ngày, nó chặn công việc của đồng đội. Cố gắng phản hồi trong vòng một ngày làm việc.
  2. Đọc mô tả trước, đọc code sau: hiểu bối cảnh rồi mới đánh giá chi tiết.
  3. Review theo từng phần nhỏ: thay đổi quá lớn (vài nghìn dòng) hãy đề nghị tác giả chia nhỏ.
  4. Chạy thử khi cần: với thay đổi quan trọng, kéo nhánh về chạy thật thay vì chỉ đọc.
  5. Không ôm hết: nếu thay đổi nằm ngoài chuyên môn của bạn, nhờ người phù hợp review cùng.
  6. Kết thúc rõ ràng: approve, request changes hoặc comment, đừng để lửng lơ.

Khi bất đồng ý kiến

Nếu hai bên không thống nhất, đừng cãi nhau qua hàng chục bình luận. Hãy gọi nhanh một cuộc trao đổi hoặc nói chuyện trực tiếp. Dựa vào chuẩn chung của nhóm (style guide, nguyên tắc kiến trúc) thay vì sở thích cá nhân. Nếu vấn đề chỉ là gu, hãy nhường tác giả, vì code do họ chịu trách nhiệm duy trì.

Một danh sách kiểm tra nhanh

  • Mô tả pull request nêu rõ mục đích và cách kiểm tra?
  • Thay đổi có nằm gọn trong phạm vi mô tả?
  • Test mới, test cũ đều qua?
  • Có đoạn code debug (console.log, dump) bị bỏ sót?
  • Có thông tin nhạy cảm bị commit nhầm?
  • Tài liệu và changelog đã được cập nhật nếu cần?

Kết luận

Review tốt là sự kết hợp của kỹ thuật và sự tử tế: tập trung vào những điều quan trọng, nói cụ thể, giữ thái độ tôn trọng và phản hồi nhanh. Khi nhóm có văn hóa review lành mạnh, chất lượng code và tinh thần làm việc đều đi lên.

Để luyện kỹ năng đọc và đánh giá code, bạn có thể kết hợp học các khóa trên codebem.com với việc review dự án của chính mình.

author_photo
Nguyễn Đình Cường

0 comment