keepmhwn

1년 동안 코드 리뷰를 하면서 느낀점-thumbnail

1년 동안 코드 리뷰를 하면서 느낀점

2023년 05월 12일

시작하며

2022년 1월부터 현재 회사의 프론트엔드 팀에 합류하여 1년이 조금 넘는 기간 동안 코드 리뷰를 하면서 느낀 점을 공유하려고 합니다. 이 글은 개인적으로 코드 리뷰를 하면서 느낀 장점과 장점을 얻기위한 올바른 코드 리뷰 방법을 정리한 것입니다.

1. 왜 코드 리뷰를 해야할까?

코드 리뷰를 하면서 느낀 장점은 크게 4가지이며, 이는 코드 리뷰를 해야하는 이유와도 같습니다.


첫 번째는 팀원의 부재에 대비할 수 있습니다. 일반적으로 프로젝트에 여러 명의 개발자가 투입되어 업무를 나누고 각자 맡은 부분을 개발합니다. 이로 인해 본인이 개발하는 것 외에는 관심을 갖지 않아 전체적인 코드를 파악하지 못할 수 있습니다. 이는 프로젝트의 책임감을 떨어뜨리기도 하고 팀원이 부재 중일 때 팀원이 개발한 부분에 오류가 발생하여 남은 팀원들이 해결해야 되는 상황이 왔을 때 빠르게 대응하지 못할 수 있습니다.


하지만 코드 리뷰를 통해 팀원들이 작성한 코드를 파악하고 있다면 코드를 파악하는 시간이 줄어 오류에 빠르게 대응할 수 있습니다. 그리고 오류에 빠르게 대응한다면 기존에 개발해야하는 작업들에 큰 영향을 끼치지 않아 기한 내에 마칠 수 있습니다.


두 번째는 유대감 형성입니다. 위에서 말했듯이 일반적으로 하나의 프로젝트에 여러 명의 개발자가 투입됩니다. 만약 코드 리뷰를 진행하지 않는다면 업무를 나눈 뒤에 각자 개발하고, 각자 개발한 것을 Merge하여 팀원들의 진행 상태 정도만 공유할 확률이 높습니다.


하지만 코드 리뷰를 한다면 팀원이 어떤 어려움을 겪고 있는지 알 수 있어 함께 문제를 해결하는 과정에서 신뢰감이 형성되고 팀원의 코드를 토론을 통해 함께 발전시킨다면 서로에게 배울 수 있는 시간이 될 것입니다. 그리고 이러한 시간은 팀원들의 유대감을 형성하는데 많은 도움이 됩니다.


세 번째는 프로젝트의 코드를 최대한 깨끗하게 유지할 수 있습니다. 깨끗하게 유지한다는 것은 컨벤션을 지킨 코드, 중복된 로직을 수행하는 여러 개의 코드가 존재하지 않는 것, 사용하지 않는 코드가 없는 것, 가독성이 높은 코드가 되도록 노력하는 것입니다. 그리고 코드를 깨끗하게 유지하기 위한 노력은 코드 리뷰가 많은 도움이 됩니다.


실제로 코드 리뷰를 하면서 기존에 존재했던 함수를 확인하지 못하고 새롭게 함수를 작성한 것을 발견할 수 있었고, 혼자만의 기준이 아닌 팀원들과 토론을 통해 한층 더 가독성 높은 코드를 작성할 수 있었습니다. 이 과정을 통해 모두가 코드를 깨끗하게 유지하고싶은 욕심과 책임감을 갖게되었습니다.


네 번째는 개인의 성장입니다. 개발자로서 성장할 수 있는 방법은 다양합니다. 그중에서도 가장 많은 시간을 투자하는 회사의 프로젝트 코드로 코드 리뷰를 진행하는 것은 효과적으로 성장할 수 있는 방법 중의 한 가지입니다. 팀원들로부터 새로운 기술을 알게 될 수도 있으며 특정 코드에 대해 토론을 하면서 발전시킬 수 있습니다.


그리고 개발을 하다 보면 한 명이 비슷한 요구사항을 맡아서 계속 진행할 수 있어 다양한 경험을 하지 못하는 상황이 있을 수 있습니다. 하지만 코드 리뷰를 하면서 팀원들이 구현한 요구사항을 본인이라면 어떻게 구현할지 생각하고 직접 코드를 작성하면서 간접적으로 경험할 수도 있습니다.

2. 어떻게 코드 리뷰를 해야할까?

위와 같은 장점을 얻기 위해서는 올바른 코드 리뷰 방법을 적용하는 것이 중요합니다. 그리고 올바른 코드 리뷰 방법은 리뷰를 요청할 때와 리뷰를 할 때의 방법이 다릅니다.


리뷰를 요청할 때

리뷰를 요청할 때 갖춰야 할 마인드는 본인의 시간만큼 리뷰어의 시간도 소중하다는 것을 아는 것입니다. 리뷰어들도 바쁜 와중에 시간을 쪼개서 리뷰를 하는 것이고, 코드 리뷰 시간이 길어지면 리뷰어들도 집중이 안 되어 꼼꼼히 리뷰하지 못할 가능성이 커집니다. 그래서 저는 리뷰를 요청할 때 리뷰어들의 시간을 아끼고, 꼼꼼히 리뷰 받을 수 있도록 다음 3가지 방법을 적용했습니다.


