코드리뷰(Code Review)

8 min readDec 9, 2020

코드 리뷰 도입전 간단하게 알아보고 왜 하는지, 어떻게 할건지에 대해 간단히 정리해보았습니다.

What is Code Review?

한 명 또는 여러 명의 개발자가 본인이 만들지 않은 코드의 내용을 점검하고 , 피드백을 주는 과정을 말한다. 여기에서 피드백이란, 오타, 버그 가능성, 개발 표준 등에 대한 의견이 될 수 있고, 좋은 코드에 대한 긍정적인 피드백이 될 수도 있다. 코드리뷰의 핵심은 단순히 코딩스타일을 일관되게 유지하거나, 예상되는 문제를 일찍 파악하는 데에 그치지 않고 코드에 대한 책임이 그 코드를 만든 사람 혼자에게 있지 않고 우리 모두에게 있다는 문화를 만드는 데에 있다.

Why is important Code Review?

버그의 조기 발견
개발 표준 준수
중복 코드를 방지하고 모듈의 재 사용성 증대
다른 사람의 잘 만들어진 코드를 보면서 배울 기회를 얻는 것. 개인 간의 격차를 줄이는 가장 좋은 방법.
좀 더 좋은 방법을 제시
이해 수준을 상향 평준화하는 것.
문제점을 찾는 목적을 넘어 전체적인 조직의 역량을 강화하는 중요한 역할을 한다.
책임자를 추궁하지 않는 문화의 정착
특정한 문제가 발생했을 때 그 원인이 누구의 코드에 있는 지를 찾으려는 모습을 자주 확인할 수 있다. 코드 리뷰 문화가 정착되면 특정 코드에 문제가 발생했을 때 누군가에게 책임을 묻거나 비난하는 문화를 없앨 수 있다. 이 문화가 정착이 되면 그 코드를 개발한 사람 뿐 아니라, 해당 변경사항을 확인한 모든 사람이 연관되어 있기 때문에 책임자를 찾기 보단 책임이 우리 모두에게 있다 라는 문화를 정착하는 것에 있다.

소프트웨어 유지보수하는 조직에서 코드 한 줄을 변경한다고 했을 때, 코드리뷰 도입 전에는 그러한 변경의 55% 정도가 문제를 일으켰다. 그러나 리뷰 도입 이후 변경의 2% 정도에서만 문제가 발생함. by Steve McConnell(Code Complete)

How do Code Review?

공식 코드 리뷰(formal code review)
여러 명의 참석자가 정해진 절차에 의해서 코드의 상세한 부분을 하나하나 검토하는 방식.
이 방식은 문제를 조기에 발견할 순 있지만(다 같이 한 코드를 보기에) 비용이 비싸고 빈번히 수행하기 어렵다.
가벼운 코드 리뷰(lightweight code review)
복잡한 절차나 부담없이 코드리뷰를 수행한다. 여기서는 이 방식에 대해 더 알아보자.

온라인 코드리뷰

온라인 코드 리뷰는 온라인 상에서 진행하는 방식으로 한명의 코드를 리뷰하는 사람이 1명에서 많게는 5명 이상까지 다양하게 진행할 수 있다. 일반적으로 버젼 관리 시스템, 이슈 트랙킹 시스템과 연동해서 해당 코드가 어떤 부분을 수정했는지, 어떤 이슈와 관련되어 있는지 쉽게 파악할 수 있어야 한다. github의 기본적인 pull request를 활용하는 방식을 많이 사용한다.

일반적으로 온라인 코드 리뷰는 코드의 작성자가 변경 사항에 대한 코드 리뷰를 요청하고 리뷰어들은 해당 코드의 피드백을 작성하는 방식으로 진행한다. 아래의 방식을 살펴보면

위 그림은 github을 이용하여 온라인 코드 리뷰 예시이다.

코드리뷰를 진행할 때 한가지 팁은 기준에 대한 체크리스트를 만들어서 체크하는 방식이다. 이를 통해 가이드를 작성할 수 있고 놓친 부분을 점검할 수 있다.

