Nhờ AI review code: tìm lỗi, hỏi đúng và xem lại trước khi merge

Pull request của Tú chỉ thay vài dòng ở chức năng xóa tài khoản. AI trả về một loạt góp ý về tên biến và cách viết gọn hơn. Nhưng câu hỏi khó nhất vẫn chưa được trả lời: người dùng có thể xóa nhầm tài khoản của người khác không? Trong ví dụ này, nhóm cần review hành vi của thay đổi, chứ chưa cần một danh sách làm mã trông đẹp hơn.

AI review mã nguồn hữu ích khi nhận xét dẫn tới một lỗi có thể kiểm trong ngữ cảnh dự án. Hãy đưa yêu cầu, phần mã liên quan và phạm vi cần xem. Sau đó xác minh từng phát hiện bằng đường chạy hoặc phép thử phù hợp trước khi sửa và quyết định merge.

Trước tiên, hiểu việc đang được sửa

Tú viết mô tả thay đổi bằng một tình huống: người dùng đã đăng nhập yêu cầu xóa tài khoản của chính họ. Anh nêu dữ liệu nào cần xử lý và điều kiện nào phải được đáp ứng. Người review, kể cả AI, cần hiểu hành vi mong muốn trước khi đánh giá vài dòng trong diff.

Đọc cả phần xung quanh, không chỉ dòng màu xanh đỏ. Quyền truy cập có thể được kiểm ở middleware, dữ liệu có thể được lọc trong một lớp khác. Nếu chỉ nhìn một hàm, AI có thể báo thiếu kiểm tra dù kiểm tra đã có ở trước. Ngược lại, một tên hàm nghe an toàn chưa chứng minh toàn bộ đường gọi đã được bảo vệ.

Tìm chức năng tương tự đang chạy trong dự án. Tú xem cách cập nhật hồ sơ xác định người dùng, kiểm quyền và trả lỗi. Mục tiêu là hiểu quy ước đang có, không tự áp một kiến trúc mới chỉ vì nhận xét nghe có vẻ chuẩn. Bài đọc thay đổi mã nguồn theo mạch giúp thu hẹp phần cần xem.

Nói rõ phạm vi review: tìm lỗi hành vi, lỗi quyền hoặc vấn đề dữ liệu liên quan đến thay đổi. Các đề xuất đổi tên và sắp lại mã có thể để riêng nếu không ảnh hưởng việc đang sửa. Khi mọi nhận xét cùng nằm trong một danh sách, lỗi quan trọng dễ chìm giữa những góp ý mang tính sở thích.

Kiểm giới hạn của công cụ đang dùng. Tài liệu GitHub về sử dụng agent có trách nhiệm nêu rằng code review có thể đưa ra phát hiện sai do hiểu nhầm mã. Vì vậy, một nhận xét nghe chắc vẫn cần bằng chứng trong dự án cụ thể.

Đi theo một đường người dùng có thể làm

Tú lần từ nút xóa đến yêu cầu gửi lên, bước xác thực, kiểm quyền và phần ghi dữ liệu. Mỗi chặng đặt một câu hỏi cụ thể. Danh tính lấy từ đâu? Mã tài khoản do ai cung cấp? Nếu yêu cầu bị thiếu thông tin, hệ thống phản hồi thế nào?

Thử trường hợp người dùng bình thường trước để hiểu luồng đúng. Sau đó xem người khác tài khoản, người chưa đăng nhập và yêu cầu lặp. Không phải mọi trường hợp đều cần viết test mới, nhưng phải có cách kiểm phù hợp với rủi ro của thay đổi. Với thao tác xóa, hậu quả dữ liệu cần được xem kỹ.

Quan sát cả việc xảy ra khi một bước thất bại. Nếu xóa thông tin ở bảng đầu rồi bước sau lỗi, trạng thái còn lại có hợp lệ không? Nếu có tác vụ chạy nền, nó sẽ nhìn thấy dữ liệu ở thời điểm nào? Câu hỏi phải dựa vào luồng thực của dự án, không chỉ liệt kê mọi lỗi có thể tưởng tượng.

Đối chiếu hợp đồng với phía gọi. Frontend có đang dựa vào trường dữ liệu vừa đổi không? Mã trạng thái hoặc cấu trúc lỗi có thay đổi không? Một sửa nhỏ phía sau có thể khiến màn hình hiểu sai kết quả. AI cần được xem các điểm gọi liên quan nếu chúng quyết định hành vi cuối.

