코드 리뷰

개요

지난 6개월간 여러 개발자들과 협업을 진행하면서 많은 양의 코드를 기회가 있었고 다양한 방식으로 옳은 방법을 찾기 위해 함께 고민했었다. 이 과정에서 어떤 이들은 코드 리뷰는 신랄하게 비판적이어야 한다며, 다른 이들은 코드 리뷰를 굳이 비판적으로만 할 필요는 없다며 다양한 의견들을 제시해 주었었는데, 여전히 어떤 방법이 옳은 방향인지는 모르겠지만 이 글을 통해서 무엇이 궁극적으로 팀을 위한 코드 리뷰인지 다시금 생각해보고자 한다.

 

코드 리뷰 대체 왜 해야만 할까? 그리고 어떻게 해야 좋을까?

기업들의 기술 블로그 뿐만 아니라 코드 리뷰에 대한 다양한 의견들을 찾아보면 결국 코드 리뷰란 개발자가 다른 개발자의 코드를 확인하면서 서로의 지식을 공유할 뿐만 아니라 업무의 효율을 올리고 결론적으로 더 나은 방향으로 나아가고자 함이다. 이 과정에서 코드 리뷰는 어떤 역할을 해줄 수 있을까?

코드 리뷰는 최소한의 안전 장치

저장소에는 다양한 브랜치가 존재하고 언제든 브랜치를 헷갈려서 PR을 날릴 수 있는 맹점이 존재한다. (물론 설정을 통해 기본적으로 PR을 올리는 브랜치를 변경할 수 있고.. 항상 조심해야하지만...) 이런 경우 코드 리뷰를 통해서 최소한의 안전을 유지할 수 있다. (develop branch에 병합할 것을 갑자기 main branch에 꽂는 다던지... 이런 불상사를 막을 수 있다) https://github.com/Kernel360/f1-KernelSquare-backend/pull/297

 

[fix] develop에 안올린 범인을 잡아왔습니다. by fingersdanny · Pull Request #297 · Kernel360/f1-KernelSquare-backe

PR을 보내기 전에 확인해주세요!! 컨벤션에 맞게 작성했습니다. 컨벤션 확인은 여기 변경 사항에 대한 테스트를 했습니다. 세부 내용 곤장 100대

github.com

이런 불상사를 막아야 한다.. 미리 잘 확인하고 PR을 올리도록 하자..

코드 리뷰를 통한 동반 성장..

개발 커뮤니티는 끊임없이 성장하고 매년 새로운 기술이 나온다. 이에 더하여 이미 존재하는 기술들을 다 배우는 것조차도 벅찰때가 분명히 존재한다. "백지장도 맞들면 낫다"라는 말이 있듯이 코드 리뷰를 통해 여러가지 지식들을 적절하게 필요한 곳에서 배울 수 있다라는 장점이 있다.

 

대 과거의... 코드 리뷰 소환

이처럼 기존의 사용하였지만 잘 이해하지 못했던 지식과 아예 새로운 지식들을 다른 사람들의 눈을 통해 보면서 더 효율적으로 성장할 수 있는 발판이 된다.

 

그러면 우리는 어떤 식으로 코드 리뷰를 진행해야할까?

https://tech.kakao.com/2022/03/17/2022-newkrew-onboarding-codereview/

 

효과적인 코드리뷰를 위한 리뷰어의 자세

안녕하세요, 톡FE파트에서 톡명함 서비스를 개발하고 있는 Kay입니다.저는 2022년 신입 공채 기술 온보딩 교육의 코드 리뷰어로 활동을 했는데요, 이를 통해 얻었던 경험과 효과적인 코드 리뷰를

tech.kakao.com

https://blog.hwahae.co.kr/all/tech/12534

 

지속가능한 코드리뷰 문화를 만드는 여정 – 화해 블로그 | 기술 블로그

지속가능한 코드리뷰 문화를 만드는 여정 코드리뷰 목적부터 시작하여 리뷰어 선정 변천 과정, 코드리뷰 비용을 줄이면서 효과적으로 리뷰하는 방법 순서로, 화해팀에서 지속 가능한 코드리뷰

blog-wp.hwahae.co.kr

 

이미 여러 개발 문화가 성숙한 기업에서는 코드 리뷰에 대한 각자의 철학과 나름의 기준들을 가지고 코드 리뷰를 진행한다. 리뷰가 단순히 리뷰에서 그치지 않고 팀 전체에게 도움이 되려면 리뷰 문화 또한 정착해있어야 하고 이를 통한 리뷰를 진행하며 단순히 검사를 받는게 아닌 "함께 자라기"를 하고 있는 것이라 생각되어야 한다.

 

이에 따라서 이번 프로젝트 동안 그리고 그 전의 코드 리뷰를 주고 받으면서 리뷰 규칙에 포함되었을 때 좋았고, 위의 기술 블로그 글에서도 소개한 리뷰 규칙들을 정리해보자면..

 

  • 리뷰를 통한 변경을 원한다면 코드 작성자에게 해당 이유를 전달해야한다. 
  • 리뷰는 숙제 검사가 아니라 자신의 의견을 다른 사람에게 보여주는 장이다. 옳고 그름을 따지기 보다는 동료가 옳은 방향으로 나갈 수 있도록 해야한다.
  • 동료가 작성한 코드가 완벽하다고 생각하는가? 그러면 칭찬해주자. 굳이 리뷰를 위한 리뷰를 남길 필요가 없다.
  • 굳이 친절하게 작성하자. 리뷰는 상대방의 개발 실력을 평가하는 자리도 아니고 굳이 기분을 나쁘게 만들 필요도 없다. (벼는 익을수록 고개를 숙인다.)

위의 내용이 꼭 포함되어 있어야만 정상적으로 코드 리뷰를 할 수 있을까? 그런 것은 아니다. 하지만 많은 개발자들이 시행착오 끝에 공통적으로 내린 결론들에 포함되어 있다면 한 번은 들여다 봐도 좋지 않을까?

 

마치며..

이번 글은 질문과 함께 마무리하고자 한다. 다음과 같은 코드를 리뷰하라고 받았을 때 어떤 식으로 리뷰를 남기고 싶은가?

 

아래 코드는 1부터 100까지 for문을 순회하면서 총합을 구하여 출력하는 코드이다.

 

위의 코드를 리뷰하라는 요청이 있었다면 어떤 식으로 리뷰를 할 것 같은가? 다음과 같은 질문들과 같이 생각해보자.

 

  • 왜 stream을 쓰지 않았는지 궁금한가?
  • 조금 더 객체지향적으로 작성할 수도 있는가?
  • 어떤 말투의 리뷰를 작성할 것인가?
  • 더 개선할 수 있는 방안은 무엇일까?

'선순환' 카테고리의 다른 글

오픈 소스 기여하기  (0) 2024.03.31