팀 리뷰

팀 리뷰는 온라인 리뷰와는 반대로 팀 구성원들이 주기적으로 오프라인에서 하는 리뷰이다. 팀 리뷰에는 반드시 특정 코드에 대한 검토 형식으로 진행할 필요는 없다. 팀 리뷰 자체도 자유롭고 가벼운 방식의 코드 리뷰 이기 때문에 다양한 주제를 가지고 진행할 수 있다. 온라인 리뷰 과정에서 나왔던 내용을 기반으로 자유로운 토론을 진행할 수도 있고 좋은 사례를 전체적으로 공유하는 시간으로 진행할 수도 있다. 또 자신이 궁금했던 점을 질문하거나 온라인 리뷰 과정에서 개선되었으면 하는 점을 제안할 수도 있다.

Code Review CheckList

기능의 정상 동작 여부
버그의 조기 발견
가독성과 유지보수 편의성
개발 표준의 준수 여부
테스트 코드의 작성 여부
재사용 가능한 모듈의 중복 개발
배울만한 점이 없는지.
코드 리뷰에는 실력이 뛰어난 개발자가 후배 개발자의 코드를 검사하는 것이 아니다. 리뷰의 목적 중 작성자에게 피드백을 주는 경우가 잦긴 하지만 이런 식으로 코드를 작성할 수 있구나, 더 쉬운 방법이 있구나 등 학습효과도 가지고 있다. 그렇기에 리뷰할 때는 피드백을 주기 위한 시각과 좋은 점을 배우려는 시각, 이 두 가지 시각의 균형을 맞추며 진행해야한다.

Code Review Precautions

처음 리뷰를 하다보면 논쟁이나 다툼이 발생할 수 있다. 그렇기에 주의 사항을 예시로 적어보면

코드의 맥락을 이해할 수 있는 설명을 미리 적어두기.
주석도 좋지만 커밋 메시지나 코멘트 이용하는 게 추적에 좋다.
하나의 이슈 당 하나의 코드 리뷰
수정사항이 적다는 이유로 여러 개의 이슈를 동시에 처리하는데 리뷰의 집중을 위해 하나의 이슈에는 하나의 리뷰만 수행할 수 있도록 정하자.
리뷰 받는 코드는 한번에 500줄 이하 유지
한번에 수 천줄 이상을 리뷰하다보면 너무 많은 시간을 투자해야한다. 그렇기에 리뷰어는 코드의 양에 따라 리뷰의 깊이를 조절해야 한다.
주관적인 의견
누구나 각자의 개발 스타일을 가지고 있다. 개발 표준을 준수하지만 각자의 스타일을 완전히 배제할 수 없기에 견해 차이가 발생한다. 이때 표현의 방식에 주의를 기울이자. 기존의 자신의 방식이 정답이라는 생각을 버리고 “나의 의견은 이러한데 당신은 어떻게 생각하나요?” 등의 의견을 물어 견해의 간극을 좁히자.
리뷰를 미루지 않기
리뷰가 길어지면 이어지는 작업이 미뤄질 수 있고 또 다른 코드와 충돌하며 처리하는 경우가 생긴다. 그렇기에 부수적인 작업이라고 생각하지 말고, 코드 리뷰에 집중할 수 있는 시간을 확보하는 것이 좋다.

디테일한 방식

