Code review

Review tồn tại để bắt lỗi sớm và lan truyền hiểu biết, không phải để chứng minh ai giỏi hơn.

Người mở pull request

Giữ PR nhỏ: dưới ~400 dòng thay đổi. PR lớn nhận được ít góp ý có giá trị hơn PR nhỏ, vì người đọc mệt.
Tự review trước khi giao cho người khác — phần lớn lỗi ngớ ngẩn tự thấy được ở bước này.
Mô tả PR trả lời ba câu: vì sao cần thay đổi, cách tiếp cận, đã kiểm thử thế nào.
Tách refactor khỏi thay đổi hành vi. Trộn hai thứ khiến diff không đọc được.
Đánh dấu chỗ mình không chắc — chỉ thẳng vào nơi cần con mắt thứ hai.

Người review

Thứ tự ưu tiên khi đọc:

Đúng sai — có xử lý sai trường hợp biên, race condition, rò rỉ tài nguyên không?
Bảo mật & dữ liệu — dữ liệu người dùng có được kiểm tra đầu vào không, có ghi bí mật ra log không, quyền có bị nới rộng không?
Thiết kế — thay đổi có nằm đúng lớp không, có trùng lặp thứ đã tồn tại không?
Khả năng đọc — tên gọi, ranh giới hàm, chỗ nào cần chú thích vì sao.
Kiểm thử — test có thật sự fail khi mã sai không?

Bỏ qua: khoảng trắng, thứ tự import, định dạng — đó là việc của formatter và linter.

Mức độ góp ý

Gắn tiền tố để người nhận biết cái nào chặn merge:

Tiền tố	Ý nghĩa
`blocking:`	Phải sửa mới merge được
`question:`	Tôi chưa hiểu, giải thích giúp
`suggestion:`	Nên cân nhắc, không bắt buộc
`nit:`	Vụn vặt, sửa hay không tuỳ bạn
`praise:`	Chỗ này làm tốt — ghi nhận cũng là phản hồi

Bế tắc thì làm gì

Qua hai vòng qua lại mà chưa thống nhất thì gọi điện hoặc trao đổi trực tiếp — 5 phút nói chuyện bằng 20 bình luận. Chốt xong, ghi lại kết luận vào PR để người sau đọc còn hiểu.

Thời hạn phản hồi

Phản hồi lần đầu trong vòng một ngày làm việc. PR nằm chờ là công việc đang bị chặn.
Không kịp review kỹ thì nói sớm để người khác nhận, đừng im lặng.