Trong nhiều năm viết và xem lại mã, tôi đã học được một số bí quyết để tạo ra các yêu cầu kéo tốt hơn và xem lại mã hiệu quả hơn.
Tôi đã đưa tất cả những bí mật này vào cuốn sách mới của mình Yêu cầu kéo và Đánh giá mã , nhưng bạn sẽ tìm thấy ở đây bản xem trước với 13 mẹo này mà bạn có thể sử dụng trong hoạt động nhà phát triển của mình.
Bạn có thể nghĩ ra nhiều lời khuyên hơn? Hãy chia sẻ chúng trong phần bình luận 😉
Bản dự thảo PR giúp bạn sắp xếp các ý tưởng và ghi lại tiến trình của mình trong khi bạn vẫn đang thực hiện tính năng của mình.
Cách tốt nhất để có được đánh giá nhanh chóng và hiệu quả là giữ cho PR của bạn nhỏ gọn và được ghi chép đầy đủ (với tất cả bối cảnh cần thiết). Bạn cũng sẽ tăng cơ hội đạt được các PR trong tương lai bằng cách cung cấp mã tuyệt vời ngay bây giờ!
Tìm tất cả các mẹo này và hơn thế nữa, với nhiều ví dụ thực tế hơn và thông tin chi tiết hữu ích trong cuốn sách miễn phí của tôi về Yêu cầu kéo và Đánh giá mã: Thực tiễn tốt nhất dành cho nhà phát triển, từ cấp dưới đến trưởng nhóm .
Hãy đặt mình vào vị trí của người đánh giá, đoán trước các câu hỏi và sử dụng nhận xét về mã của riêng bạn khi bạn cho rằng điều đó có thể giúp ích cho họ.
Đừng gán PR của bạn cho toàn bộ thế giới. Hãy chọn người đánh giá của bạn một cách cẩn thận để nhận được đánh giá phù hợp mà không phải đợi quá lâu để được phê duyệt.
Hãy cởi mở với những phản hồi, yêu cầu làm rõ, nói khi bạn không đồng ý (với sự tôn trọng) và luôn phản hồi các nhận xét.
Mọi người đều có nhiều PR để xem xét và có rất ít thời gian rảnh để làm. Nếu bạn xem xét các PR khác, bạn cũng sẽ tăng cơ hội nhận được đánh giá của mình.
Với tư cách là nhà phát triển cấp dưới, bạn có thể cho người khác biết khi bạn không hiểu một phần mã, vì bất kỳ nhà phát triển nào trong nhóm đều có thể hiểu được điều đó.
Thông tin thêm về nó trong bài đăng của tôi Làm cách nào để đưa ra đánh giá mã với tư cách là nhà phát triển cấp dưới? .
Mục tiêu của việc xem xét mã là kiểm tra các lỗi và các trường hợp khó khăn cũng như thách thức việc triển khai. Nó không nên được sử dụng để tìm hiểu các tùy chọn định dạng hoặc kiểu dáng nhỏ cũng như cho các cuộc thảo luận kiến trúc quy mô lớn.
Hãy sử dụng “tại sao không” thay vì “bạn nên làm”, hãy cởi mở và tích cực và luôn đề xuất giải pháp thay thế khi bạn yêu cầu thay đổi.
Không phải tất cả các nhận xét đều yêu cầu thay đổi và không phải tất cả các thay đổi được yêu cầu đều bắt buộc để PR được phê duyệt. Hãy nêu rõ nhận xét của bạn nếu thay đổi không khẩn cấp.
Trước khi công khai đánh giá của bạn, hãy đọc lại từng nhận xét: kiểm tra giọng điệu bạn sử dụng và đảm bảo bạn cung cấp tất cả ngữ cảnh để trợ giúp người gửi PR.
Bạn không muốn người đánh giá đợi bạn chấp thuận hai ngày sau khi họ thực hiện tất cả những thay đổi mà bạn yêu cầu. Khi bạn xem xét nó, giả sử bạn sẽ chấp thuận nó ngay sau khi thực hiện xong tất cả các bản sửa lỗi.
Khi một chủ đề bình luận trở thành một cuộc tranh luận trong PR của bạn, tốt hơn hết bạn nên cắt nó đi và đề nghị tiếp tục thảo luận ở nơi khác, ví dụ như trong chủ đề Slack. Nếu cần, hãy dành một cuộc họp cho nó và/hoặc có sự tham gia của bên thứ ba.
Đó là nó! Bạn nghĩ gì về những lời khuyên này? Bạn có thể nghĩ ra một mẹo nào bạn muốn chia sẻ với các nhà phát triển khác không?
Chia sẻ chúng ở đây trong phần bình luận 👇
Nếu bạn thích những mẹo này và muốn tìm hiểu thêm, hãy xem cuốn sách Pull Yêu cầu và Đánh giá mã của tôi, nó hoàn toàn miễn phí!
Cũng được xuất bản ở đây .