여러 분들은 혹시 코드리뷰를 해보셨나요?
1. 코드 리뷰란?
코드 리뷰란 코드의 체계적인 평가로, 버그를 식별하고 코드 품질을 향상시키며 개발자 소스 코드를 학습하는 데 도움을 주는 것을 목적으로 진행하는 리뷰입니다.
기업이나 단체들도 이러한 코드리뷰를 통해 서로 지식을 공유하고 잠재적인 결함들을 찾아 버그를 사전에 예방하고 밝혀지지 않은 극단적인 사례나 기타 문제들에 대해 이야기를 나누면서 성장해나간다고 합니다. 실제로 2022 Global DevSecOps설문조사를 참여한 개발자중 76%가 코드 리뷰가 "매우 가치 있다"고 말했습니다.
2. 코드 리뷰시 주의 할점
1) 코드리뷰라는 점 인지하기
항공 분야에서 아래와 같이 유명한 말이 있다고 합니다.
in aviation, for example, people who greatly overestimate their level of skills are all dead
항공분야에서 자신의 기술을 과대평가 하는 사람들은 모두 사망하였습니다.
여러분이 코드를 계속 코드에 대해 공부하고 이를 바탕으로 리팩터링을 반복하다보면 코드에 애정이 생기고 마치 내 코드가 정말 잘 짜여졌다고 생각하게 됩니다. 그래서 나중에 코드 리뷰를 받을 때 마치 코드에 대한 비판을 나 자신에 대한 비판으로 이해해서 갈등의 시작이 되는 경우도 존재합니다.
따라서 여러분은 코드 리뷰 할때 항상 이것은 나 자신이 아니라 나의 코드에 대한 리뷰이고 상대방이 내 코드의 품질을 향상 시켜주기위해 해주는 조언이다 라고 스스로 자각하셔야 합니다. 또한 나의 코드가 완벽하지 않고 틀릴 수도 있고 실수 할 수도 있다는 것을 항상 인지하셔야 합니다. 절대 "내가 너보다 훌룡한 개발자야" 라는 생각으로 접근하시면 안됩니다.
2) 아 다르고 어 다르다
생각을 글로 전달하는 것은 굉장히 어렵습니다. 글에는 음성 톤, 표정, 분위기등이 담기지 않기 때문에 오해를 일으킬 가능성이 큽니다.
예를 들어보겠습니다.
여러분이 음식을 먹었는데 맛이없어서 이에 대한 피드백을 줘야한다면 어떻게 주시겠습니까?
같은 의도라도 어떻게 표현하느냐에 따라 상대방에게는 상처가 될수도 성장의 발판이 될 수도 있습니다.
3. 코드 리뷰전 준비하기
자 그럼 이제 코드리뷰를 본격적으로 시작하기 전에 어떤걸 준비하면 좋을까요?
1) 컴퓨터가 할 수 있는 일에 노력을 낭비하지 않기
자신이 짠 코드는 작성하면서 수 십번 수 백번을 봤기 때문에 매우 익숙합니다. 하지만 처음 보는 리뷰어 입장에서는 읽는것 자체가 인지적 부담이되는 고수준의 집중이 요구되는 작업입니다. 따라서 코드 리뷰전 꼭 Formater와 Linter를 사용해서 공백, 들여쓰기, 오타 등을 미리 처리해주시는 게 좋습니다.
2) PR 설명
리뷰어가 코드를 보기전 MR을 통해서 변경 사항을 쉽게 알 수 있도록 해준다면 코드 작성자의 의도도 명확하게 알 수 있고 코드를 이해하는 데 큰 도움을 줍니다.
3) 스타일 가이드 정하기
스타일 가이드에는 여러가지가 있습니다. 예를들어 Google/styleguide , airbnb/styleguide 등이 존재합니다.
그렇다면 왜 필요할까요 ? 여러분들이 코드를 작성하다보면 같은 기능을 구현하는데 있어서 사용하는 코드는 정말 다양합니다.
하지만 그중에서는 사용을 지양해야 하는 코드가 공통적으로 동의하는 것도 있지만 의견이 나뉘는 것도 있습니다. 그리고 그에대한 이유도 양측이모 두 충분히 가지고 있기 때문에 잘못하면 끝없는 논쟁으로 이어질 수도 있습니다.
실제로 forEach() vs for loop 로 몇년간 토론이 이어졌던 적도 있습니다. 해당 스레드 마지막에는 레포 관리자는 이렇게 글을 남겼습니다.
"`forEach`가 옳다고 여기든 그렇지 않다고 여기든 상관없습니다. AirBnB는 자신들의 의견을 가지고 있고, 그것에 동의하지 않는다면, 그것은 당신에게 강요되지 않아요"
이처럼 사람마다 코드에 대한 생각이 다르기에 기준점이 되는 스타일 가이드를 정하고 리뷰를 받기전에 어떠한 스타일 가이드를 바탕으로 작성했다고 알려주시면 더 좋습니다.
3. 효율적으로 코드 리뷰 하기
아래의 방법들은 다른 시니어 개발자나 특정 회사가 사용하는 방법입니다.
좋다고 생각되는 방법이 있으시다면 적용해보세요
1) 내가 먼저 리뷰 받고 싶은 코드에 코멘트를 남겨서 물어보세요
리뷰어가 내가 리뷰를 원하는 곳을 우연히 해주길 기다리기 보다는 미리 질문 내용을 해당 코드에 남겨 리뷰를 받는 것도 좋은 방법입니다.
2) 진심으로 칭찬해 보세요
저도 코드 리뷰 스터디를 운영해보았는데 가끔 잘못된 부분에만 집중하시는 분들이 있습니다.
물론 개선해야할 부분을 알려주는 것도 좋지만 동시에 좋은 부분이 있으면 칭찬하는 것도 좋습니다.
예를 들어 "오 이런 API가 있나요. 정말 유용해요", "왁 !! 이런 방법이 있었군요. 감사합니다 저도 활용해 보겠습니다." 라든지
분명 여러분이 보았을 때 좋은 점이 존재하기 마련입니다. 그런 점들은 코드 작성자에게 알려준다면 어떻게 구현하였을 때 좋은 반응이 있었는지 등을 체크하면서 더 완성도 높은 코드를 작성하는 데 도움이 됩니다.
3) 커뮤니케이션 비용을 줄이기 위한 Pn 룰을 활용해 보세요
Pn 룰은 뱅크샐러드에서 성장하는 회사에서 커뮤니케이션은 가장 큰 비용이라는 문제의식에서 이를 해결하기 위한 문화를 배경으로 탄생된 룰입니다. Pn 룰을 코드 리뷰 외에도 슬랙 등 텍스트로 커뮤니케이션을 하는 곳에서도 활용할 수 있습니다.
아래처럼 코드 리뷰의 코멘트에 코멘트를 강조하고 싶은 정도를 표기하면 좋습니다.
P1: 꼭 반영해 주세요 (Request changes)
P2: 적극적으로 고려해 주세요 (Request changes)
P3: 웬만하면 반영해 주세요 (Comment)
P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
P5: 그냥 사소한 의견입니다 (Approve)- P1: 꼭 반영해주세요 (Request changes)
리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.
- P2: 적극적으로 고려해주세요 (Request changes)
작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.
- P3: 웬만하면 반영해 주세요 (Comment)
작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.
- P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.
- P5: 그냥 사소한 의견입니다 (Approve)
작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.
4) 답보다는 스스로 고민하고 개선 방법을 선택할 수 있게 해보세요
업무와 코드 리뷰를 병행하는 건 쉽지 않은 일입니다. 업무량은 많은데 코드 리뷰까지 신경 쓰려고 하다보면 상세히 코드를 살펴보지 못하는 경우도 생깁니다. 그럴 때 리뷰어는 "000로 변경하세요", "000을 쓰세요"와 같이 현재 코드의 개선점을 찾아 답을 알려주는 리뷰가 늘어나기도 합니다. 이러한 리뷰가 늘어날 수록 리뷰이는 주어진 리뷰의 코드만 변경할 뿐 스스로 고민하는 시간은 줄어듭니다. 답을 알려주는 리뷰가 많아질수록 코드에 대한 애정도 사라지고 수동적인 개발자가 될 수 있으므로 스스로 고민하고 개선 방법을 찾는 것이 중요합니다.
const result = [];
arr.forEach(item => {
if(item % 2 === 0) {
result.push(item);
}
});위 코드는 배열을 순회하며 짝수인 값만 result 배열에 추가하는 코드입니다.
안 좋은 리뷰
“arr.filter(item => item % 2 === 0); 으로 사용하세요."
filter의 사용 코드를 알려주는 피드백입니다. 리뷰이 입장에서는 filter의 동작 방식을 제대로 이해하지 못한 채 수정하게 됩니다. 또한 비슷한 코드가 여러 군데 있음에도 불구하고 이곳만 수정할 수도 있습니다.
좋은 리뷰
“자바스크립트에는 배열에는 다양한 내장 메서드들이 존재합니다. 그중 filter 메서드를 활용해 보세요. 이 메서드를 활용하면 코드량을 줄일 수 있습니다.”
답을 알려주기보단 키워드(filter)를 알려줌으로써 어떤 식으로 검색해야 하는지 방법을 제시하고 있는 피드백입니다. 리뷰이 입장에서는 동작 방식을 찾아보고 스스로 학습할 기회가 생기고 비슷한 코드를 리팩토링할 수도 있습니다.
마치며
코드 리뷰는 커뮤니케이션 비용이 많이 드는 일입니다. 저 또한 코드 리뷰에 대해 잘 모르지만 무작정 스터디를 만들고 시작했을 때 여기 있는 사항들을 많이 지키지 못했습니다. 그래서 때로는 누군가에 상처를 준적도 받은 적도 있습니다. 그리고 영양가 없는 리뷰를 남긴적도 있었습니다. 그럴때마다 기업 테크 블로그, 유튜브, 다른 개발자 회고글에서 코드 리뷰 방법이나 실제로 어떻게 하고 있는지는 보면서 실제 스터디에도 조금씩 적용하면서 개선해나갔고 이를 토대로 코드 리뷰를 잘 활용하니 성장하는 데 굉장히 큰 도움이 되었습니다. 여러분들도 처음에는 어렵고 어색하겠지만 이 글과 아래 Reference에 있는 글과 영상들 참고해가면서 조금 더 효과적으로 코드 리뷰를 해보시길 바랍니다. 항상 응원합니다!
Reference
지속가능한 SW 개발을 위한 코드리뷰 :: 4월 우아한테크세미나
'정보' 카테고리의 다른 글
| 싱글톤 (0) | 2023.11.26 |
|---|---|
| [JEST] Mocking (0) | 2023.11.05 |
| 코딩테스트할 때 유용한 코드들 (1) | 2023.10.01 |
| Husky, lint-staged 설치 및 사용법 (0) | 2023.09.19 |
| ESLint란 무엇이고 어떻게 사용할까? (0) | 2023.07.30 |
