Code Review — nó là gì, cách thức đánh giá mã và kiểm tra PR hoạt động

Code Review là gì

Code review là sự kiểm tra có hệ thống mã nguồn bởi đồng nghiệp trước khi tích hợp. Trong bối cảnh Git, điều này có nghĩa là: một nhà phát triển tạo pull request với các thay đổi, chỉ định người đánh giá, và họ nghiên cứu diff, để lại nhận xét và đưa ra phán quyết. Người đánh giá có thể yêu cầu thay đổi, phê duyệt PR hoặc để lại nhận xét chung.

Đánh giá mã theo đuổi năm mục tiêu: cải thiện chất lượng mã (phát hiện lỗi trước khi chúng đến sản phẩm), lan truyền kiến thức (người đánh giá học được các phương pháp mới, tác giả nhận được phản hồi), đảm bảo tiêu chuẩn (kiểm tra tuân thủ phong cách mã và quyết định kiến trúc), giảm bus factor (nhiều hơn một nhà phát triển biết mã) và xây dựng văn hóa trách nhiệm (tác giả viết cẩn thận hơn khi biết mã sẽ được đánh giá).

Đối lập với đánh giá mã là blind commit: một nhà phát triển đẩy thay đổi vào nhánh dùng chung mà không qua đánh giá. Cách tiếp cận này chỉ chấp nhận được trong các dự án một nhà phát triển hoặc cho các bản vá khẩn cấp với đánh giá sau đó. Trong phát triển nhóm chuyên nghiệp, đánh giá mã là bước bắt buộc cho mọi thay đổi, bao gồm cập nhật tài liệu và cấu hình.

Những gì cần kiểm tra trong Code Review

Đánh giá mã nên có hệ thống, không hỗn loạn. Người đánh giá giàu kinh nghiệm kiểm tra mã theo một thứ tự cụ thể: đầu tiên là kiến trúc và logic, sau đó là kiểm thử, tiếp theo là bảo mật và hiệu suất, và cuối cùng — phong cách và đặt tên. Thứ tự này đảm bảo các vấn đề nghiêm trọng được chú ý trước khi người đánh giá mệt mỏi.

Kiến trúc và logic: mã có giải quyết được nhiệm vụ không, có sự trừu tượng quá mức không, các nguyên tắc SOLID và DRY có được tuân thủ không. Mã phức tạp khó hiểu ngay từ lần đọc đầu tiên là tín hiệu cần tái cấu trúc. Người đánh giá phải đảm bảo mã làm chính xác những gì nhiệm vụ chỉ định và không có tác dụng phụ ngoài phạm vi trách nhiệm của nó.

Kiểm thử: các bài kiểm thử mới có bao phủ tất cả kịch bản không — tích cực, tiêu cực, trường hợp biên. Các bài kiểm thử hiện có có vượt qua sau các thay đổi không. Có bài kiểm thử không ổn định nào thất bại không nhất quán không. Bảo mật: không có SQL injection, XSS, rò rỉ dữ liệu nhạy cảm qua log hoặc phản hồi API. Hiệu suất: hiệu quả thuật toán, truy vấn cơ sở dữ liệu quá mức, rò rỉ tài nguyên.

• Kiến trúc — tính đúng đắn của giải pháp, tuân thủ SOLID, không có kỹ thuật quá mức.
• Logic — xử lý tất cả kịch bản, bao gồm lỗi và trường hợp biên.
• Kiểm thử — bao phủ các thay đổi mới, không làm hỏng kiểm thử hiện có.
• Bảo mật — injection, XSS, CSRF, rò rỉ dữ liệu qua log.
• Hiệu suất — độ phức tạp thuật toán, truy vấn N+1, rò rỉ bộ nhớ.

Kích thước đánh giá: tại sao 400 dòng là tối đa

Giới hạn kích thước PR là chỉ số quan trọng nhất của hiệu quả đánh giá mã. Một nghiên cứu của Cisco (2015) và các thí nghiệm tiếp theo của SmartBear và Google cho thấy khi khối lượng đánh giá vượt quá 400 dòng, khả năng phát hiện lỗi của người đánh giá giảm mạnh. Nếu PR vượt quá 400 dòng, lỗi được phát hiện với xác suất không cao hơn ngẫu nhiên.

Kích thước tối ưu: 200–400 dòng cho mỗi PR. Khối lượng này có thể được đánh giá trong 30–60 phút mà vẫn duy trì sự tập trung. Google khuyến nghị không quá 200 dòng cho mỗi vòng đánh giá với sự tập trung hoàn toàn. Nếu thay đổi lớn hơn, nhiệm vụ cần được phân rã thành nhiều PR tuần tự, mỗi PR giới thiệu một thay đổi hoàn chỉnh về mặt logic.

Thời gian đánh giá: trong vòng 24 giờ kể từ khi tạo PR. Nếu đánh giá kéo dài nhiều ngày, ngữ cảnh nhiệm vụ bị mất và tác giả phải dành thời gian khôi phục ngữ cảnh khi trả lời nhận xét. Các nhóm có văn hóa đánh giá mã mạnh mẽ thiết lập SLA cho đánh giá: ví dụ, 4 giờ cho thay đổi quan trọng và 24 giờ cho thay đổi thông thường.

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

Giọng điệu của nhận xét rất quan trọng đối với hiệu quả đánh giá mã. Một nhận xét như “Điều này sai” gây ra phản ứng phòng thủ và không cung cấp thông tin hữu ích cho tác giả. Một cách diễn đạt tốt hơn là câu hỏi-đề xuất: “Bạn nghĩ gì về cách tiếp cận này?”, “Điều này có thể gây ra NPE nếu user == nil. Có lẽ thêm guard?”. Câu hỏi ít đối đầu hơn và kích thích thảo luận.

