코드리뷰 실전가이드: 자주 묻는 질문과 해답 모음

1. 코드 리뷰를 받는 입장에서 해야 하는 입장이 되었는데 다른 분들은 리뷰를 어떤 식으로 하는지 궁금합니다.

안녕하세요. 이번에 테크리드로 승진(?)하게 된 5년차 개발자입니다. 작은 스타트업에 있다보니 생각보다 빠르게 테크리드 역할을 맡게 되었습니다. 이제 제가 코드리뷰를 맡아서 해야 하는 상황이 되었습니다. 매번 코드리뷰를 받다가 하게 되는 입장이 되어서 다른 분들 의견을 들어보고 싶습니다. 다들 기대하는 혹은 상상하는 코드리뷰 문화는 어떤건가요? 혹은 좋은 코드 리뷰를 경험한 분이 있다면 어떤 방식이었는지 궁금합니다!

답변

요약 1. 저는 로직을 이해하기 쉽도록 구현했는지를 위주로 코드리뷰하고, 코드 스타일은 린터/포매터를 십분 활용합니다. 2. 코드 작성자는 확신이 없는 부분에 대해서 사전에 설명하는 코멘트를 남겨두면 좋습니다. 3. 코드 리뷰어는 자신의 코멘트가 필수적으로 반영되어야 하는지, 선택적으로 반영하면 좋은 것인지 명시하면 좋습니다. 4. 구글 등 다른 코드리뷰 문화도 참고하시면 좋습니다. 경험상 사람마다 코드리뷰에서 주로 보는 부분이 다르겠지만, 저는 로직을 주로 봅니다. 구현하고자 하는 것에 비해서 복잡하게 되어있지는 않은지, 맥락을 알아야지만 이해할 수 있도록 구현되어 있지는 않은지 점검하는 편이에요. 그래서 사실 코드를 읽다가 이해하기 어렵다 싶으면 그때부터 로직에 개선점이 있는지 주의 깊게 봅니다. 코드 스타일 등 린터나 포매터로 자동화할 수 있는 부분은 크게 신경 쓰지 않는 편이에요(대부분 CI에서 잡히고, 새로운 린터 규칙이 필요하면 추가하면 됩니다). 한편, 코드리뷰를 하다 보면, 리뷰가 올라오기까지의 시간과, 리뷰를 반영했을 때 그걸 확인하고 승인하는데 까지 걸리는 시간이 오래 걸리기 마련입니다. 일종의 핑퐁이지요. 이 핑퐁을 줄이기 위한 방법으로 저는 선제적 코멘트를 사용했습니다. 로직을 최대한 이해하기 쉽게 짜려고 노력했지만, 더 이상 개선할 수 없었을 때, 그렇다고 주석을 남기기도 애매할 때는 github, bitbucket의 코드 인라인 코멘트로 왜 이렇게 짰는지, 무엇을 고민하고 있는지에 대해 적어둡니다. 그러면 리뷰어가 왜 이렇게 짜셨나요? 라고 묻고, 그에 대해 답하면서 생기는 핑퐁이 줄어듭니다. 마지막으로, 코드 작성자의 입장에서는 리뷰어의 코멘트가 필수적으로 반영되어야 하는지, 아니면 반영되면 좋은 것인지 구분이 애매할 수 있습니다. 그래서 리뷰어가 필수/선택 여부를 명확하게 표시해주는 게 좋다고 생각합니다. https://google.github.io/eng-practices/review/ 구글의 코드리뷰 가이드 문서와 거 문서에 링크된 다른 글을 읽어보셔도 도움이 될 거 같습니다.

2. 사내 코드리뷰... 어떻게 하는게 맞는걸까요?