Với vấn đề chưa chứng minh được, ghi rõ giả thuyết và điều cần kiểm. “Có thể xóa nhầm” chưa đủ để yêu cầu sửa ngay. Hãy chỉ ra đầu vào nào, đi qua đường nào và tạo ra kết quả gì. Nếu không tìm được đường xảy ra, cần xem lại nhận xét trước khi chuyển cho tác giả.

Nhận xét phải dẫn tới một bước kiểm tra

Một góp ý hữu ích nêu vị trí, điều kiện kích hoạt và ảnh hưởng. Ví dụ: “Khi gửi mã tài khoản khác, truy vấn này chưa giới hạn theo người đang đăng nhập.” Người đọc biết cần kiểm yêu cầu nào. Câu “cần tăng bảo mật” không đủ để họ xác nhận hoặc sửa đúng vấn đề.

Đưa cách kiểm nhỏ nhất có ý nghĩa. Với giả thuyết về quyền, chạy yêu cầu bằng hai tài khoản phù hợp trong môi trường thử. Với lỗi dữ liệu rỗng, tạo đúng trường hợp đầu vào. Tránh sửa mã trước rồi viết một phép thử chỉ lặp lại cách triển khai mới mà chưa chứng minh lỗi cũ.

Phân biệt lỗi cần sửa với câu hỏi cần làm rõ. Nếu chưa biết quy tắc nghiệp vụ, hỏi tác giả hoặc tìm tài liệu liên quan. Đừng để AI biến một lựa chọn có chủ đích thành lỗi chỉ vì cách đó khác ví dụ phổ biến. Ngữ cảnh dự án là phần quyết định.

Sau khi có bản sửa, kiểm lại đường gây lỗi và phần hành vi liên quan. Không cần chạy lặp mọi kiểm tra nếu không có lý do mới, nhưng cũng không dừng ở việc mã đã đổi. Bài kiểm tra chất lượng mã có AI hỗ trợ giúp đặt việc xác minh vào cùng quá trình viết.

Giữ các nhận xét đã bác bỏ với lý do ngắn nếu nhóm cần học lại. Chẳng hạn, quyền đã được kiểm ở middleware và có test tương ứng. Điều này giúp lần review sau tránh lặp cùng một cảnh báo, đồng thời làm rõ chỗ dự án đặt trách nhiệm kiểm tra.

Giữ quyền merge ở đúng người

Nhận được câu “không thấy lỗi” không có nghĩa thay đổi đã được bảo đảm an toàn. Review chỉ phản ánh phạm vi đã xem và cách đã kiểm. Người có trách nhiệm trong nhóm cần quyết định merge theo quy trình dự án, với các kiểm tra bắt buộc và hiểu biết về hành vi đang đổi.

Tách việc đề xuất khỏi quyền sửa và quyền đưa thay đổi vào nhánh chính. Nếu AI được phép tạo bản sửa, vẫn xem diff cuối trước khi chấp nhận. Một sửa lỗi có thể kéo theo thay đổi ngoài phạm vi. Cấp quyền đúng việc giúp kết quả dễ kiểm hơn và tránh hành động vượt nhu cầu.

Không đưa bí mật hoặc dữ liệu khách thật vào ví dụ chỉ để nhận review tốt hơn. Dùng dữ liệu giả phù hợp và công cụ được nhóm cho phép. Người review cần cấu trúc và hành vi liên quan, không nhất thiết cần toàn bộ dữ liệu đang chạy.

Biến kinh nghiệm thành checklist ngắn

Sau lỗi thực tế, thêm một câu kiểm cụ thể vào hướng dẫn của nhóm. Ví dụ: “Thao tác theo tài khoản phải kiểm phạm vi người dùng ở đường gọi.” Checklist nên phản ánh những việc dự án thật sự cần, thay vì dài đến mức ai cũng lướt qua.

Định kỳ bỏ các mục trùng và bổ sung ví dụ khi một câu hỏi còn khó hiểu. Kết hợp với đánh giá AI trên nhiệm vụ cụ thể, nhóm có thể biết công cụ hay bỏ sót hoặc báo nhầm điều gì. Với Tú, review tốt là tìm đúng vấn đề có ảnh hưởng và kiểm được nó, trước khi thay đổi đến tay người dùng.