Code review văn minh: góp ý sao cho không ai tổn thương

Trong công việc hằng ngày của dev, chúng ta thường gặp hai thái cực Code Review:

• Thái cực 1: Pull Request (PR) 200 dòng code nhưng chỉ nhận đúng một bình luận "LGTM" (Look Good To Me) sau vài chục giây.

• Thái cực 2: PR 5 dòng code nhưng nhận lại tới 47 bình luận, đi kèm những câu hỏi mang tính phán xét như "Sao lại viết thế này?".

Cả hai cách làm trên đều không mang lại giá trị thực sự. Một quy trình Code Review hiệu quả cần đạt được sự cân bằng: đủ kỹ lưỡng để bắt lỗi, và đủ tử tế để người nhận đóng góp muốn tiếp tục viết code tốt hơn.

1. Mục Đích Thực Sự Của Code Review

Trước khi bắt tay vào review, cả team cần thống nhất rằng Code Review không chỉ đơn thuần là việc "tìm lỗi". Nó mang lại 3 giá trị cốt lõi:

• Chia sẻ kiến thức: Người review hiểu thêm về mảng code mình không trực tiếp viết; người được review học hỏi được cách xử lý tối ưu hơn.

• Giữ chuẩn mực codebase: Tránh tình trạng mỗi thành viên viết theo một phong cách riêng, khiến dự án trở thành một tập hợp thiếu thống nhất.

• Giảm rủi ro phụ thuộc cá nhân: Khi có ít nhất hai người cùng nắm rõ một luồng xử lý, dự án sẽ không bị ảnh hưởng nặng nề nếu có thành viên vắng mặt.

Tư duy cốt lõi: Khi hiểu rằng mục tiêu cuối cùng là giúp cả team cùng tiến bộ, giọng điệu góp ý tự nhiên sẽ trở nên chân thành và mang tính xây dựng hơn.

2. Dành Cho Người Review (Reviewer)

Nhận xét vào code, không nhận xét vào con người

Hãy phân biệt rõ giữa chất lượng dòng code và năng lực của tác giả.

• ❌ Nên tránh: "Bạn viết đoạn này sai rồi."

• ✅ Nên nói: "Đoạn này có thể phát sinh lỗi nếu danh sách trả về bị rỗng."

Nội dung kỹ thuật là như nhau, nhưng cách nói thứ hai tập trung hoàn toàn vào việc xử lý vấn đề thay vì tạo cảm giác chỉ trích.

Thay câu mệnh lệnh bằng câu hỏi

Nhiều trường hợp người review chưa nắm hết toàn bộ bối cảnh (context) công việc. Đặt câu hỏi mở sẽ giúp tác giả giải thích rõ lý do, và đôi khi chính người review lại học thêm được góc nhìn mới.

Thay vì đưa ra mệnh lệnh

"Dùng map đi, viết thế này sai rồi."

"Sao lại viết đoạn này kỳ vậy?"

"Code chỗ này khó đọc quá."

...Hãy thử gợi ý bằng câu hỏi...

"Chỗ này dùng map có gọn hơn không, hay bạn có lý do riêng để dùng vòng lặp for?"

"Mình chưa hiểu rõ đoạn này lắm, bạn giải thích giúp mình ý tưởng xử lý ở đây nhé?"

"Thử tách phần kiểm tra quyền ra một hàm riêng xem, liệu có giúp code thoáng hơn không?"

Phân loại mức độ quan trọng của góp ý

Để người nhận không bị ngợp và biết rõ phần nào bắt buộc phải sửa, bạn có thể áp dụng các tiền tố đơn giản:

• [Must] / [Blocker]: Lỗi logic, lỗ hổng bảo mật, bug nghiêm trọng — Bắt buộc sửa trước khi merge.

• [Should] / [Suggest]: Gợi ý cách tối ưu tốt hơn — Khuyến khích cân nhắc, không bắt buộc.

• [Nit] (Nitpick): Chi tiết nhỏ như cách đặt tên, khoảng trắng — Sửa được thì tốt, không ảnh hưởng lớn.

Một số lưu ý quan trọng khác:

• Dành lời khen đúng lúc: Nếu thấy một cách xử lý thông minh hay bộ test case cẩn thận, đừng ngần ngại để lại một lời khen.

• Giải thích rõ lý do: Thay vì chỉ nói "Đổi tên biến này đi", hãy giải thích thêm: "Tên data hơi chung chung, đổi thành orderList sẽ giúp người đọc sau dễ hiểu ngay nội dung bên trong".

• Phản hồi sớm: Tránh để PR treo quá 1 ngày làm việc. Nếu chưa thể xem ngay, hãy nhắn một câu hẹn thời gian cụ thể.

• Để máy móc xử lý định dạng: Hãy sử dụng công cụ tự động (ESLint, Prettier, CI/CD) để kiểm tra syntax, khoảng trắng, dấu chấm phẩy. Người review chỉ nên tập trung vào logic và kiến thức.

3. Dành Cho Người Nhận Review (PR Creator)

Gửi Pull Request nhỏ và gọn

Một PR kéo dài hàng trăm dòng thường chỉ nhận được cái gật đầu qua loa vì không ai đủ thời gian soi kỹ. PR càng nhỏ gọn (dưới 200–300 dòng), chất lượng góp ý bạn nhận lại sẽ càng sâu sát và hữu ích.

Viết mô tả (Description) rõ ràng

Giúp người review nắm bắt nhanh thông tin bằng cách tóm tắt:

1. Thay đổi này giải quyết bài toán gì?

2. Cách tiếp cận/giải pháp thực hiện là gì?

3. Cần lưu ý đặc biệt ở khu vực nào?

4. Đã thực hiện kiểm thử (test) ra sao?

Tự review lại code của mình

Trước khi gửi link cho đồng nghiệp, hãy dành 2 phút đọc lại toàn bộ phần code thay đổi (diff). Bạn sẽ dễ dàng phát hiện ra các dòng console.log thừa hoặc ghi chú chưa dọn dẹp.

Giữ thái độ cởi mở

Phản xạ tự nhiên khi nhận góp ý là giải thích để bảo vệ code của mình. Tuy nhiên, hãy chậm lại một chút:

• Nếu người review hiểu nhầm -> Có thể do code hoặc mô tả của bạn chưa đủ rõ ràng.

• Góp ý nhắm vào dòng code, không nhắm vào bạn. Người tiếp thu nhiều góp ý tích cực sẽ là người bứt phá nhanh nhất.

Nguyên tắc xử lý khi bất đồng ý kiến

Nếu cuộc tranh luận trên các dòng comment kéo dài quá 3 lượt qua lại mà chưa đi đến thống nhất:

1. Dừng gõ phím ngay lập tức.

2. Trao đổi trực tiếp: Gọi điện hoặc gặp mặt nói chuyện 5 phút. Việc trao đổi trực tiếp giúp giữ đúng tông giọng hòa nhã và giải quyết vấn đề nhanh hơn rất nhiều so với văn bản.

3. Ghi lại kết luận: Sau khi thống nhất, ghi tóm tắt kết quả lại vào PR để cả team cùng nắm thông tin.

Lời Kết

Văn hóa Code Review phản ánh trực tiếp sự gắn kết và chuyên nghiệp của một đội ngũ phát triển phần mềm. Một môi trường làm việc tích cực là nơi người mới tự tin gửi code, người đi trước sẵn lòng chia sẻ, và chất lượng hệ thống ngày càng hoàn thiện.

Lần tới, khi định gõ "Sao lại viết thế này?", hãy thử đổi thành một câu hỏi gợi mở xem sao nhé!