공통
안녕하세요 멘토님!
이번 프로젝트를 진행하기 전에 '코드리뷰'에 관해서 멘토님께 의견을 구하고 싶은 부분이 있습니다.
팀원 모두 이전 프로젝트를 진행하면서 PR에 대한 코드리뷰를 진행하고 approve를 받으면 merge하는 방식을 사용했었습니다.
코드리뷰를 진행하는 상세한 방법에서는 조금씩 차이가 있었지만,
공통적으로 아쉽다고 느낀점은 팀원들이 자신의 일을 진행하느라 코드리뷰가 '형식적'으로 진행 되었다는 점이었습니다.
이러한 점을 해결하기 위해서 '코드 리뷰를 해줄 파트너 정하기, PR이 올라오면 지정된 시간 내에 리뷰해주기, 특정 시간을 정해놓고 리뷰를 진행하기'등의 방법을 생각해봤습니다.
그러나 각각의 방법들이 단점이 존재한다고 느껴져서 코드리뷰를 어떻게 진행할지 정하지 못하였습니다.
그래서 멘토님께 어떤 방식으로 코드리뷰를 진행하면 좋을지 조언을 듣고 싶습니다.
멘토님 답변
PR이 올라오면 리뷰어는 아래와 같은 과정을 거칠겁니다.
- 어떤 작업을 한 것인지 확인하고
- 잘 작업했는지 확인이 되면 merge
여기에서 리뷰어는 2가지 리소스가 듭니다.
- 컨텍스트를 이해하는 시간
- 기준에 맞게 잘 작업했는지 코드 체크하는 시간.
- 기준) 가독성, 컨벤션, …
이 시간을 효율적으로 보내기 위해서
- 리뷰이는 리뷰어가 잘 리뷰할 수 있도록 장치를 마련하고
- 리뷰어는 리뷰이가 피드백을 빠르게 이해할 수 있도록 피드백을 잘 주어야합니다.
말씀하신 방법도 대상자를 지정하거나, 시간의 룸을 아예 잡는 것도 좋은 방법입니다!추가적으로 효율적으로 피드백을 줄 수 있는 장치를 마련해서 리뷰자체의 부담을 줄이는 것도 고려해보시면 좋을 것 같아요.아래는 각 대상자별로 할 수 있는 방법들입니다.<리뷰이: 리뷰를 올리는 사람>목표: 리뷰어가 부담없이 잘 리뷰할 수 있도록 한다.
- 양의 부담을 줄인다. - 너무 많은 코드를 PR에 올리지 않는다.
- line수를 기준으로 기준을 잡는 것이 좋습니다.
- e.g. 300줄 이하의 PR을 올린다.
- 만약 양이 많아진다면, 커밋순으로 리뷰가 가능하도록 커밋을 잘 정리해서 올리는 방법이 있습니다.
- 약간의 훈련이 필요하므로, 적절히 도입해보셔도 좋을 것 같네요.
- 빠르게 나의 작업을 이해할 수 있도록 한다. - PR 본문에 상세하게 작성하는 방법 (PR template을 같이 구성하는 것도 방법입니다.)
- 중점적으로 봐줄 리뷰 포인트 리스트업
- UI수정이 있다면, 이미지 캡쳐본을 반드시 올린다.
- …
- 피드백 수용 이후에는 수정이후에 해당 리뷰어에게 다시 request를 보내거나 멘션을 꼭 해서 리뷰해준 사람에게 다시 요청을 날립니다.
- 기타) 꼭 봐야할 리뷰어는 지정한다.
- 이전에 유사한 코드를 개발했던 사람이거나, 의존성이 있는 개발을 진행하는 담당자를 할당하면, 컨텍스트 이해가 다른이보다 빨라 리뷰의 퀄리티나 속도가 올라갈 수 있습니다.
- 기타) 리뷰를 수용했지만 수정하기에 수정사이즈가 클 경우
- 본인의 리소스와 일정을 확인하시고, 적절한 판단을 해야합니다.
- 시간이 부족할 경우 우선순위 높은 리뷰만 수정하고, 나머지 우선순위 낮은 작업은 ‘백로그‘화 해서 추후에 수정하도록 작업량을 분리하는 것도 방법입니다.
<리뷰어: 리뷰를 하는 사람>
- 리뷰 요청이 오면 최대한 당일에는 피드백을 완료한다. 라는 규칙을 세워서 리뷰를 빠르게 진행하도록 합니다.
- 컨텍스트 스위칭이 발생해서, 본인의 작업을 하는 와중에 진행하기에는 부담이 있을 수 있습니다.
- 훈련이 필요한 부분이라, 적응해보시려고 노력해보시면 좋을 듯 합니다.
- 빠르게 진행이 안되면, 리뷰어에게는 블로커가 됩니다. ‘내가 빨리 리뷰해야 저사람 일정이 늦어지지 않는다’로 생각하시고 리뷰해주시는것도 방법일듯합니다.
- 리뷰의 우선순위 표기하기
- 코드 리뷰를 하다보면, 여러가지 관점으로 리뷰를 할텐데, 리뷰를 받는 사람은 받은 리뷰의 우선순위가 어느 정도인지 모를 겁니다. -> 이렇게되면 모든 리뷰를 다 고려해야한다고 생각할 수 있음
- 이를 위해서 리뷰에 우선순위를 표기하는 것을 제안드립니다.
- 뱅크샐러드의 리뷰문화 블로그 공유드립니다.
- pN을 표기하는 부분 읽어보시면 도움이 되실 것 같습니다.
- pN과 PR의 comment/request change/approve를 연관지어서 PR리뷰를 해보시는 것도 방법입니다.
깃헙 연동
- slack에 깃헙을 꼭 연동하시길 바랍니다.
- github에서 reminder를 설정하면 특정 시간대에 리뷰를 받아야할 내역들을 slack으로 받을 수 있습니다.
리뷰에 대해서 특정 기간동안 회고하기
- 리뷰 과정을 회고하는 시간을 가져봐도 좋습니다.
- 어떤 부분이 아쉬웠는지, 개선해야하는지를 회고하고 액션아이템을 뽑아내보셔서 개선해보는 것도 시도해보시는걸 권장드려요.
PR에서 무슨 피드백을 주지?목표: 작업자가 못보았던 부분을 찝어주시는 것. 백지의 눈으로 확인해서, 가독성을 올려주는 것
- 가독성은 무조건 피드백하시길 권장드립니다.
- 단순하게 생각해서, 내가 바로 읽었을 때 이해가 바로 안가면 가독성이 안좋은 것입니다.
- 컨텍스트가 모르는 사람이 읽어도 어느정도 이해할수 있는 수준이 되도록 해야합니다.
- 컨벤션
- 아마 컨벤션을 잡으실텐데, 통일성을 해치는 코드나 패턴들에 피드백을 주시는 것이 좋습니다.
- 에러 핸들링: 에러가 발생할 수 있는 케이스를 잡아주시는 것