Tôi từng làm việc ở một startup Việt Nam nơi code review là "việc phải làm" – developer A gửi PR, developer B nhìn qua trong 5 phút và approve với một emoji thumbs up. Năm tháng sau, họ gặp một bug nghiêm trọng trong transaction handler. Ai đó đã thay đổi logic xử lý exception, nhưng reviewer lúc đó chỉ... cuộn qua đoạn đó. Sau sự cố đó, team nhận ra rằng code review không phải là một bước trong quy trình – nó là nền tảng xây dựng chất lượng.
Sự thật khắc nghiệt mà ai cũng tránh nói
Các nghiên cứu từ Google và Microsoft cho thấy: 70% bugs có thể phát hiện được thông qua code review, nhưng chỉ khi reviewer thực sự tập trung. Vấn đề là, hầu hết team không tập trung. PR thứ 10 trong ngày thì chất lượng review đã giảm đáng kể. Mệt mỏi là kẻ thù lớn nhất của code review.
Thực tế là: đa số developer không ghét code review vì nó làm chậm quá trình, mà vì cách mà nó được thực hiện. Một comment để nói "tại sao bạn không dùng const thay vì let?" lúc 5 chiều thứ 6 sẽ khiến người gửi PR muốn bỏ việc.
Văn hóa, không phải quy tắc
Reviewers tốt không phải những người cực kỳ khắt khe. Họ là những người hiểu rõ mục đích đằng sau mỗi comment. Có sự khác biệt lớn giữa:
"Lỗi biến cục bộ này sẽ gây memory leak trong vòng lặp" (có tác động)
"Có thể dùng map() thay vì for" (style, có thể đặt lại cho lần sau)
Trong một team tốt, reviewer sẽ đặt câu hỏi thay vì chỉ chỉ trích. Thay vì "Sao bạn lại viết logic kinh dị thế này?", hãy nói "Em có thể giải thích tại sao lại cần bước này không? Tôi không chắc intent của nó."
Chia sẻ bài viết
Bài viết liên quan
Bạn cần tư vấn về công nghệ?
Đội ngũ Idflow luôn sẵn sàng hỗ trợ bạn trong hành trình chuyển đổi số.
Đó là sự khác biệt giữa một culture review code mạnh và một culture khiến mọi người lo sợ gửi PR.
Những con số mà công ty lớn không muốn nói
Ở Meta, một PR trung bình được review bởi 1.5 người (họ không chỉ dùng một reviewer). Ở Shopify, thời gian trung bình từ khi gửi PR đến approve là 24 giờ – không phải vì team lười, mà vì họ biết rằng reviewer tốt cần thời gian để suy nghĩ thực sự.
Ngược lại, ở các team "move fast and break things", con số approve time là 2-3 giờ, nhưng tỷ lệ bug trong production cao gấp 3 lần.
Công cụ chỉ là công cụ
GitHub, Gitea, GitLab, Gerrit – chúng ta có hàng tấn tools, nhưng chúng không tạo ra văn hóa review code tốt. Một team có culture kém dù dùng GitHub cũng sẽ review code tồi. Ngược lại, một team có culture tốt có thể review code bằng email và commit message (như Linux kernel làm).
Điều quan trọng là:
- Quyền lực phân tán: Không phải chỉ tech lead được approve
- Context rõ ràng: PR description phải giải thích "tại sao", không chỉ "cái gì"
- Đánh giá hoàn cảnh: Refactor lớn cần review khác so với bug fix nhỏ
Hành động thực tế
Nếu bạn muốn cải thiện code review trong team:
1Bắt đầu bằng chính mình – Review các PR như bạn muốn được review. Hỏi câu hỏi thay vì đưa lệnh.
1Đặt ra thời gian reviewer – Nếu không có "review time", reviewers sẽ luôn bị gián đoạn. Một số team dành 1 giờ sáng mỗi ngày chỉ để review.
1Phân tách concerns – Refactor code style không nên cùng PR với logic changes. Sẽ dễ dàng review hơn.
1Ghi lại learnings – Nếu một lỗi được phát hiện qua review, hãy thêm vào test suite hoặc documentation.
1Celebrate good reviews – Khi ai đó catch một bug sắp xảy ra, hãy khen. Culture tốt được xây bằng positive reinforcement.
Sự thật cay đắng
Code review không bao giờ "hoàn hảo". Có lúc bạn sẽ approve một PR rồi phát hiện bug tuần sau. Đó là bình thường. Điều quan trọng là liệu team bạn học được gì từ nó hay chỉ vội vàng fix và quên.
Văn hóa review code hiệu quả không phải về việc bắt lỗi mọi lỗi. Nó về việc team phối hợp để tạo ra code tốt hơn, reviewer hiểu code hơn, và developer trẻ học hỏi từ những người có kinh nghiệm.
Đó là lý do tại sao các team tại Idflow Technology luôn coi code review là một hoạt động học tập, không phải một barrier.
