코드 리뷰 어쩜 좋아?

최근에 프로젝트를 진행하면서 여러 가지 고찰을 하게 되었는데, 글로 남겨두면 좋을 거 같아 기록합니다.

그중 오늘은 코드 리뷰에 대한 저의 생각을 적어 보기로 합니다.

---

왜 코드 리뷰를 해야 하는 가?

저는 무슨 일을 하던 당위성을 먼저 찾고, 거기에서 동기부여를 얻는 편입니다. 

그래서 오늘의 주제인 코드 리뷰에 대한 당위성을 설명할게요.

 

너 자신을 알라.

저의 첫 코드 리뷰에요. 

18개 파일 체인지에 79번의 대화가 오고 갔죠.

 

 

당시 느꼈던 감정은 

1.  너무 사소한 거에 트집 잡는데?

2. 내가 이렇게 무능하다고?

3. 리뷰어를 어떻게 대해야 할까?

등등 의 감정이었습니다.

 

또 자신의 무능력함과 답답함으로 우울감 마저 느껴질 정도였죠. 

`이걸 한다고 진짜 내 실력이 늘어? 단편적인 지식만 습득하는데? `

`이렇게 힘들고 짜증 나는 걸 계속해야 하나?`

라는 말을 수 십 번은 되뇐 것 같아요.

 

지금 생각하면 당시의 괴로움은 부족한 자신을 받아들이는 과정이었어요.

특히, 전공 자바 수업에서 높은 점수를 받았던 터라 스스로를 자바를 잘한다고 착각했을 시기입니다.

정작 자바 책은 딱 1권만 읽은 채로 말이죠.🥲 (역시 책 1권만 읽은 사람이 제일 무섭다는 말이 맞는 거 같습니다만...)

 

우매함의 봉우리 정상에서 무서운 줄 모르고 서 있었습니다 ㅋㅋ

그걸 절망의 계곡까지 떨어뜨려주신 당시 리뷰어에겐 아직도 감사한 마음이 큽니다.

힙하다

예전에 우연한 기회로 유대인들의 교육 방식에 대한 다큐멘터리를 본 기억이 있어요.

일명 '하부루타'라고, 한 주제를 가지고 끊임없이 토론을 하는 것이었죠.  

이름부터 학습 방법까지 힙해서 아직도 기억에 남아요.

 

물론 코드 리뷰는 하부루타와는 다르게 비동기적인 커뮤네이케이션이지만,

공통된 주제를 가지고 상대와 토론을 할 수 있다는 것에서 아주 성격이 비슷하다고 생각합니다.

 

코드리뷰도 하부루타처럼 힙할까요? 

코드 리뷰 문화가 있다면, 누군가가 내 코드를 본다는 긴장감은 생각보다 짜릿합니다. 

단, 코드에 확실히 근거를 가지고 있다면 말이죠. 

자신의 근거에 태글을 걸 동료가 있다고 생각하면, 재미는 x2가 됩니다.

(너무 기대하진 말아요... 대부분의 경우 파훼되는 근거에 속상할 수도 있으니까요..)

 

코드를 무지성을 작성하다가도 '누가 내 코드 보겠지?'라는 생각이 들면, 작성했던 코드를 Ctrl + Z 연타와 근거를 

생각해 나가는 자신을 보게 될 거에요.

 

또 근거를 찾다 보면, 더 확실한 정보, 더 깊은 원리를 찾게 보게 될거에요. (아마도? 일단 나는 그랬음) 

 

이것 말고도 코드 퀄리티를 높인다. 등등 여러 가지 있지만, 그게 와닿진 않아 생략하겠습니다.

---

어떻게 하면 좋나?.

둘러보기

코드 리뷰는 단순한 콘솔 애플리케이션에서부터 앤터프라이즈 애플리케이션까지 많은 영역에서 이루어집니다.

 

그래서 가장 먼저 자신의 환경을 둘러봐야 합니다. 

