코드 리뷰 잘 요청하는 법

주니어 개발자에게 코드 리뷰란

주니어 개발자일수록 코드리뷰가 굉장히 중요하다.

코드 리뷰만큼 실력있는 동료에게 배울 수 있는 좋은 기회는 드물다.

많은 개발자들이 동료 개발자의 코드를 보고 와! 하는 경험을 했을텐데 그런 분들에게 배울 수 있는 시간인 만큼 최대한 신경 써서 코드 리뷰를 요청해야 한다.

리뷰어의 시간을 아낄 수 있는 방법을 쓰자

다른 사람의 코드를 읽는 일은 굉장히 어려운 일이다.

책으로 읽어도 저자의 의도를 파악하기 힘들 때가 많은데

코드로 다른 사람의 생각을 파악해야 한다!

게다가 코드 리뷰를 잘 해준다고 리뷰어에게 뭔가 특별히 돌아오는게 있지도 않다.

좋은 코드 리뷰를 하는 것은 동료에 대한 호의다.

따라서 리뷰어의 힘을 조금이라도 덜 들도록 애를 써야 한다.

1. Create PR을 누르기 전에 내 코드를 한 번 더 점검하자

PR을 만들 때 코드 리뷰 시스템에 내 코드가 어떻게 보이는지 확인 하자.

console.log나 쓸데없는 주석을 남기고 PR을 하는 일이 종종 있는데

신기하게도 여기선 눈에 아주 잘 들어온다!

반드시 내가 요청하는 코드가 어떤 상태로 보이는지 확인하자.

당연히 에디터 상에서 꼼꼼하게 확인하는 것도 꼭 해야 한다.

2. PR 최상단에 요약 내용을 달자

1. 어떠한 버그가 있었는지
2. 어떻게 구현하는지
3. 어떻게 고쳤는지

맥락을 잘 모르는 사람이 봐도 이해하기 쉽도록 요약해서 작성하자.

이걸 잘 작성 해두면 비슷한 문제가 생겼을 때 찾기도 쉽다!

노하우가 쌓이면 다른 사람이 문제 파악 하기도 쉽고 검색하기 좋은 PR을 작성할 수 있을 것이다. (난 아직 아님🙃)

3. 어떠한 기능/버그를 개발/수정 했는지 이미지로 보여주자 (FE 한정)

어떠어떠한 버그를 수정했다고 글만 남기는 것과 수정 전/ 수정후 이미지를 첨부하는 것은 큰 차이가 있다.

수정한 본인이야 맥락을 아니까 글로만 봐도 파악이 되는거지 솔직히 글만 봐선 뭘 고쳤다는 건지 이해 하기 힘든 경우가 있다.

FE 개발자는 버그 수정 내역을 이미지화 하기 쉽다.

그리고 이왕이면 정적인 이미지보단 애니메이션으로 올리는게 훨씬 좋다.

개인적으로 Gif 캡쳐 프로그램으로 Screentogif(window), LICEcap(mac)을 추천한다.

4. 타인이 집중해서 봐줬으면 하는 부분에 미리 코멘트를 남기자

코드 리뷰를 남기자마자 본인이 제일 먼저 리뷰 창에 가서 코멘트를 남기자.

코드 리뷰 하는 입장에선 리뷰하다 다른 이가 남긴 코멘트를 자연스럽게 보게 된다.

이슈를 처리하다 고민이 된 부분이나 확신이 들지 않는 부분을 강조할 때

PR 본문보다 코드에 직접 코멘트를 남겨두는 것이 훨씬 이해하기 쉽고 눈에 잘 띈다.

5. 코드 리뷰가 늦어져도 다시 잘 요청하자

각 회사별로 코드 리뷰 기한을 정했겠지만 일이 바쁘다보면 기한을 넘기는 경우도 종종있다.

뭔가를 열심히 개발했다면 빨리 반영하고 싶은 마음이 있을 수 있고 재촉하고 싶을 것이다.

다시한번 말하지만 좋은 코드 리뷰는 리뷰어의 호의이다!

최대한 유쾌하게 요청해보자.

개인적으로는 딱딱한 코드 리뷰보다 유쾌한 분위기의 코드 리뷰가 훨씬 좋았다.

6. Alarm bot이 없다면 만들어 보자

PR 요청이 오면 Slack으로 알람을 보내는 봇을 만들어서 쓸 수 있다.

팀원 중 한 분이 개발하여 도입했는데 코드 리뷰 요청을 따로 이야기 할 필요가 없어서 정말 좋았다.

혹시 사내에 봇이 없다면 도입하는 것을 추천한다.

7. 종종 감사의 마음 표현하기

최근 좋은 개발자 몇 분이 퇴사했다.

실력으로나 인품으로나 모자람이 없는 분들이었는데 참 아쉽다.

가장 아쉬운 점은 많이 배우고 있다는 감사의 뜻을 전한 적이 별로 없었다는 것이다.

개발자는 이직이 잦기 때문에 이별의 순간은 갑자기 찾아온다.

감사한 마음을 종종 표현하자.