개발자라면 GIT과 GITHUB을 땔 수 없을 것이다.
엄청난 시간을 보내는 것은 아니지만 작업물의 공유와 관리, 작업물 리뷰를 위해서 무시할 수 없는 시간을 사용 중 일 것이다.
현재 우리 백 앤드 파트에선 이렇다 할 PR에 대한 규칙이 없는 상태였다.
그래서 PR의 제목, 내용이 프로젝트와 누가 올리냐에 따라 천차만별로 다르게 올라오기 때문에 PR을 올리는 사람이나 보는 사람 둘 다 핵심을 놓치게 되는 이슈들이 발생했다.
이런 이유로 PR 템플릿을 만들어 최소한의 규칙을 정하기로 하였다.
PR 템플릿을 만드는 가장 큰 이유는 PR을 올리는 사람과 받는 사람 간의 원활한 소통을 위한다고 생각하기 때문에 파트원들의 요구사항을 수집할 필요가 존재했다.
파트원들과 회의를 통해 나온 주요 요구사항들이었다.
보통 PR을 리뷰할 때 PR의 제목이나 내용에 적긴 하지만 이런 부분이 규칙처럼 정해져 있지 않아
어떤 사람은 캡처까지 하면서 잘 전달해 주시는 분들이 있는 반면, 어떤 분들은 간략하게 글로만 전달하는 분들도 있었다.
따라서 각 내용들이 어디에 적어야 하는지를 명시한다면 PR을 볼 때 어떤 내용인지 쉽게 확인이 가능하고 부족한 내용을 의식적으로 채우게 된다.
또한 서버 작업을 하다 보면 단순히 코드의 변경사항뿐 아니라 개발 환경에 따라 인프라(DB, 웹서버 등) 변경사항들을 올리는 경우도 있다.
이런 부분은 로컬 개발 환경에 반영해야 될 수 있기 때문에 이런 내용의 변경사항을 공유하는 부분의 니즈가 있었다.
이전에 이런 내용들이 사람에 따라 PR에 포함되는 게 아니라 슬릭과 같은 메신저로 공유가 된 적이 있었는데 관련 히스토리 찾기가 힘들어서 고생을 하고 있었다.
작업 내용 ⚒️
- (작업한 내용을 기록해 주세요)
리뷰어 참고 사항 🤔
DDL
(DDL Query문이 있을 경우 넣어주시고, 없을 경우 없음을 표기해 주세요.)
참고 자료 🚀
- (기획서, 지라 티켓, 슬랙 등 관련된 문서를 공유해 주세요)
앞선 요구사항을 종합하여 이런 형태의 PR 템플릿을 파트에서 사용하게 되었다.
물론 완벽한 형태는 아니라서 아직까지 자잘한 시행착오가 있는 상태이다.
하지만 이전에 날것으로 작성했던 것에 비하면 확실히 정리된 상태들의 PR들을 볼 수 있었고 히스토리 관련된 부분도 PR에 대부분 적혀있기 때문에 앞으론 히스토리 찾아서 헤맬 필요가 없어졌다!
템플릿을 적용하고 몇 번 해보다 보니 PR의 상태와 목적을 확인하고 싶은 니즈가 느껴졌다.
기능용 작업인지, 테스트용 작업인지, 리팩토링 작업인지, 아직 작업 중인 PR 인지, 배포용 작업인지 등등
이런 내용을 PR에 쓸 수도 있지만 이런 내용만 따로 보거나 PR의 리뷰의 우선순위를 위해서 굳이 PR 내용을 보지 않고도 확인하고 싶어 했다.
그래서 PR에 label를 달아서 해결하기로 했다.
예시)
label을 붙임으로 어떤 작업인지 굳이 제목이나 내용에 쓰지 않아도 바로 알 수 있게 되고
테스트만 있는 PR이거나 작업 중인 PR은 리뷰가 급하지 않기에 우선순위를 정할 수도 있었다.
그리고 github에서 label에 따른 필터링 기능을 제공하기 때문에 히스토리를 찾기가 훨씬 더 수월해졌다.
예전에 나도 PR을 올리면서 이렇게 대충 올려도 되나? 싶은 생각이 들 정도로 대충 올렸던 날이 많았다.
하지만 템플릿 적용 후 의식적을 내용을 채우기 위해 바뀌는 모습도 느껴지고 이렇게 정리가 되다 보니 리뷰 시 큰 도움을 많이 받았다.
이전에 남의 코드를 볼 때도 PR 내용이 부실하면 코드를 봐도 뭔 작업인지 이해를 못 할 때가 많았는데 그런 경험이 줄었고
리뷰를 원하는 부분도 명시할 수 있어서 그런 부분의 논의가 좀 더 활발해진 점 또한 좋은 점이었다.