프론트 팀 코드 리뷰 도입기 (과거 완료형)

이제는 전 회사가 된 곳에서의 내용이다.

회사 내에서 면접을 진행하면서 면접자들 중에 코드 리뷰에 대한 수요가 많은 것을 자주 느끼고 또한 저희 회사에서도 팀원이 늘어나면서 서로 중복 되는 코드들이 꽤 발생하고 타인이 코드의 이해도가 낮아 담당자가 없을 경우에는 장애 대응이 현저히 느려진다는 것이였다. 그런 상황을 몇 번 접하다 보니 자연스럽게 필요성을 조금씩 느끼면서 간소하게라도 코드리뷰를 진행하려 찾아보았다..!

코드 리뷰 왜 하는가?

많은 회사에서 하는 문화인 만큼 왜 하는지 찾아봤을 때 주 목적은 아래와 같다.

---

외롭지 않은 코딩

스스로 PR을 날리면서 Commit을 하게 되면 현타가 온다.

더욱 깔끔한 코드 & 조금은 더 통일된 코드

누군가 나의 코드를 본다는 것을 의식(?)해서 조금 더 신경 써서 변수나 로직 등을 배려하여 작성한다. 또한 오타나 간단한 오류를 사전에 발견 할 수도(?)

해당 프로젝트에 이해도 상승

자신이 작성하지 않은 서로의 코드를 보면서 이해도가 높아지고 또한 작성자는 코드를 설명하면서 이해도가 높아진다.

코드 리뷰 코멘트에 대한 등급

P1: 꼭 반영해주세요 (Request changes)

리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.

P2: 적극적으로 고려해주세요 (Request changes)

작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.

P3: 웬만하면 반영해 주세요 (Comment)

작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.

P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)

작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.

P5: 그냥 사소한 의견입니다 (Approve)

작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.

P1: 함수 qwe의 이름을 좀 더 명확하게 알 수 있도록 변경 부탁드립니다.
P4: 컴포넌트 이름 ~를 ~로 하는게 더 좋을 것 같아요.

PR

Pull Request - Example

## 작업 개요
고양이가 야옹이라고 내는 소리를 미야아옹으로 바꾸는 작업

## 작업 상세 내용

- '야옹' 소리 파일을 제거하고 '미야아옹' 파일 교체

## 비고
- 현재 '미야아옹'이라는 파일의 용량이 너무 크다 추후에 압축하여 최적화 시켜야 할 것 같다.

Pull Request - Template

File path: .github/PULL_REQUEST_TEMPLATE.md

## 작업 개요

## 작업 상세 내용

-

## 비고

코드리뷰 주의 사항

Commit과 PR은 작게 쪼개서 진행한다

너무 많은 양을 보기에는 리뷰어에게 부담스럽고 놓칠 수 있는 것이 많다.

리뷰어는 최대한 빠른 시일내에 리뷰를 진행한다

리뷰가 완료 되기 전까지 요청자는 시간이 붕 뜨기 때문이다.

코멘트는 명령이 아닌 의견임을 숙지하자

코멘트를 받는 사람이나 주는 사람이나 말을 이쁘게 요청하는 의미를 담아 해야 한다.

글을 마치며 👋🏻👀

확실히 조금 더 통일된 코드, 서로의 피드백 그리고 우리 팀에서 어떤 사출물들이 나오고 있는지 좀 더 이해가 잘 된다.

그리고 생각보다 다른 사람 코드 보는 게 재미있는 것 같다. 한 번에 많은 코드를 보면 머리 아프지만 아토믹하게 커밋을 쪼개고 그것들을 따라가면서 읽으면 생각보다 공부가 되는 부분도 있다.

하지만…! 이렇게 많은 이점이 있고 수요가 있음에도 많은 회사에서 지키지 못하는 이유는 하면서도 많이 느꼈지만, 생각보다 이상에 다가가는 것은 쉽지 않다. (ㅋㅋㅋ..)끝으로 컨텐츠 자체는 그저 두 사이트의 내용을 정리한 내용이지만 두고 보면 코드 리뷰 왜 하냐는 이야기를 할 때 생각날 것 같아서 정리했다. 😊

Reference 📎

코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드

코드리뷰가 쏘아올린 작은공 - 우아한형제들 기술 블로그