Login

Xây dựng văn hóa code review thân thiện: góp ý thế nào để không làm mất lòng nhau

  • author-image

    Nguyễn Đình Cường

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

Code review có thể là nơi học hỏi tuyệt vời, cũng có thể là nơi sinh ra căng thẳng nếu góp ý thiếu tế nhị. Văn hóa review lành mạnh giúp đội nâng chất lượng mà vẫn giữ được sự tin tưởng giữa các thành viên.

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

  • Phát hiện lỗi và rủi ro trước khi code vào sản phẩm.
  • Giữ code dễ đọc, nhất quán và dễ bảo trì.
  • Chia sẻ kiến thức về hệ thống.
  • Học hỏi lẫn nhau, cả người review lẫn người được review.

Review không phải là cơ hội để chứng tỏ ai giỏi hơn.

Khi bạn là người góp ý

  1. Nhận xét code, không nhận xét con người. Nói "đoạn này có thể khó đọc" thay vì "bạn viết cẩu thả".
  2. Giải thích lý do. Một góp ý kèm lý do và ví dụ có giá trị hơn một mệnh lệnh.
  3. Phân biệt mức độ. Ghi rõ đâu là điều bắt buộc sửa, đâu là gợi ý tùy chọn.
  4. Hỏi thay vì khẳng định khi bạn chưa chắc: "Mình thắc mắc vì sao chọn cách này, có lý do đặc biệt không?".
  5. Khen điều tốt. Ghi nhận một cách giải quyết hay giúp người viết có thêm động lực.
  6. Tập trung vào điều quan trọng: logic, bảo mật, hiệu năng, kiểm thử. Để máy móc kiểm tra định dạng.

Khi bạn là người được review

  • Giữ pull request nhỏ, mô tả rõ mục đích và cách kiểm tra.
  • Tự review trước khi gửi, dò lại các dòng thừa, ghi chú tạm.
  • Xem góp ý là cơ hội học, không phải sự tấn công.
  • Hỏi lại nếu chưa hiểu thay vì đoán.
  • Nếu không đồng ý, trao đổi bằng lý lẽ, và sẵn sàng chấp nhận nếu bị thuyết phục.
  • Cảm ơn người đã bỏ thời gian đọc code của bạn.

Ví dụ góp ý tốt và chưa tốt

Chưa tốtTốt hơn
Tên biến này dở quá.Tên biến d chưa nói rõ ý nghĩa, thử đổi thành daysUntilExpire được không?
Sao lại viết thế này?Mình chưa rõ lý do viết cách này, bạn giải thích giúp mình để mình học thêm nhé.
Sửa đi.Đoạn này có thể lỗi khi danh sách rỗng, bạn thêm kiểm tra giúp mình nhé.

Quy ước của đội

  • Thống nhất tiêu chuẩn chung về định dạng, đặt tên, kiểm thử, tốt nhất ghi lại thành tài liệu.
  • Dùng công cụ tự động để kiểm tra định dạng và lỗi cơ bản.
  • Đặt kỳ vọng về thời gian phản hồi, ví dụ trong ngày làm việc kế tiếp.
  • Giới hạn kích thước pull request để dễ review.
  • Coi review là việc của cả đội, không chỉ vài người senior.

Khi review trở nên căng thẳng

Nếu cuộc tranh luận trong bình luận kéo dài quá hai ba lượt, hãy chuyển sang gọi nhanh hoặc nói chuyện trực tiếp. Văn bản dễ bị hiểu sai giọng điệu. Sau đó tóm tắt lại kết luận trong pull request để mọi người nắm.

Người mới có nên review không

Có. Dù chưa giỏi, bạn vẫn đặt được câu hỏi hay và qua việc đọc code người khác, bạn học được rất nhiều. Hãy hỏi những gì bạn chưa hiểu, đó cũng là dấu hiệu code có thể cần rõ ràng hơn.

Danh sách kiểm tra khi review

  • Code có làm đúng điều mô tả trong yêu cầu không?
  • Có trường hợp biên nào chưa xử lý, như dữ liệu rỗng, rất lớn hay không hợp lệ?
  • Có rủi ro bảo mật, như đưa dữ liệu người dùng vào truy vấn mà không xử lý?
  • Tên biến, hàm có rõ nghĩa và nhất quán không?
  • Có kiểm thử tương ứng không, và kiểm thử có thực sự kiểm tra hành vi?
  • Thay đổi có quá lớn và nên tách nhỏ không?

Một danh sách như vậy giúp review có hệ thống, tránh sa vào chi tiết nhỏ mà bỏ sót vấn đề lớn. Đội nên điều chỉnh danh sách theo đặc thù dự án của mình.

Tự động hóa những phần máy làm tốt hơn

Hãy dùng công cụ định dạng mã, kiểm tra phong cách và chạy kiểm thử tự động trước khi người thật review. Khi máy lo phần mệt mỏi, người review có thể tập trung vào thiết kế, logic và bảo mật. Điều này cũng giảm tranh cãi về sở thích cá nhân như thụt lề hay dấu ngoặc.

Kết luận: văn hóa review tốt được xây từng góp ý một. Hãy giữ sự tôn trọng, rõ ràng và biết ơn trong mỗi bình luận.

Hãy rèn nền tảng viết code sạch cùng các khóa học tại codebem.com để tự tin hơn khi tham gia review.

author_photo
Nguyễn Đình Cường

0 comment