Tâm lý khi nhận PR Review: Tách biệt cái tôi khỏi dòng code

Khi một Senior Engineer hoặc Tech Lead comment: *"Đoạn này có thể gây race condition"* hay *"Query này thiếu index dẫn đến full table scan"*, phản xạ tự nhiên của nhiều lập trình viên mới là cảm thấy bị chỉ trích hoặc có xu hướng phòng thủ.

Tuy nhiên, nguyên tắc vàng trong văn hóa kỹ thuật chuyên nghiệp là: Reviewer đang rà soát mã nguồn để bảo vệ hệ thống production, không phải đánh giá giá trị cá nhân bạn. Mỗi nhận xét khắt khe trên Pull Request thực chất là một bài học đắt giá được đúc kết từ nhiều giờ incident và sự cố thực tế của người đi trước.

Quy trình 3 bước xử lý phản hồi review code

1. Thấu hiểu nguyên nhân gốc rễ (Root Cause): Đừng vội sửa máy móc dòng code đó. Hãy tự hỏi: *"Vì sao reviewer lại gợi ý cấu trúc này? Nó giải quyết vấn đề gì về độ phức tạp thời gian, tính toàn vẹn dữ liệu hay độ an toàn luồng?"*
2. Đánh giá vùng ảnh hưởng (Blast Radius): Khi thay đổi một method hoặc schema dữ liệu, những nơi nào khác đang phụ thuộc vào nó? Bạn đã bổ sung unit test hoặc integration test để đảm bảo không làm gãy các tính năng hiện tại chưa?
3. Thảo luận kỹ thuật khách quan: Khi đã cập nhật xong, hãy để lại phản hồi rõ ràng kèm liên kết commit tương ứng. Nếu bạn có phương án khác tốt hơn, hãy trình bày bằng số liệu benchmark hoặc tài liệu chính thức thay vì cảm tính.

Xây dựng Personal Checklist sau mỗi đợt review

Mỗi lần một Pull Request được merge, hãy ghi lại 1–2 lỗi bạn đã mắc phải vào một danh sách cá nhân (Personal Checklist): quên kiểm tra điều kiện biên, thiếu transaction rollback, đặt tên biến tối nghĩa hay bỏ quên xử lý timeout.

Trước khi tạo Pull Request tiếp theo, hãy tự mở diff và review toàn bộ code của mình dựa trên checklist đó. Bạn sẽ thấy chất lượng code của mình nhảy vọt chỉ sau vài tháng.

Tại VCoderLog Academy, các bài tập lớn đều trải qua quy trình Code Review 1:1 nghiêm ngặt với Solution Architect để giúp học viên hình thành tư duy kỹ thuật chuẩn công nghiệp ngay từ ngày đầu.