요약: - pr 1개는 1가지의 일을 해야함(SRP) - 1가지의 일에만 집중 - 그래야 리뷰하기 편함 - 여러가지의 커밋으로 이루어지더라도 1가지의 일을 진행 - 하지만 커밋 1개로 진행하는게 적절해보임
@zbflzlxl Жыл бұрын
영상 계속 올리시는거 보니까 답을 맞춘 사람이 있는 모양이군요 ㅎ
@user-vm3ly3ex6w Жыл бұрын
좋네요😊
@yjg02211 Жыл бұрын
이전에 학원에서 코드 리뷰를 해보고 싶어서 도입하려 노력해본 적이 있었는데, 당시 pull requests를 보며 리뷰를 하려고 해도 뭘 했는지를 모르니까, 작성자가 부연설명을 해도 파악하기가 힘들더라고요. 그 당시에는 처음 코드 리뷰를 하기도 했고, 아는 지식이 없으니까 리뷰를 못했다고만 생각했는데... 정말... 생각도 못했네요. 제가 보지 못하고 놓치는 부분들을 친철하게 알려주셔서 정말 감사드립니다.
@Kevinyo1538 Жыл бұрын
기능단위로(쪼갤 수 있는 최소한의 단위?) pr하지않으면 '나는 올릴테니 너는 알아서 코드리뷰 해라' 느낌이 강하더라구요.. 팀프로젝트 할 때 이런 규칙을 정하고 해도 따르지 않는 경우가 많아서 코드리뷰 이후에도 버그가 많이 발생해서 힘들었던 기억이 있네요 ㅠ
@ejoongseok Жыл бұрын
안녕하세요 기선님! 좋은 내용의 영상 제작해주셔서 감사합니다. PR 1개는 한 가지 일만 해야 한다는 아주 중요한 말씀을 해주셨는데요.🙂 한 가지 일이라는 것이 웹 어플리케이션 개발에서는 하나의 기능추가(API)라는 관점으로 봐도 괜찮을까요? 가령 회원가입 기능을 만들어야 한다고 할 때 저의 방식은 회원가입 기능을 개발하는 것(Controller-Service-Repository-Test 코드 작성)은 하나의 일이라고 생각하여 하나의 기능당 PR 1개 같은 방식으로 PR을 생성하고 있었습니다. 이런 방법이 영상에서 말씀해주신 한 가지 일에 해당하는 것인지 궁금합니다. 추가로, 이미 운영 중인 서비스에서 코드를 추가해야 할 때 보이스카웃 원칙에 따라 관련된 기존 코드의 리팩토링을 하는 경우가 있을 텐데, 이럴 때 코드 추가와 리팩토링을 하나의 일로 봐야 할지 궁금합니다!
@GeunChangAhn Жыл бұрын
맞는지 모르겠지만 저의 경험을 공유합니다. 신규 기능 개발인 경우에는 사실 원칙상으로는 개발TASK에는 리팩토링을 하지 않습니다. 나중에 개발 완료후 리팩토링 모드가 가동됩니다 ^^ 다만 위에서 직접적으로 질문 주신 "이미 운영중인 서비스서 피치 못할 샹황"일 때.. 저희는 다르게 보고 코드 추가떄 리뷰를 하고 리팩토링도 리뷰를 합니다 그래서 PR한번에도 코드 리뷰를 여러번 PR을 올리고 리뷰어는 계속 aprrove를 합니다. (당연히 머지 하거나 클로즈하지 않습니다) 해당 PR 리뷰올릴때는 현재 목적인 커멘트를 달고 PR을 올려서 해당 관점만 집중해서 리뷰를 하며 혹시 다른 관심사의 개선점이 발견되어도 일단 aprrove를 합니다 그리고 아까 발견했던 관심사의 개선점을 개선후 개선점 커멘트와 함께 다시 PR을 올리고 리뷰를 합니다. 이런식으로 한 PR이지만 한 PR당 여러 리뷰를 거치며 한 리뷰를 단일 관심사로 하고 있습니다. 해당 PR의 구현이 끝나면 최종 리뷰가 끝나고 나서 최종 PR을 올렸을때 그때 권한을 가진 분이 최종 머지를 하고 close합니다. 도움이 되셨으면 합니다. 혹시 저희 방법이 틀렸거나 더 좋은 방법이 있으면 마구마구 답변 주시면 감사하겠습니다.
@ejoongseok Жыл бұрын
@@GeunChangAhn님 답변 감사합니다.👍 운영 중인 서비스에서 코드 추가와 리팩토링을 함께 해야 할 때 PR 전략에 대해 말씀해주신 내용을 제가 이해한 게 맞는지 여쭤봅니다! - 운영 중인 서비스에 우선 추가해야 할 코드만 적용 후 PR 생성(리팩토링할 코드가 보이지만 일단 패스) - 생성한 PR에서 추가해야 할 코드에 대해 reviewer가 approve 함. - 코드 추가할 때 보였던 개선점에 대해 리팩토링 후 현재 PR에 commit&push - 새로 push 된 코드에 대해 reviewer에 알림이 가고 reviewer는 리팩토링한 코드에 대해 리뷰 위와 같은 사이클로 코드 추가 및 리팩토링이 완료되면 생성한 PR을 merge. 저의 경우에는 신규 웹 애플리케이션을 개발할 때 하나의 기능을 한 가지 일(하나의 관심사)로 보고 개발을 진행하고 있습니다.🙂 Ex) 회원 등록 제가 회원 등록이라는 기능을 개발할 때 작업하는 방식은 아래와 같습니다. - 회원 등록에 대해 지라 티켓을 생성 [title: 회원 등록 API 개발] - 생성한 지라 티켓 작업용 브랜치 생성 [name: feature/create-user] - 생성한 브랜치에서 개발 후 PR - 코드 리뷰에서 수정 사항 발견 - 수정사항 반영하지 않고 일단 merge - 수정사항 반영할 지라 티켓 생성 [title: 회원 등록 API 수정사항 반영] 후 위와 같은 사이클로 진행 회원 등록이라는 기능을 한 가지 일로 보다 보면 가끔 개발 중간에 제가 예상했던 거보다 복잡한 비즈니스 로직이 있거나 할 때 작업 중인 브랜치에 작업량이 점점 커질 때가 있는데 이럴 때 더 작게 나눠서 PR을 올리고 더 빠른 주기로 피드백을 받고 싶은데 회원 등록이라는 한 가지 일을 어떻게 더 작게 나눠야 할지 고민될 때가 있습니다.🥲