[🌱 인프콘 세션 후기 2 - PR vs SC]

인프콘 세션 후기 그 두번째를 올립니다. [👀 좋은 코드리뷰란?] > 코드 변경 크기, 작업 명확성, 빠른 속도 좋은 코드 리뷰는 해줘보고도 싶고 받아보고도 싶은 그렇기에 더 어려운 것이라 생각합니다. 가령 어떠한 기능을 만들 때 브랜치를 만들기 귀찮거나 이전 작업의 문제가 거슬려서 이것저것 고치다보면 리뷰어의 손에는 500줄이 넘는 코드의 파도가 밀려오게 되는 것 같습니다. [🌊 코드의 파도 속에 빠지는 리뷰어 🫠] 시간이 없는 리뷰어는 일단 큰 문제가 없는지 확인 한 후에 '일단' 머지합니다. 그리고 이때부터 지옥이 시작됩니다. 이런 수정들이 쌓여 conflict나 문제가 발생해도 리뷰에서 거르지 못합니다. 결국 모든 작업을 롤백하거나 그 때부터 원인을 찾게 됩니다. 당연히 배포는 늦어집니다. [Stacked Changes를 쓰면 뭐가 달라? 🤷‍♀️] 보통 이렇게 작업합니다 1. 하나의 피처 브랜치를 따서 2. DB commit 3. 비즈니스 commit 4. UI commit 5. PR (그리고 리뷰어의 고통) 이 방식을 바꿔보는 겁니다 1. 하나의 브랜치를 따서 2. DB commit 3. DB에 대한 PR을 보내고 이어서 비즈니스 브랜치를 2의 작업 브랜치에서 딴다 4. 2-3의 과정을 UI에서 반복한다. 5. 모든 작업이 끝나면 UI -> 비즈니스 -> DB -> 마스터로 병합한다. 6. 리뷰어는 이미 작은 단위의 작업을 f/u하고 있었으므로 리뷰하기 쉬움 확실히 리뷰어 입장에서 리뷰를 하는 부담이 줄어들 것 같긴 하네요 🤔 [PR vs SC 정리] PR 1. 메인 브랜치에서 브랜치를 딴다 2. 기능 단위의 변경 3. 작업 전체 변경분 비교 4. 변화를 메인과 비교 SC 1. 이전 변화가 일어난 브랜치에서 브랜치를 딴다 2. 코드 변화 단위 변경 3. Stack 별로 비교 4. 변화를 하나하나 쌓아나간다. [언제 PR을 쓰고 SC를 쓸까?] - PR : 여러 팀이 함께 작업하는 경우, 잦은 리뷰 처리가 어려운 경우 - SC : 작은 변경이 많은 경우, 팀 내에서 빠르게 개발을 해야 하는 경우 이미 규모가 있는 팀이라면 PR에서 SC로 가기 힘들 것 같지만, 빠르게 MVP를 만들어봐야 하는 작은 규모의 팀에선 SC를 사용해볼 수도 있을 것 같습니다. 코드 리뷰에도 여러 전략이 있다는 걸 알게 되네요.