주니어 때 코드리뷰 받으면서 꼭 지켰으면 하는 것들
작년까지 주니어였고 지금은 리뷰를 달아주는 쪽에 있는데, 양쪽 다 겪어보니 느끼는 게 있어서 적어봅니다. 물론 팀마다 문화가 다르니 참고만 하세요.
1. 리뷰 코멘트에 감정적으로 반응하지 않기
2. 왜 이렇게 짰는지 최소 한 줄은 남기기 (커밋 메시지든 PR 본문이든)
3. 리뷰 반영 커밋은 따로 찍어서 어떤 걸 고쳤는지 보이게 하기
4. 이해 안 되는 코멘트는 그냥 물어보기. "이해했습니다" 하고 넘어가면 나중에 또 같은 지적 받습니다
5. 300줄 넘는 PR은 그냥 안 올리는 게 정신건강에 이롭습니다
특히 3번, 5번이 실제로 체감이 컸습니다. 예전에 기능 하나에 리팩터링까지 한 PR에 다 때려넣었다가 코멘트 40개 받고 멘탈 나간 적이 있어요. 쪼개서 올리니까 같은 코드인데도 리뷰 속도가 두 배는 빨라졌습니다.
그리고 리뷰어 입장에서 하나 덧붙이면, 질문을 명확하게 해주는 게 정말 고맙습니다. "이 부분 이렇게 하는 게 나을까요?" 대신 "A 방식을 선택한 이유는 성능 때문인가요, 아니면 기존 코드 스타일 때문인가요?" 이렇게 물어보면 답을 훨씬 빨리 써줄 수 있어요. 결국 서로 시간 아끼자는 얘기입니다.
4 개의 답변
5번은 진리임ㅋㅋ 300줄 넘으면 리뷰어도 대충 훑고 Approve 눌러버림
주니어 때 기능 추가 + 네이밍 정리 + 안 쓰는 코드 삭제까지 한 PR에 몰아넣었다가 코멘트 60개 받고 진짜 멘탈 나갔음. 그때 시니어가 '너 혼자 리팩터링하지 마라, 리뷰어한테도 그건 노동이다'라고 해줘서 좀 이해됐어. 지금은 PR 올리기 전에 스스로 diff 보면서 '이거 이 PR에 필요한가?' 한 번씩 걸러내는데 그것만으로도 리뷰 받는 속도가 확 다르더라. 2번도 은근 중요한 게, 나중에 git blame 했을 때 왜 이렇게 짰는지 알 수 있으면 그게 제일 좋음.
글쎄 3번은 좀 애매하지 않나. 리뷰 반영 커밋을 따로 찍으라는 거랑 커밋 히스토리 깔끔하게 유지하라는 거랑 충돌하는 팀도 많아. 우리 팀은 머지할 때 스쿼시라서 반영 커밋이든 뭐든 다 뭉개지고, 오히려 '어떤 리뷰가 어떤 커밋에서 반영됐는지'는 PR 코멘트 스레드에서 보는 게 정석으로 잡혀 있음. 그리고 '무조건 지켰으면 하는 것들'이라고 단정하는데, 팀 문화 다르다고 위에 써놓고 아래에서 단정하는 건 좀 모순 같음. 근거가 '내 경험상'뿐이라 다른 환경에선 안 통할 수도.
4번 진짜 공감. 나도 '이해했습니다' 하고 넘긴 거 두 달 뒤에 똑같이 지적받음ㅋㅋ 그때 리뷰어가 '그때 왜 안 물어봤어?'라고 하셔서 더 민망했음. 그 이후로는 이해 안 되면 '제가 이해한 바로는 X인데, Y를 의도하신 건가요?' 이렇게 되물어보는데 이게 서로 시간 아끼는 지름길이더라. 리뷰어도 자기 코멘트가 애매했구나 하고 바로 알아채니까.