안녕하세요 요즘 정말 고민인 부분이 있는데 따로 조언을 구할 곳이 없어서 질문 올려봅니다. 맥락을 좀 설명하자면, 사내에서 개발자들끼리 연차 상관없이 서로 코드 리뷰를 하는 시스템이 잡혀있습니다. 전 입사한 지 1년 정도 되었고, 같이 일하시는 분들은 0~10년차 이상 다양해요. 문제는 크게 2가지 입니다. 첫 번째는, 코드 리뷰를 할 때 제 개인의 기준을 잣대로 활용해도 되는가? 입니다 저는 코드를 짤 때 저만의 기준이 존재합니다. 예를 들면, 코드를 읽다가 “이런 변수명은 지양해야지, 이렇게 함수 중첩이 되면 가독성이 떨어져, 이 함수는 하는 일이 너무 많은 것 같은데?” 라는 생각이 들면 코멘트를 작성하는 편입니다. 근데 문득 저만의 기준을 상대방에게 강요하고 있는 건가..? 하는 생각이 들었어요. 혹시 여러분들은 코드 리뷰를 할 때 기준이 있나요? 있다면 무엇을 기준으로 하시나요? 개인의 경험인가요? 두 번째는, 연차가 많으신 분의 코드를 리뷰 할 때 “내가? 해도 되는 건가?” 라는 생각이 들어요. 물론, 개발자라면 연차 상관없이 코드 그대로만 리뷰하는 게 맞지만, 리뷰를 하다 보면 “이게 맞는 건가? 내가 너무 시야가 좁은 것은 아닌가? 내가 고려하지 못한 다른 부분 때문에 코드를 이렇게 작성하신 게 아닐까?” 라는 생각이 자주 들어서 썼던 코멘트도 지우는 경우도 많거든요 ㅎㅎ 연차가 있으신 개발자 분들이 느끼기에 저연차 또는 갓 들어온 신입이 본인 코드에 리뷰를 달면 어떤 기분이신지도 궁금합니다. 두서없이 쓰다보니 길어졌는데요. 결론은 사내 코드리뷰를 어떻게 하시는지, 기준이 무엇인지 궁금합니다! 감사합니다!!

답변

안녕하세요! 좋은 고민이네요 ㅎㅎ 저도 코드 리뷰를 자주하지만 상당히 어려운 것 같아요. 그래도 제가 하는 방식과 최근에 동료의 코드 리뷰 방식을 공유받은 내용을 알려드리면 도움이 될까 싶어 답변 남깁니다. 우선 저는 사내에 코드 컨벤션이 정리된 문서가 있습니다. 가령, 컴포넌트 구조는 어디에 어떻게 위치하며, 상태 관리는 어떤 식으로 하는지, 유틸성 함수들은 어떻게 관리하는지 등 대략적인 프로젝트 구조를 통일 시키기 위한 가이드라인이 존재해요. 그래서 이 컨벤션을 기준으로 리뷰를 많이 합니다. “컨벤션에 맞지 않는 코드 같은데 이렇게 개선하면 어떨까요?” 등의 코멘트를 주로 남겨요. 또 다른 기준은 리뷰하고 있는 코드에 크리티컬한 이슈가 될 만한 버그가 없는지 확인하는 것 같아요. 시간이 된다면 직접 코드 수정된 프로젝트를 로컬에서 구동해보고 로직을 따라가면서 제가 생각한 엣지 케이스 몇개를 대입해봅니다. 테스트 코드가 있다면 좋지만, 없는 경우도 많아서 이렇게 직접 테스트를 자주 하는 것 같아요. 그리고 크리티컬한 이슈가 발견되면 코멘트를 남겨요. 개인적인 기준도 분명 존재하지만 이건 권장사항 느낌인 것 같아요. 코드의 퀄리티를 높일 수 있는 방향이 있고 시간적 여유가 있다면, “이런 식으로 코드를 짜면 좀더 가독성/효율이 좋아질 것 같은데, 어떻게 생각하시나요?” 류의 코멘트를 자주 답니다. 물론, 배포를 바로 나가야되는 상황이라면 코드 퀄리티를 어느정도 포기하고 내보내기도 합니다. 저는 기준이라는게 각자 다르고, 개발자들도 사람이기에 코드도 다 다르다고 생각하는 입장을 가지고 있어요. 그래도 팀 차원에서 리소스를 아끼려면 코드가 어느정도 일관성이 있어야 하는데 이걸 정하기 위해 컨벤션 문서가 있다고 생각해요. 아직 사내에 컨벤션이 정해진게 없다면 동료분들과 정해보는 것도 좋을 것 같아요! 두번째 질문은 … 음 저도 아직 경험이 많지 않아서 잘 모르겠네요. 하지만, 연차와 상관없이 작업자가 고려하지 못한 부분을 코드 리뷰어가 (질문자님이) 충분히 찾을 수 있다고 생각해요. 그래서 그렇게 크게 주눅 들 필요가 없다고 생각합니다. 오히려 “내가 고려하지 못한 부분이 있는건가?” 싶으시면 그걸 그대로 코멘트 남겨주는것도 좋은 방법이라고 생각해요. 결론은 코드리뷰 힘든거 동의하구요. 그래서 기준이 있으면 좋긴합니다만, 그게 개인의 기준보다는 팀적으로 합의된 컨벤션 기준일 때 더 좋을 것 같다는 의견입니다. 추가적으로 리뷰를 남길때는 일관성있게 남기는 것도 중요한것 같습니다. 커리어리에도 코드리뷰 관련 좋은 글들이 있어서 몇개 첨부합니다. - https://careerly.co.kr/comments/79230 - https://careerly.co.kr/comments/79688 - https://careerly.co.kr/comments/81256 - https://careerly.co.kr/comments/80998 - https://careerly.co.kr/comments/78321 - https://careerly.co.kr/comments/73408 다른 분들은 어떻게 생각하시는지 저도 궁금하긴하네요 :)

