현직 개발자들의 코드 리뷰 방식을 알고싶어요
본 게시글은 커리어리의 질문과 답변을 정리한 글입니다.
익명님의 질문
사내 코드 리뷰를 어떻게 하는 것이 좋을까요?
고민 1. 코드 리뷰를 할 때 코드에 대한 사람마다의 기준이 있을 텐데 개인의 기준으로 평가해도 될까요?
고민 2. 연차가 많으신분의 코드 리뷰를 신입이 해도 될까요? 제 시야가 좁아서 오히려 잘못된 리뷰를 해주면 어떡하죠?
고민 3. 신입이 연차가 있으신분에게 리뷰를 달면 어떤 기분이신지도 궁금합니다.
커리어리의 현직자분들의 답변
퍼블리 소프트웨어 엔지니어이신 손정현님의 답변입니다.
🧑💻 사내 코드 컨벤션(가이드라인)을 기준으로 리뷰합니다.
사내에 대략적인 프로젝트의 구조를 통일시키기 위한 가이드라인이 존재해요. 이 가이드라인을 코드 컨벤션이라고 부릅니다.
주로 사내 코드 컨벤션을 기준으로 리뷰를 합니다.
코드 컨벤션의 내용: 컴포넌트 구조의 위치, 상태관리 방식, 유틸성 함수 관리 방식 등
리뷰 예시: "컨벤션에 맞지 않는 코드 같은데 이렇게 개선하면 어떨까요?" 제안
🧑💻 아직 컨벤션(가이드라인)이 정해진게 없다면 동료분들과 정해보는 것도 좋을 것 같아요!
🧑💻 시간이 된다면 직접 로컬에서 구동해보고 여러가지 케이스를 대입해 크리티컬한 이슈가 될 만한 버그가 없는지 확인합니다.
🧑💻 "이런식으로 코드를 짜면 좀더 가독성/효율이 좋아질 것 같은데, 어떻게 생각하시나요?" 류의 코멘트를 자주 합니다.
🧑💻 배포를 바로 해야하는 상황이라면 코드 퀄리티를 어느정도 포기하고 내보냅니다.
🧑💻 연차와 상관없이 작업자가 고려하지 못한 부분을 질문자님이 충분히 찾을 수 있다고 생각합니다. 의아한 부분의 코드가 있다면 '혹시 제가 고려하지못한 부분이 있을 까요?'하고 그대로 코멘트를 남기는 것도 좋은 방법인 것 같습니다.
🧑💻 코드 리뷰가 힘든만큼. 개인의 기준 보다는 팀적으로 합의된 컨벤션 기준일 때 좋을 것 같다는 의견입니다.
룩코 백엔드 개발자이신 코딩하는 기린님의 답변입니다.
🧑💻 코드 리뷰를 통해 컨벤션을 만들어가는 방식을 추천해요.
코드 리뷰는 단순 평가를 넘어 그 과정속에서 구성원들의 코드 스타일을 맞춰가는 것! 저희 회사도 코드리뷰에서 나왔던 많은 피드백으로 컨벤션이 자리잡아 갔습니다.
🧑💻 시니어 개발자들에게 코드 리뷰를 하는 것은 보통 질문성 코드 리뷰가 많습니다.
코드를 이런식으로 구성한 이유에 대한 질문, 함구 구성의 설명을 묻는 질문 등이 있습니다.
🧑💻 시니어 분들도 사람이시기에 실수가 있는 부분도 종종 있어서 잡아드리면 다들 좋아하십니다. ^^
당근페이 프론트엔드 엔지니어이신 이범희님의 답변입니다.
🧑💻 제가 중점적으로 보는 코드 리뷰 기준을 알려드릴게요.
1. 오류가 있는가?
→ 목적: 서비스가 사용자에게 문제 없이 제공될 수 있는가
2. 유지보수하기 좋은가?
→ 목적: 서비스에 새로운 기능을 추가하거나 개선하는데 좋은 구조 인가?
🧑💻 코드 리뷰를 할 때는 왜 코드리뷰를 하는가에대한 목적을 분명히 아는 것이 중요하다고 생각해요.
네이밍, 중복, 함수의 역할과 책임, 의존성, 가독성 등에 대한 리뷰는 중점적인 목적은 아니라고 생각해요. 코드 리뷰의 최우선적인 가치는 프로덕트와 팀의 생산성이라고 생각합니다. 개발 경력이 얼마이건 항상 이부분을 놓치지 않는 것이 중요하다고 생각해요.
🧑💻 리뷰할 때의 팁을 알려드릴게요.
✓ 어떤 목적을 위해서 수정하는 것이 좋은지(오류인지 구조인지) 알려주기.
✓ 수정한다면 어떤 방식으로 도입하는게 좋은지를 추천해주기.
🧑💻 신입이 리뷰를 해도되는 가? 가 아닌 해야된다. 고 생각해요.
연차의 적고 많음이 아닌 바라보는 시각에 따라 오류가 발생할 수 있는 지점을 찾아낼 수 있어요.
🧑💻 잘못된 리뷰를 작성해주는 것이아닐까? 라는 고민이 드는 코드는 성장할 수 있는 기회를 만난 것이에요.
누가봐도 이상한 코드라면 이런 고민은 하지 않을 거에요.
🧑💻 첫 리뷰에서 의미있는 리뷰를 달 수 없다면 질문을 던지며 토론을 해보세요. 더 나은 구조가 나올 것입니다.
🧑💻 리뷰 대상을 잘 고려해 리뷰의 말투를 사용해야해요.
감정적 말투가 아닌 코드 자체만을 가지고 같이 코드를 개선해보자! 라는 느낌으로 리뷰를 하시는게 중요해요.
커리어 AI봇인 GPT-4의 답변입니다.
🤖 리뷰를 작성할 때 겸손한 자세로 피드백을 하는 것이 좋습니다.
겸손한 자세의 리뷰 예시를 보여드릴게요.
✓ 이 부분을 이렇게 변경하면 어떨까요?
✓ 제가 이해한 것이 맞다면, 이부분을 개선할 수 있는 방법이 있을 것 같아요.
다음은 퍼블리 소프트웨어 엔지니어이신 손정현님이 코드리뷰에 관해 추천해주신 게시글의 내용입니다.
우아한형제들 웹프론트엔드 개발자이신 배민근 개발자님이 작성하신 글입니다.
🧑💻 카카오 테크에서 기고된 코드리뷰에 관한 글을 가져왔습니다. 기고된 글은 시니어가 교육생한테 어떻게 리뷰하면 좋은지에 대해 초점이 맞춰져 있어 저는 이글을 같이 일하는동료, 팀원분들과 하는 코드리뷰에 관한 관점에서 글을 다시 바라보려고 합니다. 기고된 글의 5가지 규칙에 대한 저의 해석을 담아 코드리뷰에 대해 알려드릴게요!
카카오 테크의 "효과적인 코드리뷰를 위한 리뷰어의 자세" 글 https://tech.kakao.com/2022/03/17/2022-newkrew-onboarding-codereview/
🧑💻 1. 코드리뷰를 할 때는 왜 개선이 필요한지 이유를 충분히 설명해 주세요.
본인이 코드리뷰를 달면서 어떤 생각으로 이런 리뷰를 달았는지 의도를 명확히 전달하는게 좋다고 생각합니다.
🧑💻 2. 코드에 정답은 없으므로 다양한 관점을 가지고 본인의 생각에 대해 이야기하고 제안하자!
코드에 정답은 없지만 여러 모범 답안이 있을 수 있습니다. 해당 의견을 채택할지 말지는 작업자의 몫이고 채택되지 않더라도 좋은 온의가 있었다면 그 자체로도 만족스럽습니다.
🧑💻 3. 코드를 클린하게 유지하고, 코드의 일관성이 유지될 수 있도록 리뷰해주세요.
혹시나 클린하게 유지라는 말이 무슨 말일까 고민된다면 클린 코드라는 책을 읽어보신다면 클린하게 라는 의미에 대해 조금 더 이해하실 수 있지 않을까 싶네요.
🧑💻 4. 코드 리뷰를 하는 목적은 서로 생각을 공유하고 좀 더 깔끔한 코드를 작성하기 위함이다.
리뷰어이든 리뷰이든 더 나은 프로덕트를 위해 코드리뷰는 반드시 필요합니다. 출근하면 앞에 30분은 코드리뷰 같은 룰이라던지 데브옵스의 도움을 받는다던지 등 그라운드 룰이 있어도 좋을거 같다는 생각이 드네요!
🧑💻 5. 리뷰를 위한 리뷰를 하지 마세요. 피드백 할게 없으면 칭찬해 주세요.
코드에 고칠 부분이나 제안할 내용이 없더라도 고생한 동료분들을 위해 수고하셨다는 내용이나 최소한 LGTM이라도 남겨주시면 어떨까요?
LGTM이란?
코드 리뷰의 최종 목표는 다른 엔지니어로부터 해당 변경을 적용해도 된다는 합의를 이끌어내는 것입니다. 합의한 엔지니어는 ‘좋아 보임(looks good to me)’이라는 뜻의 LGTM이라는 태그를 달아 의사를 표현합니다. 구글에서는 이 LGTM이 변경을 커밋하는 데 요구되는 필수 항목입니다.
우아한형제들 프론트엔드 개발자이신 김하림 개발자님이 작성하신 글입니다.
🧑💻 글로벌 기업들은 코드리뷰를 어떻게 할지에 대해 정리를 해보려고 합니다.
🧑💻 구글과 마이크로소프트에서는 코드 리뷰를 매우 중요하게 여기며, 이를 위해 다양한 방법을 사용하고 있습니다.
구글
- 코드 리뷰 개발자 가이드를 통해 코딩 스타일을 비롯한 주요 원칙을 공개하고 있습니다.
- Tricorder라는 정적 분석 도구와 Rosie라는 코드 정리 시스템을 활용해 사용하지 않는 코드는 없애고, 리팩토링이 필요한 경우에는 수정된 코드를 개발자들에게 리뷰 요청하는 것으로 알려져있습니다.
Microsoft
- Codeflow를 통해 코드 리뷰를 진행하고 있습니다.
- 개발자들간에 코드 리뷰의 코멘트를 명확히 이해하고 전달할 수 있도록 이모티콘을 활용하기도 합니다. 이모티콘을 통해서 텍스트만으로 전달하면서 발생할 수 있는 감정적인 싸움이 예방될 수 있다는 것입니다.
글로벌 기업들의 코드리뷰를 참고한 사이트는 다음과 같습니다. https://www.samsungsds.com/kr/insights/global_code_review.html
본 게시글이 문제가 될 경우 댓글을 남겨주시면 감사하겠습니다.