Một nhận xét tốt bao gồm ba phần: điều gì sai, tại sao nó là vấn đề và cách sửa. Ví dụ: “Vòng lặp này sử dụng O(n²) do contains lồng nhau, có thể chậm với 10k+ bản ghi. Hãy thử thay thế bằng Set để tra cứu O(1).” Cách diễn đạt này đồng thời xác định vấn đề, giải thích tầm quan trọng của nó và đề xuất giải pháp — tác giả không cần phải đoán.

GitHub và GitLab hỗ trợ đề xuất — các đề xuất thay đổi mã nội dòng. Người đánh giá có thể viết: “```suggestion Filter empty strings before processing```” và tác giả có thể áp dụng thay đổi chỉ bằng một cú nhấp chuột. Điều này tăng tốc các sửa chữa nhỏ và giảm số vòng đánh giá. Đối với các thay đổi lớn, tốt hơn nên viết nhận xét chung thay vì nhúng các khối lớn vào đề xuất.

# Mẫu nhận xét đánh giá mã tốt

# XẤU: "This code is wrong"
# TỐT: "We may lose data on empty response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# Cú pháp đề xuất GitHub:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Quy trình Code Review trong nhóm

Một quy trình đánh giá hiệu quả được xây dựng trên bốn giai đoạn. Đầu tiên — tác giả chuẩn bị PR: viết tiêu đề rõ ràng (ví dụ: “feat: add password reset screen”), thêm mô tả thay đổi, liên kết đến nhiệm vụ trong trình theo dõi và hướng dẫn kiểm thử. Thứ hai — tác giả chỉ định người đánh giá qua tự động chỉ định (dựa trên CODEOWNERS) hoặc thủ công.

Giai đoạn thứ ba — người đánh giá kiểm tra mã và để lại nhận xét. Thứ tư — tác giả thực hiện sửa chữa, trả lời nhận xét và yêu cầu đánh giá lại. Chu kỳ lặp lại cho đến khi nhận được phê duyệt. Sau khi phê duyệt, tác giả thực hiện hợp nhất (hoặc bot thực hiện). Tự động hóa qua Mergify hoặc GitHub Auto-merge tăng tốc giai đoạn cuối.

Một yếu tố quan trọng của quy trình là quản lý PR cũ. Nếu PR không được đánh giá trong hơn 3 ngày, quy trình bị chặn. Giải pháp: luân chuyển người đánh giá (nếu người được chỉ định không có mặt), thông báo qua Slack/Teams, giới hạn thời gian đánh giá (SLA). Trong một số nhóm, PR không được đánh giá trong hơn 7 ngày sẽ tự động đóng và tác giả tạo PR mới sau khi đồng bộ với main.

• Tạo PR — tiêu đề rõ ràng, mô tả, liên kết nhiệm vụ, ảnh chụp màn hình cho thay đổi UI.
• Chỉ định — tự động chỉ định qua CODEOWNERS hoặc chọn thủ công 1–2 người đánh giá.
• Đánh giá — kiểm tra theo thứ tự: kiến trúc → logic → kiểm thử → bảo mật → phong cách.
• Sửa chữa — tác giả trả lời tất cả nhận xét, sửa vấn đề chặn, yêu cầu đánh giá lại.
• Hợp nhất — sau khi phê duyệt và CI xanh, tác giả hoặc bot thực hiện hợp nhất.

Những sai lầm thường gặp trong Code Review

Sai lầm đầu tiên — đánh giá hời hợt. Người đánh giá quét nhanh diff mà không đi sâu vào logic và nhấn Phê duyệt. Nguyên nhân: PR lớn, hạn chót, mệt mỏi. Hậu quả: lỗi đến sản phẩm. Giải pháp: nếu không có thời gian cho đánh giá chất lượng — hãy thành thật viết “Tôi không thể đánh giá hôm nay, hãy chuyển sang ngày mai” thay vì phê duyệt hình thức.

Sai lầm thứ hai — chỉ trích quá mức (nitpicking). Người đánh giá để lại hàng chục nhận xét về phong cách định dạng, đặt tên biến, chi tiết vụn vặt. Điều này làm mất động lực của tác giả và kéo dài đánh giá. Giải pháp: StyleGuide và linter nên kiểm tra phong cách tự động. Con người trong đánh giá kiểm tra logic, kiến trúc và bảo mật.

Sai lầm thứ ba — đánh giá không có câu hỏi. Nếu người đánh giá chỉ đăng Request Changes và Approve nhưng không đặt câu hỏi, họ bỏ lỡ cơ hội học điều mới. Chỉ báo tốt nhất của đánh giá lành mạnh là sự hiện diện của các cuộc thảo luận nơi cả hai bên học được điều mới. Nếu đánh giá là độc thoại của một người tham gia, quy trình đã bị hỏng.

• Đánh giá hời hợt — Phê duyệt không có phân tích sâu. Giải pháp: không đánh giá nếu không có thời gian.
• Nitpicking — chỉ trích phong cách lẽ ra nên được linter kiểm tra. Giải pháp: tự động hóa kiểm tra phong cách.
• Sở thích cá nhân — “Tôi sẽ viết khác đi”. Giải pháp: mã nên hoạt động, không phải làm hài lòng người đánh giá.
• Chậm trễ — đánh giá hơn 24 giờ. Giải pháp: SLA cho đánh giá, leo thang khi vi phạm.
• Bỏ qua ngữ cảnh — đánh giá mã mà không hiểu nhiệm vụ. Giải pháp: đọc mô tả PR trước diff.