첫 번째는 적당한 크기로 작업물을 나누어서 리뷰를 요청하는 것입니다. 본인이 다른 사람의 코드를 리뷰할 때 500줄, 1,000줄이 넘는 코드를 리뷰해야 한다면 어떨까요? 시간도 오래 걸리지만 꼼꼼하게 리뷰하지 못할 수 있습니다. 그래서 저는 어떤 요구사항을 개발할 때 여러 개의 작업으로 나눠서 개발을 하고 코드 리뷰를 요청합니다. 이렇게 한 번에 모든 것을 개발하는 것이 아닌 여러 개로 나누어 개발한다면 리뷰를 받을 때 버그도 쉽게 발견될 수 있었습니다.


두 번째는 정확하게 commit을 나누는 것입니다. 완료된 작업물을 하나의 commit에 포함시키거나 작업의 내용과 상관없는 commit 메시지를 사용한다면 리뷰하는 것이 힘들 수 있습니다. 작업들을 주제에 맞게 나누고 알맞은 commit 메시지를 사용하여 올린다면 commit만으로도 어떤 것을 작업한 것인지 쉽게 파악할 수 있습니다. 실제로 한 팀원으로부터 commit이 잘 나누어져 있어서 보기 편하다는 피드백을 받았습니다. 부가적으로 commit을 잘 나누면 히스토리를 파악하는 것도 수월해집니다.


세 번째는 리뷰를 요청한 작업물에 대한 설명을 적는 것입니다. 본인은 기획된 것을 살펴보고 많은 시간을 투자하였기 때문에 작업물에 대해 이해도가 높습니다. 하지만 리뷰어는 배경지식이 없기 때문에 리뷰를 하기 전에 어떤 작업을 한 것인지 파악해야 되는 과정이 추가됩니다. 만약 리뷰를 요청할 때 본인의 작업에 대해 상세히 설명한다면 리뷰어는 시간을 아낄 수 있습니다. 이를 위해 Github의 Pull Request할 때 작업의 내용, 작업의 히스토리, 문제 또는 고민이 되는 부분 등을 적을 수 있는 Template을 만들어서 활용한다면 리뷰를 요청할 때마다 자연스럽게 이를 작성할 수 있습니다.

리뷰를 할 때

팀원들의 코드를 리뷰할 때도 본인의 시간을 아끼고 팀원들이 빠르게 작업할 수 있도록 최대한 빠르고 꼼꼼하게 리뷰해야 합니다. 그리고 리뷰를 할 때는 본인이 맡은 것 외의 코드도 파악할 수 있도록 더욱더 꼼꼼하게 할 필요가 있습니다. 저는 이를 위해서 다음 2가지 방법을 적용하고 있습니다.


첫 번째는 본인만의 루틴을 만드는 것입니다. 저는 리뷰를 할 때 브라우저 콘솔에 warning 또는 error가 발생하는 것을 놓친 적이 있었습니다. 그 이후로 warning 또는 error가 발생하는지 확인한 적도 있지만 주요 로직을 확인하면서 잊어버린 경우가 종종 있습니다. 그래서 저는 꼼꼼히 리뷰를 하기 위해 저만의 루틴을 만들었습니다. 예를 들면 아래의 순서대로 리뷰를 하는 것입니다.


  1. 코드에 오탈자가 없는지 확인합니다.
  2. 코드를 실행시켜 에러가 발생하는지 확인합니다.
  3. 코딩 컨벤션을 지키지 않은 것이 있는지 확인합니다.
  4. 주요 기능에 대한 로직을 파악합니다.
  5. 다른 방법이 있는지 생각합니다.

위의 순서는 대략적으로 작성한 것이고 위와 같이 루틴을 만든다면 비교적 빠른 시간 안에 꼼꼼히 리뷰를 하는데 많은 도움이 되었습니다.


두 번째는 본인이라면 어떻게 했을지 생각해 보는 것입니다. 리뷰할 때 팀원이 작성한 로직을 보고 더 나은 방법이 있는지, 다른 방법은 없는지 생각해서 코드를 작성해 보는 것은 다음과 같은 장점이 있습니다.


마치며

코드 리뷰를 하지 않았던 팀에서 코드 리뷰가 하나의 문화로 정착하기까지 많은 시행착오를 겪었습니다. 언제 코드 리뷰를 할 것인지, 코드 리뷰를 통해 무엇을 확인할 것인지, 궁극적으로 코드 리뷰를 왜 해야 하는지와 같은 이견을 좁히는 과정이 쉽지 않았습니다. 하지만 토른을 하면서 하나씩 규칙을 세우고, 습관이 되면서 지금은 모두가 반드시 해야하는 일로 인식하고 있습니다. 이러한 경험을 바탕으로 코드 리뷰에 대한 생각을 정리한 글을 통해 아직 코드 리뷰를 하지 않는 팀이 있다면 한 번쯤 고려해보면 좋을 것 같습니다.