Chuẩn review code

Review nhằm đạt gì

Theo thứ tự ưu tiên:

1. Bắt lỗi mà tác giả không thấy vì đã quá quen với code của mình.
2. Lan truyền hiểu biết để phần này không chỉ một người nắm.
3. Giữ sự nhất quán để codebase đọc như do một người viết.

Tranh cãi về dấu cách hay thứ tự import không thuộc danh sách trên. Những thứ đó giao cho công cụ định dạng tự động, bàn trong review là lãng phí thời gian cả hai phía.

Trách nhiệm người gửi

• Giữ thay đổi nhỏ. Trên 400 dòng thì chất lượng review giảm rõ rệt.
• Viết mô tả nêu vì sao, không chỉ cái gì — phần "cái gì" đã nằm trong diff.
• Tự đọc lại diff của mình trước khi gửi. Phần lớn góp ý có thể tự bắt được ở bước này.
• Nói rõ chỗ mình không chắc, để người review tập trung đúng nơi cần.

Trách nhiệm người review

• Phản hồi trong vòng một ngày làm việc. Thay đổi nằm chờ sẽ lỗi thời và tích tụ xung đột.
• Phân biệt rõ mức độ góp ý:
  • Chặn: có lỗi, có rủi ro bảo mật, hoặc phá vỡ giao kèo đang có.
  • Nên sửa: cải thiện đáng kể, nhưng không chặn việc hợp nhất.
  • Ghi chú: ý kiến cá nhân, tác giả tự quyết.
• Hỏi thay vì ra lệnh. "Chỗ này khi danh sách rỗng thì sao?" tốt hơn "sai rồi".
• Khen khi thấy đoạn code hay. Review chỉ toàn điểm trừ khiến người ta ngại gửi.

Cần soi kỹ ở đâu

• Xử lý lỗi và các trạng thái biên — nơi lỗi hay trốn nhất
• Ranh giới giữa các thành phần, nhất là chỗ thay đổi giao kèo công khai
• Bất cứ chỗ nào chạm tới xác thực, quyền hạn hay dữ liệu cá nhân
• Branch xử lý đồng thời và thứ tự thực thi
• Câu truy vấn hoặc vòng lặp chạy trên danh sách có thể lớn dần theo thời gian

Khi bất đồng không giải quyết được

Bàn trực tiếp năm phút thay vì viết qua lại mười lượt bình luận. Vẫn không ngã ngũ thì hỏi ý kiến người thứ ba và ghi lại kết luận. Điều tệ nhất là để thay đổi mắc kẹt vô thời hạn.