코드 리뷰 요청에 정성을 담아보자

습관의 중요성

나도 잘 못하기는 하는데 그래도 아무것도 안적는 사람들이 생각보다 많아서 적는다.

말 그대로 코드리뷰 요청을 보내는데 코드리뷰 본문에 아무것도 적지 않는 사람들이 종종 있다.

그게 나야 움빠 둠빠 두비두바

 

이렇게 본문이 텅~ 비어버린 코드리뷰를 보면 어떤 생각이 들까?

진짜 어렵다.

뭘 해줘야 하는지 길을 찾기가 너무 어렵다.

이렇게 되면 코드 컨벤션에 대해서만 주구장창 잡기도 한다.

 

내가 지금 재직중인 회사에는 아래와 같은 말이 있다.

코드리뷰도 정~~~~말 똑같다고 느낀다.

코드리뷰를 요청한, 만든사람이 본문에 내용을 잘 담아주면 코드 리뷰어가 방향성을 잡고 리뷰를 해주기 참~ 좋다.

 

나중에 취업하고 본격적으로 일할 때도 굉장히 중요한 요소이다.

내가 PR을 생성해서 코드리뷰를 요청했는데 본문이 텅 비어있으면

팀원들은 뭘 리뷰해줘야하는지 알 방법이 없다. 아니 알 방법이 file changes를 통해서 스스로 확인해야한다.

자기 업무만으로도 바빠 죽겠는데 언제 이걸 다 확인 할 시간이 있을까?

그냥 따봉 버튼 누르고 approve하지 않으면 다행이다.

 

코드 리뷰를 많이 해보지 않아 어색하다면 코드리뷰에 정성을 담는 습관을 들이도록 하자.

 

어떻게

그러면 어떻게 PR을 작성하는게 좋을까?

정성을 담아 PR 꾸미는게 끝도 없을것 같긴 한데

리뷰어의 입장에서 이정도만 있으면 참 좋았다~ 싶은거만 몇가지 적어야겠다.

 

본문에 고민한 부분 설명하기

과장 조금 섞어서 코드리뷰의 시작과 끝이 아닐까?

5년전 나의 PR

가장 단적인 예로는 위와 같이 구현하면서 궁금했던 부분에 대해 별도로 기재하는 방법이 있을것 같다.

구현하면서 궁금한 부분만 적는다기 보다 작업을 하면서 궁금한 부분이라고 봐주는게 좋을것 같다.

 

지금은 코드의 단적인 부분만 질문하지만 설계의 방향성을 질문하게 될 수 도 있다. (설계의 방향에 대해 논의하는게 더 중요하기도 하다.)

 

내가 PR을 작성하며 왜 이렇게 코드를 작성했는지 고민의 결과로 어떠한 형태가 되었는지 코드 리뷰어에게 컨텍스트를 알려줄 수 있는 좋은 찬스이니 본문을 적극 활용하도록 하자.

 

코멘트 적극 활용하기

더 나아가서는 코드리뷰 요청자가 먼저 comment 기능을 이용해 구현한 부분의 설명을 하이라이트해주는 방법이 있다.

이렇게 설명을 해줌으로써 코드리뷰어들의 부담을 덜어줄 수 있고 해당 코드의 컨텍스트를 쉽게 파악할 수 있게 도움을 줄 수 있다.

 

가이드라인 룰 정하기

이건 조금 유명한것 같은데

코드리뷰를 남길때 레벨을 설정해서 남긴 코드리뷰를 중요도를 나타내는 것이다.

내가 일하고 있는 팀에서는 5개의 단계를 이용해 코드리뷰를 하고 있다.

왜 이렇게 레벨을 나누나 싶은데

코드리뷰를 반영하다보면 그런 때가 있다.

 

"아 이것까지 지금해야하나? 엄청 사소한건데.."

물론 위 생각은 코드리뷰를 남기는 사람도 동일하게 생각한다.

그래서 중요도가 낮은 코드리뷰 사항까지 남기다보면 코드리뷰의 양이 많아지기도 한다.

 

이러한 상황에서 반드시 반영했으면하는, 논의를 반드시 거쳤으면 하는 사항에 대해서 코드리뷰어가 점수를 줄 수 있도록 코드리뷰이가 가이드라인을 제공하는것도 꽤 좋은 방법이다.

 

위와 같이 코멘트 앞에 접두사 처럼 항목을 붙이곤 한다.

반드시 위와 같은 포맷을 따라야하는 것은 아니다. 더 양질의 코드리뷰를 주고 받기 위함이니 형식은 얼마든지 달라질 수 있을것 같다.

 

답변 달기

진짜 사소한건데..

코드리뷰로 남겨둔 부분에 답변을 달지 않는 리뷰어가 진짜 생각보다 너무 많았다. 나도 그랬을까?

진짜 어떻게 하겠다는 건지 알수가 없다.

코드리뷰는 단발성 이벤트가 아니다.

상호간 대화가 오고가며 서로 성장하게 되는 과정이기도 한데 답변이 없으면 너무 힘이 빠진다.

어쩔땐 진짜 하기 싫어지기도 한다

동의하면 동의하는지, 동의하지 않으면 어떠한 이유에서 동의하지 않는지

이해가 되지 않으면 어떠한 사유로 이해가 되지 않는지

뭐라도 좋으니 적어주자 리뷰어도 사람이다~