수년간 코드를 작성하고 검토하면서 저는 더 나은 끌어오기 요청을 작성하고 코드를 보다 효율적으로 검토할 수 있는 몇 가지 비밀을 배웠습니다. 나는 이 모든 비밀을 내 새 책인 에 쏟아 부었지만, 여기서는 이미 개발자 활동에 사용할 수 있는 13가지 팁이 포함된 미리보기를 볼 수 있습니다. Pull Requests and Code Review 더 많은 팁을 생각해 볼 수 있나요? 댓글로 공유해주세요 😉 1. 코드가 검토 준비되기 전에 PR을 작성하세요. PR 초안은 기능을 계속 작업하는 동안 아이디어를 정리하고 진행 상황을 문서화하는 데 도움이 됩니다. 2. 사람들이 당신의 PR을 리뷰하고 싶게 만드세요 빠르고 효율적인 검토를 얻는 가장 좋은 방법은 PR을 작게 유지하고 (필요한 모든 맥락을 포함하여) 잘 문서화하는 것입니다. 지금 훌륭한 코드를 제공하면 향후 PR 기회도 높아집니다! 내 무료 책인 더 많은 실제 사례와 실행 가능한 통찰력을 통해 이러한 모든 팁을 찾아보세요. Pull Requests and Code Review: Best Practices for Developers, Junior to Team Lead에서 3. PR의 첫 번째 리뷰어가 되어 보세요 리뷰어의 입장이 되어 질문을 예상하고, 도움이 될 수 있다고 생각되면 자신의 코드에 주석을 달아보세요. 4. PR에 적합한 리뷰어를 할당하세요. 당신의 PR을 전 세계에 할당하지 마십시오. 승인을 위해 너무 오래 기다리지 않고 관련 리뷰를 받을 수 있도록 리뷰어를 신중하게 선택하세요. 5. 댓글에 응답하세요. 피드백을 받아들이고, 설명을 요청하고, 동의하지 않는 경우(존경심을 가지고) 말하고, 항상 의견에 응답하세요. 6. 사람들이 당신의 PR을 리뷰하기를 원한다면, 그들의 PR을 리뷰해야 합니다. 모든 사람은 검토할 PR이 많지만 여유 시간은 거의 없습니다. 다른 PR을 리뷰하면 자신의 PR도 리뷰를 받을 확률이 높아집니다. 7. 주니어 개발자라도 코드를 리뷰할 수 있습니다. 팀의 모든 개발자가 이해할 수 있어야 하는 코드의 일부를 이해하지 못하는 경우 주니어 개발자로서 다른 사람에게 알릴 수 있습니다. 내 게시물에 대한 자세한 내용은 . 주니어 개발자로서 코드 리뷰를 제공하는 방법은 무엇입니까? 8. 코드 검토 중 올바른 사항을 확인하세요. 코드 검토의 목표는 버그와 극단적인 경우를 확인하고 구현에 도전하는 것입니다. 사소한 형식이나 스타일 선호도를 따지는 데 사용하거나 대규모 건축 논의에 사용해서는 안 됩니다. 9. 댓글에 올바른 어조를 사용하세요 “해야 한다” 대신 “안 될 이유”를 사용하고 개방적이고 긍정적이며 변화를 요청할 때 항상 대안을 제안하십시오. 10. PR 승인을 위해 변경이 필요한지 여부를 명확히 하십시오. 모든 댓글에 변경이 필요한 것은 아니며 요청된 모든 변경 사항이 PR 승인에 필요한 것은 아닙니다. 변경이 긴급하지 않은 경우 의견을 명확하게 기재하세요. 11. 제출하기 전에 리뷰를 검토하세요. 리뷰를 공개하기 전에 각 댓글을 다시 읽어보세요. 사용하는 어조를 확인하고 PR 제출자에게 도움이 되는 모든 맥락을 제공했는지 확인하세요. 12. 제출자가 귀하가 요청한 모든 변경 사항을 적용한 경우 PR을 승인합니다. 검토자가 귀하가 요청한 모든 변경 사항을 적용한 후 2일 동안 귀하의 승인을 기다리는 것을 원하지 않습니다. 검토할 때 모든 수정이 완료되자마자 승인할 것이라고 가정하세요. 13. 일부 충돌은 댓글로 해결할 수 없습니다. 댓글 스레드가 PR에서 논쟁거리가 되면 해당 스레드를 중단하고 Slack 스레드 등 다른 곳에서 토론을 계속하도록 제안하는 것이 좋습니다. 필요한 경우 회의를 열거나 제3자를 참여시키십시오. 그게 다야! 이 팁에 대해 어떻게 생각하시나요? 다른 개발자에게 주고 싶은 팁이 하나 있나요? 여기 댓글로 공유해주세요 👇 이 팁이 마음에 들었고 더 많은 것을 배우고 싶다면 내 책인 확인하세요. 무료입니다! Pull Requests and Code Review를 게시되었습니다. 여기에도