• 나를 리뷰해 줄 사람은 누구인지.
• 내가 리뷰할 사람은 누구인지.
• 나 또는 상대의 작업량이 얼마나 많은지.

등등 현재의 상황을 둘러보고 그에 맞는 그라운드 룰을 상대와 정합시다.

 

상황에 따라 아주 러프하게 질문해도 어떻게 리뷰할지/ 리뷰를 당할지 방향성을 잡는데 큰 도움이 되었던 것 같아요.

상대가 근처에 있다면 대면으로 만나서 나와 당사자의 현재 상태를 공유하는 것을 추천해요. 

정말 원하는 것들이 무엇이 알면 서로 행복한 리뷰 시간이 돼요.

 

규칙

개인적으로 규칙, 원칙이란 말을 굉장히 싫어해요.

마음 같아서는 '그냥 하고 싶은 대로 해라'주의지만,

해야 할 것과 하지 말아야 할 것은  명확하다고 생각해요.

 

그래서 몇 가지 규칙을 제안하고자 합니다.

 

리뷰할 때

1. 상대를 리뷰했다면, 그 코드에 대한 책임은 나에게도 생긴다.

이게 제일 중요한 마인드 셋 같아서 적어봅니다.

가끔 보면 테스트가 터지는데도 "잘하셨네요~~. 이 부분 이 부분 수정만 하시면 되겠네요. 이만 approve 합니다."

하는 사람들을 보면 정말 책임감이 없다는 생각 마저 듭니다.

만약에 배포했다가 서버 터지면 누구 책임인가? 다시 한번 생각해 필요가 있어보이네요.

 

2. 코멘트의 의도 구체적으로 전달해자.

코드 리뷰는 앵간해서 비동기 커뮤니케이션으로 진행되죠.

상대가 바쁘다면, 피드백이 늦어질 수도 있는데,

굳이 추상적인 말로 피드백 사이클 한 번 더 돌게 할 필요 없지 않을까요?

 

3. 정답 보단 질문을 

이건 내가 리뷰를 당하던 입장에서 많이 느낀 점입니다.

best practice를 리뷰로 알려준다면, 딱 거기까지가 끝이에요.

질문을 한다면, best practice가 무엇인지 찾아가는 과정에서 많은 부수 지식들을 얻는 경험이 될거에요 

 

4. 스타일로 시비 걸지 말자.

물론~~ 팀 컨벤션이 정해져 있다면 적극적으로 시비를 거는 것이 맞겠지만, 그게 아니라면 굳이라는 생각이 들어요.

서로 바쁜 시간 쪼개서 코드리뷰하는 거 아닌가요? 불필요한 리소스 낭비하지 말아요.

 

리뷰받을 때

1. 피드백 늦어지면 알려주기

상대방도 바쁘다. 언제까지 우리의 리뷰 요청을 기다리게 만들어선 안됩니다. 피드백이 늦어진다. 늦어지는 이유와 함께 메시지를 보내봅시다.

 

2. 코멘트에 반항해 보기

상대가 권위 있다 하더라도, 코멘트들을 모두 '네 반영하겠습니다', '네 맞는 말인 거 같아요'라고 하면 리뷰어/리뷰이 모두 코드 리뷰가 정말 재미없을 거에요. (너무 반항만 하는 건 쫌... 별로 긴 한데 기준을 명확히 세웁시다.) 

 

3. 위축되지 말기

상대방이 너무 잘해서 내가 초라하게 느껴져도 위축되지 말시다! 내 페이스를 완전히 잃어버리게 됩니다. 저는 이럴 때 상대의 지식을 모두 흡수한다는 생각으로 뻔뻔하게 나갑니다. 이건 각자 부딪혀 보며 몸으로 익힙시다. 제일 어려운 부분인거 같아요.

---

 

지금까지 나만의 코드 리뷰 방식을 작성해봤어요.

 

다음 편에서는 제가 프로젝트를 진행하면서 어떻게 리뷰 문화를 팀에 녹이려고 했는지 작성해보겠습니다.