Mục lục
Khi xem xét pull request (PR) của đồng nghiệp, hãy tập trung vào những lĩnh vực chính sau:
Chức năng
Mã nguồn có đạt được mục đích của nó không?
Ví dụ: Nếu PR nhằm triển khai tính năng đăng ký người dùng, hãy kiểm tra xem tất cả các trường cần thiết có mặt không, việc kiểm tra dữ liệu có được thực hiện và dữ liệu người dùng có được lưu đúng vào cơ sở dữ liệu không.
Chất lượng mã nguồn
- Tính dễ đọc và bảo trì
- Tuân thủ các tiêu chuẩn mã hóa và hướng dẫn phong cách
- Các quy ước đặt tên phù hợp
- Sao chép mã nguồn và cơ hội tái cấu trúc
Hiệu suất
Có bất kỳ điểm nghẽn hoặc sự kém hiệu quả nào không?
Ví dụ: Kiểm tra các truy vấn cơ sở dữ liệu không cần thiết trong vòng lặp hoặc các thuật toán không hiệu quả.
Bảo mật
Kiểm tra các lỗ hổng hoặc thực hành không an toàn
Ví dụ: Tìm kiếm các lỗ hổng tiềm ẩn về SQL injection hoặc xử lý đầu vào người dùng không đúng cách.
Kiểm thử
Đảm bảo có đủ độ bao phủ và chất lượng kiểm thử
Ví dụ: Xác minh rằng các kiểm thử đơn vị bao phủ các chức năng chính, các trường hợp biên, và các tình huống lỗi tiềm ẩn.
Tài liệu
Xác minh các chú thích trong mã và tài liệu bên ngoài
Ví dụ: Kiểm tra các docstring hàm rõ ràng và các chú thích giải thích logic phức tạp.
Các thực hành tốt nhất cho việc xem xét mã hiệu quả
Đúng thời gian
Xem xét các PR kịp thời để duy trì động lực phát triển
Ví dụ: Cố gắng xem xét các PR trong vòng 24 giờ sau khi gửi.
Thận trọng
Dành thời gian để hiểu các thay đổi và ảnh hưởng của chúng
Ví dụ: Chạy mã nguồn trên máy cục bộ và kiểm tra các tình huống khác nhau.
Cụ thể
Cung cấp phản hồi rõ ràng, có thể hành động với các ví dụ hoặc gợi ý
Ví dụ: Thay vì "Hàm này gây nhầm lẫn", hãy nói "Hãy cân nhắc chia nhỏ hàm process_data() thành các hàm nhỏ hơn và cụ thể hơn để cải thiện khả năng đọc."
Xây dựng
Tập trung vào mã nguồn, không phải nhà phát triển; đưa ra giải pháp, không chỉ phê bình
Ví dụ: Thay vì "Đây là mã nguồn xấu", hãy nói "Chúng ta có thể cải thiện điều này bằng cách sử dụng từ điển thay vì các câu lệnh if lồng nhau. Đây là một ví dụ: ..."
Đặt câu hỏi
Tìm kiếm sự làm rõ khi không chắc chắn về các lựa chọn triển khai
Ví dụ: "Tại sao bạn chọn sử dụng phương pháp đệ quy ở đây thay vì phương pháp lặp lại? Tôi tò mò về lý do."
Khen ngợi công việc tốt
Công nhận các giải pháp hoặc cải tiến thông minh
Ví dụ: "Làm tốt việc tối ưu hóa truy vấn cơ sở dữ liệu. Điều này sẽ cải thiện đáng kể thời gian tải."
Xem xét tổng thể
Đánh giá cách các thay đổi phù hợp với kiến trúc hệ thống tổng thể
Ví dụ: "Phương pháp xác thực mới này phù hợp như thế nào với kế hoạch của chúng ta để triển khai đăng nhập một lần trong tương lai?"
Xác minh các trường hợp biên
Suy nghĩ về các kịch bản lỗi tiềm ẩn hoặc đầu vào không bình thường
Ví dụ: "Điều gì xảy ra nếu API trả về phản hồi rỗng? Chúng ta có nên thêm xử lý lỗi cho trường hợp này không?"
Sử dụng công cụ
Hãy tận dụng các công cụ phân tích mã tự động để phát hiện các vấn đề phổ biến
Ví dụ: Cài đặt các công cụ phân tích mã (ví dụ: ESLint cho JavaScript, Pylint cho Python) trong pipeline CI/CD của bạn để tự động kiểm tra phong cách mã và lỗi tiềm ẩn.
Theo dõi
Đảm bảo các thay đổi được đề xuất được triển khai và xem xét lại nếu cần
Ví dụ: Sau khi cung cấp phản hồi, kiểm tra PR đã cập nhật để xác minh rằng các thay đổi đã được triển khai đúng cách và không có vấn đề mới nào được đưa vào.
Bằng cách làm theo các thực hành này, bạn sẽ đóng góp vào việc nâng cao chất lượng mã nguồn, chia sẻ kiến thức và quy trình phát triển hợp tác hơn.