Quy trình review code của team mình

Team mình review code theo một quy trình mình mất khá lâu mới chỉnh được cho đúng. Không quá nặng nề để làm chậm mọi người, nhưng đủ chặt để bug không lọt ra production. Đây là toàn bộ quy trình đó.

Nguyên tắc đầu tiên: PR nhỏ#

Quy tắc số một, và là quy tắc khó giữ nhất: PR phải nhỏ. Một PR dưới 400 dòng được review kỹ. Một PR 2000 dòng được review kiểu "nhìn qua thấy ổn, approve". Người ta không lười — não người có giới hạn. PR càng to, chất lượng review càng tụt.

Nên việc đầu tiên khi mở một PR to là mình hỏi: tách được không? Gần như luôn tách được.

Ai review, review cái gì#

Mỗi PR cần ít nhất một approve từ người không viết code đó. Với code đụng vào phần nhạy cảm — auth, thanh toán, migration — cần hai.

Reviewer tập trung vào ba thứ, theo đúng thứ tự:

• Đúng không — logic có chạy đúng với cả case lỗi, case rỗng, case race không?
• Đọc được không — sáu tháng nữa người khác đọc có hiểu không?
• Test đúng tầng chưa — logic nghiệp vụ có unit test, flow có e2e, getter thì khỏi.

Cái mình KHÔNG review#

Format, thụt dòng, dấu nháy, thứ tự import — tất cả để cho Prettier và linter lo. CI chặn, không cần con người nhắc. Nếu trong PR có comment cãi nhau về khoảng trắng, nghĩa là tooling đang thiếu, và mình đi sửa tooling chứ không sửa thói quen con người.

Comment sao cho không làm tổn thương#

Một bài học mất thời gian mới học được: comment vào code, đừng comment vào người. "Hàm này nên tách ra cho dễ test" thì ổn. "Sao em lại viết thế này" thì không. Cùng một ý, nhưng một câu nói về code, một câu nói về người viết.

Và khi mình khen thì mình khen cụ thể. "Chỗ xử lý lỗi này gọn, thích" — câu đó đáng giá hơn mười cái icon approve.

Tốc độ#

PR mở ra phải được review trong vòng nửa ngày làm việc. Để một PR treo hai ngày là cách nhanh nhất giết động lực của người viết, và là cách nhanh nhất tạo ra một hàng dài PR phụ thuộc lẫn nhau. Review nhanh không phải là review ẩu — nó là tôn trọng thời gian của nhau. Nếu mình bận, mình nói "chiều mình xem", chứ không để im.