notification 이 가는 구조 구축
의견이 좁혀지지 않을 땐 직접 만나서 해결. 결론에 도달한 이유는 간단히 적기.
리뷰어는 가급적 리뷰를 먼저 해주기. ⇒ 업무 효율이 좌우됨.
일반적인 규칙은 24시간 내에 리뷰를 보내주는 방식(그날 리뷰는 그날)
코드가 향후 오래 사용될 경우 깐깐한 리뷰, 실험적인 코드면 느슨한 리뷰로 적절한 안배로 리뷰어의 리소스의 강약을 조절
코드리뷰에서 가장 많이 배워 나를 더 나은 엔지니어가 될 수 있다.
리뷰시 나만의 스타일을 고집하면 안됨.
리뷰 요청자가 고집이 쎄서 한두번 애기해서 안 듣는 다면 포기하여 팀웍을 깨지 않는 것도 중요함.
리뷰할 땐 예의를 갖추기
리뷰할 때 구체적이고 명시적으로 부족한 점을 적어주기.
첫 리뷰는 특히 신경써서 작성

노하우

나보다 뛰어난 엔지니어에게 리뷰를 많이 받아 실력 성장.
나보다 못하는 엔지니어라도 보는 관점이 다르기 때문에 항상 배우는 점이 존재함.

Code Review중인 현업에서의 방식과 피드백

1. H사

나태해지기 쉬운 구조
서로 비판을 받아들일 준비가 되어 있어야 함.
서로 적극적으로 피드백을 주려는 노력이 많이 필요
⇒ 그렇지 않으면 코드리뷰라는 프로세스 하나만 더 생겨 관례적으로 넘어가는 경우가 다반사이기에 서로 노력을 해야함.
검수자가 특히 열심히 리뷰를 해주어야 함.
예를 들어 칭찬이든, 오류든, 버그든, 컨벤션 이슈 무엇이든 1개 이상의 코멘트를 작성해야 한다.
오프라인 리뷰는 보통 다른 회사에서는 주니어 교육용으로 사용
할 거면 다 같이 모이는 자리에서 진행해야 의미가 있음.
꼰대가 나타나서 분위기를 망치면 안됨. (누구나 다 적극적으로 참여하는 분위기 유지)
일정이 지연되는 스트레스가 발생하는데 PR 브랜치에 푸시가 이루어졌을 때 바로 빌드가 되고 접속해서 확인할 수 있게 CI세팅을 잘 해 놓으면 리뷰가 병목되는 현상을 방지할 수 있음.

2. N사

작성한 코드 pr 날리고 선임이 리뷰해주는 방식.

⇒ 현재는 서비스가 바뀌면서 회의잡고 설명으로 바뀜.

⇒ 사수마다 다름 ⇒ 회의 때 서로 바주고 사수, 부사수 끼리도 디스함.

3. B사

PR하면 리더가 Merge하기 전까지는 PR List에 존재. PR한 사람 제외하고 모든 사람이 코멘트 달기.
정기적인 리뷰시간에는 PR을 날린 작업자가 어떤 목적을 가지고 어떻게 접근해서 어떻게 작업했는지(포인트는 코드의 당위성, 구조화를 지키고자 어떤 노력을 했는지, 접근방법) 이야기하고 코멘트에 대한 느낀점을 솔직하게 이야기(좋다, 다른 접근방법은?, 구리다(솔직함이 포인트))
그렇게 싸이클을 돈 후 리더가 리뷰를 해주고 일정에 잘 따라오고 있는지 저번주에 비해 나아진 점, 안좋아 진 점등 피드백을 줌.
그리고 각자 자리에 가서 2시간 이내로 피드백이 어땟고, 어떤 대처를 할지 적어서 리더한테 보내고 리더는 관리함.

C사

페어프로그래밍이라는 문화가 있다. 언제든지 요청해서 시간을 잡을 수 있고

구함: @사람

무엇을 :

얼마나 :

형식으로 씀

보통 페어프로그래밍 요청하는 대상은 작업할 영역을 잘 안다고 느껴지는 사람을 택하고 누군가는 나무를 보고 누군가는 숲을 보게 하는 시스템.

페어 워크 상대간에 너무 실력차가 나면 일단 실력자가 몹 프로그래밍하듯 진행. 초보자가 패턴을 읽히고 학습하는데 굉장히 유용함.

참고 문헌

https://blog.logi-spot.com/코드리뷰의-진짜-목적은-따로있다/