좋네요😊

맞는지 모르겠지만 저의 경험을 공유합니다. 신규 기능 개발인 경우에는 사실 원칙상으로는 개발TASK에는 리팩토링을 하지 않습니다. 나중에 개발 완료후 리팩토링 모드가 가동됩니다 ^^ 다만 위에서 직접적으로 질문 주신 "이미 운영중인 서비스서 피치 못할 샹황"일 때.. 저희는 다르게 보고 코드 추가떄 리뷰를 하고 리팩토링도 리뷰를 합니다 그래서 PR한번에도 코드 리뷰를 여러번 PR을 올리고 리뷰어는 계속 aprrove를 합니다. (당연히 머지 하거나 클로즈하지 않습니다) 해당 PR 리뷰올릴때는 현재 목적인 커멘트를 달고 PR을 올려서 해당 관점만 집중해서 리뷰를 하며 혹시 다른 관심사의 개선점이 발견되어도 일단 aprrove를 합니다 그리고 아까 발견했던 관심사의 개선점을 개선후 개선점 커멘트와 함께 다시 PR을 올리고 리뷰를 합니다. 이런식으로 한 PR이지만 한 PR당 여러 리뷰를 거치며 한 리뷰를 단일 관심사로 하고 있습니다. 해당 PR의 구현이 끝나면 최종 리뷰가 끝나고 나서 최종 PR을 올렸을때 그때 권한을 가진 분이 최종 머지를 하고 close합니다. 도움이 되셨으면 합니다. 혹시 저희 방법이 틀렸거나 더 좋은 방법이 있으면 마구마구 답변 주시면 감사하겠습니다.

​@@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을 올리고 더 빠른 주기로 피드백을 받고 싶은데 회원 등록이라는 한 가지 일을 어떻게 더 작게 나눠야 할지 고민될 때가 있습니다.🥲