Code review hiệu quả: cách làm đúng cho cả đội
Code review đúng cách giúp đội bắt lỗi sớm, lan truyền kiến thức và giữ codebase nhất quán. Làm sai, nó biến thành nơi tranh cãi cái tôi và làm chậm mọi pull request. Bài này chỉ cho bạn cách review có trọng tâm, góp ý không gây căng thẳng, và một checklist dùng được ngay.
Code review là gì và vì sao dễ đi chệch hướng
Code review là việc một hoặc vài người đọc thay đổi của người khác trước khi merge. Mục tiêu thật sự không phải “bắt lỗi” mà là bảo đảm thay đổi đó đúng, dễ bảo trì và cả đội hiểu được nó.
Nó đi chệch hướng khi người review sa vào chuyện nhỏ (đặt tên biến, dấu cách) mà bỏ qua logic sai, hoặc khi góp ý mang giọng phán xét. Kết quả là pull request treo nhiều ngày và người viết cảm thấy bị soi.
Chuẩn bị trước khi review
Người viết code
PR nhỏ được review kỹ hơn PR lớn. Một thay đổi dưới khoảng 200-400 dòng thường nhận phản hồi chất lượng; PR nghìn dòng chỉ nhận được “LGTM” cho có. Trước khi gửi, hãy tự review một lượt, viết mô tả ngắn nêu “làm gì, vì sao, đã test thế nào”, và tách phần refactor ra khỏi phần thêm tính năng.
Người review
Đọc mô tả và issue trước khi đọc code. Hiểu ý định giúp bạn đánh giá liệu cách giải quyết có hợp lý, thay vì chỉ soi từng dòng rời rạc.
Review cái gì: thứ tự ưu tiên
Đừng review dàn trải. Đi từ quan trọng xuống chi tiết:
| Mức | Cần kiểm tra |
| Đúng đắn | Logic có giải quyết đúng vấn đề? Có bỏ sót trường hợp biên, lỗi null, race condition? |
| Thiết kế | Cách chia hàm, phụ thuộc, đặt code đúng chỗ chưa? Có làm phức tạp hơn mức cần? |
| An toàn & dữ liệu | Có lộ input chưa kiểm tra, rò rỉ thông tin, hay thao tác dữ liệu thiếu kiểm soát? |
| Test | Có test cho phần logic mới? Test có thật sự kiểm tra hành vi, hay chỉ chạy cho đủ? |
| Rõ ràng | Tên gọi, comment chỗ khó, khả năng đọc lại sau 6 tháng. |
Chuyện định dạng và style nên để linter và formatter tự động lo, đừng tốn thời gian con người vào đó.
Cách góp ý để không gây căng thẳng
Góp ý về code, không về người. Thay vì “sao lại viết thế này”, hãy hỏi “chỗ này nếu input rỗng thì xử lý ra sao?”. Nêu lý do đằng sau đề xuất, vì một góp ý có lý do dễ được chấp nhận hơn một mệnh lệnh.
Phân biệt rõ mức độ: cái nào là điều kiện bắt buộc để merge, cái nào chỉ là gợi ý tùy chọn. Nhiều đội đánh dấu góp ý tùy chọn bằng tiền tố như “nit:” để người viết biết có thể bỏ qua.
Ví dụ thực tế
Một PR thêm chức năng tìm kiếm. Reviewer thấy hàm gọi thẳng câu truy vấn ghép chuỗi từ input người dùng. Thay vì viết “code này nguy hiểm”, họ để lại: “Chuỗi tìm kiếm ghép trực tiếp vào query có thể mở đường cho SQL injection. Mình nên dùng tham số hóa (parameterized query). Chỗ khác trong repo đang làm vậy ở file người dùng, tham khảo được.” Góp ý này nêu rủi ro cụ thể, đề xuất giải pháp, và chỉ chỗ tham khảo. Người viết sửa trong mười phút, không ai mất mặt.
Sai lầm thường gặp và cách sửa
Review PR quá lớn. Não người không giữ nổi hàng nghìn dòng cùng lúc nên bỏ sót lỗi thật. Cách sửa: yêu cầu tách PR, hoặc thỏa thuận giới hạn kích thước.
Chỉ soi style, bỏ qua logic. Cách sửa: giao style cho công cụ tự động, dành mắt người cho tính đúng và thiết kế.
Để PR treo nhiều ngày. Chờ lâu làm nghẽn cả đội và khiến code lỗi thời. Cách sửa: đặt kỳ vọng phản hồi trong ngày làm việc, coi review là ưu tiên chứ không phải việc làm khi rảnh.
Duyệt cho xong (“rubber stamp”). Approve mà không đọc kỹ khiến review vô nghĩa. Cách sửa: nếu không có thời gian đọc tử tế, nói thẳng để người khác nhận.
Checklist trước khi bấm approve
- Mình đã hiểu ý định của thay đổi này?
- Logic có xử lý trường hợp biên và lỗi không?
- Có rủi ro bảo mật hoặc dữ liệu nào không?
- Có test cho phần logic mới và test có ý nghĩa không?
- Tên gọi và cấu trúc có dễ hiểu khi đọc lại sau này?
- Góp ý của mình đã phân biệt bắt buộc và tùy chọn chưa?
- PR có đủ nhỏ để mình review thật sự nghiêm túc?
Kết luận
Code review tốt là kỹ năng đội nhóm, không phải cuộc thi đúng sai. Bước tiếp theo cụ thể: cùng đội thống nhất một quy ước ngắn về kích thước PR tối đa, thời gian phản hồi mong đợi, và cách đánh dấu góp ý tùy chọn. Chỉ ba thỏa thuận đó đã đổi được không khí review.
Câu hỏi thường gặp
Nên có bao nhiêu người review một PR?
Với hầu hết thay đổi, một người review kỹ là đủ. Phần code nhạy cảm (thanh toán, bảo mật, hạ tầng) nên có thêm người thứ hai am hiểu vùng đó.
Reviewer và người viết bất đồng thì xử lý sao?
Trao đổi dựa trên lý do kỹ thuật, không phải sở thích. Nếu vẫn bế tắc, mời người thứ ba hoặc người phụ trách kỹ thuật quyết, và ghi lại quyết định để lần sau khỏi tranh lại.
Có nên review cả code do AI sinh ra không?
Có, thậm chí cần kỹ hơn. Code do công cụ sinh ra trông trôi chảy nhưng vẫn có thể sai logic hoặc bỏ trường hợp biên, nên vẫn phải qua cùng bộ tiêu chí đúng đắn và test.
Review mất thời gian, có đáng không?
Chi phí sửa lỗi tăng dần khi lỗi lọt sâu về phía sản phẩm. Bắt một lỗi logic ở khâu review rẻ hơn nhiều so với vá nó trên production, chưa kể giá trị lan truyền kiến thức cho cả đội.
Nguồn tham khảo
- Google Engineering Practices – tài liệu công khai về Code Review của Google.
