Kỹ năng Code Review văn minh: Cách đưa ra phản hồi giúp đồng nghiệp tiến bộ mà không tạo hiềm khích
Bi kịch khi Code Review trở thành chiến trường công kích cá nhân Quy trình Code Review sinh ra để nâng cao chất lượng phần mềm và chia sẻ kiến thức. Nhưng trong nhiều team công nghệ, review code lại …
☰ Mục lục bài viết (7 phần) Mở / Đóng mục lục
Bi kịch khi Code Review trở thành chiến trường công kích cá nhân#
Quy trình Code Review sinh ra để nâng cao chất lượng phần mềm và chia sẻ kiến thức. Nhưng trong nhiều team công nghệ, review code lại trở thành nguồn cơn gây mâu thuẫn nội bộ gay gắt:
- Người review thì săm soi, dùng từ ngữ mỉa mai: "Ai viết đoạn code dở tệ này thế này?".
- Người được review thì tự ái cá nhân, phòng thủ và coi mỗi comment là một đòn tấn công vào năng lực của mình.
Dưới đây là cẩm nang Code Review văn minh theo tiêu chuẩn của Google Engineering.
4 Nguyên tắc Code Review đỉnh cao#
1. Phê bình dòng code, không bao giờ phán xét con người#
- Sai: "Bạn không biết dùng hàm map à? Sao lại viết vòng for cổ lỗ sĩ thế này?".
- Đúng: "Đoạn code này nếu chuyển sang dùng
items.map()thì sẽ ngắn gọn và dễ đọc hơn, bạn thấy sao?".
2. Phân loại mức độ nghiêm trọng bằng Conventional Comments#
Sử dụng các nhãn tiền tố rõ ràng để người được review biết việc nào bắt buộc phải sửa, việc nào chỉ là gợi ý tham khảo:
[blocking]hoặc[issue]: Lỗi logic nghiêm trọng, bug bảo mật $\rightarrow$ Bắt buộc sửa mới được merge.[suggestion]: Đề xuất cách viết sạch hơn $\rightarrow$ Tùy tác giả cân nhắc.[nitpick]: Lỗi chính tả nhỏ, format thừa khoảng trắng $\rightarrow$ Không chặn merge.[praise]: Khen ngợi khi đồng nghiệp có cách giải quyết sáng tạo, thông minh!
3. Giải thích lý do (The "Why") đằng sau mỗi đề xuất#
Đừng chỉ ra lệnh "Hãy sửa thành X". Hãy giải thích lý do kỹ thuật đằng sau kèm link tài liệu tham khảo:
"Chỗ này mình đề xuất dùng
useCallbackvì component con bên dưới được bọc trongReact.memo. Nếu không giữ tham chiếu hàm, component con sẽ bị re-render vô ích mỗi khi component cha cập nhật state."
4. Đừng ngần ngại dành lời khen (Praise)#
Một review tốt không phải chỉ toàn những lời bắt lỗi. Nếu thấy một đoạn code xử lý edge case xuất sắc hoặc một test suite viết rất chỉn chu, hãy để lại comment:
"Đoạn xử lý concurrency này thông minh lắm! Good job bạn!".
Góc thảo luận#
Văn hóa Code Review ở team của bạn hiện tại như thế nào? Có quy định thời gian tối đa để review xong một Pull Request không?
Xem thêm nội dung liên quan:
Thảo luận
1 phản hồi
Tham gia thảo luận
Bài liên quan trong #Sự nghiệp & Phỏng vấn IT
-
Lập trình viên có bị thay thế bởi AI không? 5 kỹ năng bắt buộc phải nâng cấp trong 2 năm tới
Hoàng Nam (Tech Lead) · 💬 1 -
Xây dựng thương hiệu cá nhân (Personal Branding) cho lập trình viên qua GitHub và Tech Blog
Lan Anh (Senior Frontend) · 💬 1 -
Freelance vs Fulltime: Đánh đổi gì khi chọn con đường làm tự do cho các dự án quốc tế?
Việt Anh (Cloud Architect) · 💬 1 -
Chuẩn bị phỏng vấn Live Coding: Chiến lược giải quyết bài toán khi bạn bị "đơ" trước mặt interviewer
Quốc Bảo (Fullstack Developer) · 💬 1 -
Quản lý thời gian và Deep Work cho Developer: Thoát khỏi vòng xoáy họp hành liên miên
Quốc Bảo (Fullstack Developer) · 💬 1