3. 팀 규모가 커져서 코드 스타일 규칙을 정하려고 합니다.

회사에서 프로젝트를 3개 진행중이고 프론트엔드 개발자가 6명이 되어서 이제는 좀 코드 스타일에 대한 규칙 같은걸 정해보려고 합니다. 어떤 부분을 참고해야 할까요? 지금 정해보고 싶은 것들이 eslint prettier 변수나 함수 네이밍 룰 정도기는 한데 참고하시는 책이나 블로그 글이나 사이트가 있을까요?

답변

모든 것을 한번에 정하기는 어려울텐데요. 혼자가 아닌 협업하면서 같이 개발을 하게 되면 우선적으로 정해야하는 것들을 먼저 논의/협의 하고 나머지는 진행하면서 조금씩 보강해 나가면 될 거 같아요. 1. eslint, prettier : recommended를 찾아서 적용하는걸 추천해요 2. 네이밍룰 : 변수, 함수, 파일명, 디렉토리명등 대표적인 것들에 대해서만 정하고 시작해도 좋아요 3. 디렉토리 구조 : 기능 집약적으로 vs 역할 집약적으로? 둘 중 큰 틀에서는 정하고 시작하는게 좋아요. 4. Git 브랜치 전략 : 일반적인 pr merge할때, 큰 기능 develop으로 merge할 때, develop을 main으로 merge할 때, 릴리즈 할때, 핫픽스 할 때 등에 대한 전략 등 5. 코드 리뷰 : Pn Rule 추천해요. (https://blog.banksalad.com/tech/banksalad-code-review-culture/) 그 외에는 진행하면서 지속적으로 논의하면서 Ground Rule을 만들어 나가면 좋을 거에요.

4. 코드리뷰/ git flow 어떻게 하나요

부트캠프 수업을 듣으면 …정기팀회의 설명하는 …것 어려워서…링크이나 답변 부탁 드리겠습니다

답변

안녕하세요 :) 처음엔다 어려운듯합니다 좀 하시다 보면 적응 되실것 같아여 제가 봤던 것 중에 괜찮을 자료 공유드립니다 코드리뷰 관련 https://tech.kakao.com/2022/03/17/2022-newkrew-onboarding-codereview/ git flow 관련 https://techblog.woowahan.com/2553/

5. 코드리뷰는 어떻게 진행되나요?

안녕하세요~! 1년차 인공지능 엔지니어입니다. 저희 회사가 인원수가 매우 적다가 이제 회사가 커지면서 코드 리뷰 진행에 대해서 고려하고 있습니다. 그런데 어떻게 진행되는 것이 좋은지 감이 잘 오지가 않아서 질문드립니다. 각 회사에서는 어떻게 코드리뷰가 진행되는지 또는 어떻게 진행되는게 효율적인지 알려주실 수 있으실까요?

답변

안녕하세요! 회사마다 다르겠지만 저희는 사내 코딩 컨벤션을 정리한 문서가 있고 일반적인 코드 리뷰 프로세스는 이렇게 진행하고 있어요. 1. 각 팀 (도메인) 별로 브랜치가 존재함 2. 팀의 작업자가 브랜치를 새로 생성해서 작업을 함 3. 작업이 완료되면 팀의 메인 브랜치에 Pull Request를 올리면서 Reviewer를 등록함 4. 모든 Reviewer의 리뷰가 끝나야 팀 메인 브랜치에 해당 작업 브랜치를 머지 코드 리뷰는 회사나 팀마다 스타일이 다 다르고 현재 개발 문화와 인원에 맞게 프로세스를 잡아가는게 중요한 것 같습니다. 물론, 기존 업무 흐름과 생산성에 크게 영향을 주지 않는선에서 프로세스를 잡는건 어려운 것 같습니다 :) 참고해보시면 좋은 글들 첨부합니다! - https://careerly.co.kr/comments/79688 - https://techblog.woowahan.com/7152/