개발자
안녕하세요!! Code Review Rule을 만들고자 하는데 한 가지 인사이트를 얻고자합니다. 제가 궁금한 것은 Code Review를 어느 시점에 다들 하는지 궁금합니다. 저는 통합 테스트 환경에서 각자의 Feature들이 충분히 테스트된 후 기능에 문제가 없을 때 Code Review를 진행하는 방향으로 했으면 하는데 문제가 통합 테스트 환경에 배포하기 위해서는 develop에 merge가 되어야 하고 이렇게되면 Feature와 Develop간의 Diff가 없어 review가 어렵습니다. 여러분들은 어느 시점에 코드 리뷰를 진행하고 계신지? 그리고 위 문제와 비슷한 문제를 겪었다면 어떻게 해결 했는지 여쭤봐도 될까요??
답변 1
삭제된 사용자
2024년 04월 12일
안녕하세요. 질문주신 내용은 회사마다, 팀마다, 혹은 주변 환경에 따라 답변이 달라질 수 있는 질문인 것 같습니다. 질문자님께서는 통합 테스트 환경에서 각자의 feature들이 충분히 테스트된 후 기능에 문제가 없을 때 코드 리뷰를 하고 싶다고 하셨는데 만약 동시에 여러 작업자가 통합 테스트 환경에서 테스트를 해야하는 업무 구조에서는 오히려 더 불편할 수도 있을 것 같습니다. 현재 상황에 그럴 염려가 없다고 가정한다면, 그 다음으로 염려하시는 feature와 develop간의 diff에 관해서는 여러 해결책이 있을 것 같습니다. "통합 테스트 환경에 배포하기 위해서는 develop에 merge가 되어야" 라고 적어주신 것을 보면 develop에 올라간 내용이 통합 테스트 환경에 사용되는 것 같은데요. 그렇다면 develop 브랜치에서 테스트까지 완료된 내용을 main 브랜치에 PR 보내는 식으로 해도 됩니다. 아니면 "develop가 테스트 환경에 배포되어야 한다"는 제약사항을 없애고 feature 브랜치를 통합 테스트 환경에 배포해서 테스트를 진행한 후에 develop에 PR을 보내는 식으로 해도 될 것 같구요. 고민하시는 내용은 모두 팀에서 정할 수 있는 규칙에 가까운 것이라 가장 편한 방식을 고르시면 될 것 같습니다 :D
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
커리어리 AI 봇
GPT가 달아주는 답변입니다.
2024년 04월 11일
코드 리뷰는 디벨롭 브랜치에 병합되기 전, 즉 개발자가 작업을 완료하고 pull request를 생성한 시점에서 진행하는 것이 일반적입니다. 이렇게 하면 코드 변경 사항을 검토하고 이해할 수 있으며, 버그를 미리 발견하고 피드백을 제공하여 코드의 품질을 향상시킬 수 있습니다. Pull Request(PR) 단계에서 리뷰를 진행하면, 통합 테스트 환경에 배포하기 위해 develop에 merge가 필요한 문제를 해결할 수 있습니다. 우선 각기 다른 feature 브랜치에서 작업한 후 PR을 생성합니다. 이 때 PR은 develop 브랜치 대신 해당 feature 브랜치로부터 생성됩니다. 그런 다음, 동료 개발자들이 PR의 코드를 리뷰하며 코드의 올바름과 체계적인 설계, 그리고 잠재적인 문제 등을 체크합니다. Code Review가 완료되면 그제서야 develop 브랜치와 병합(merge)하여 최종적인 실제 환경 배포까지 진행합니다. 이러한 프로세스는 Git Flow나 Github Flow와 같은 버전 관리 전략을 사용함으로써 효과적으로 관리할 수 있습니다. 물론 프로젝트의 크기나 규모, 팀의 조직 구성에 따라 이 프로세스는 달라질 수 있으니, 여러 방법을 시도하고 팀에 가장 잘 맞는 방식을 찾아내는 것이 중요합니다.
지금 가입하면 모든 질문의 답변을 볼 수 있어요!