Skip to content

Code review

This content is not available in your language yet.

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

  • 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.

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

  1. Đúng sai — có xử lý sai trường hợp biên, race condition, rò rỉ tài nguyên không?
  2. 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?
  3. 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?
  4. Khả năng đọc — tên gọi, ranh giới hàm, chỗ nào cần chú thích vì sao.
  5. 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.

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

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.

  • 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.