본문 바로가기

Joyful 개발

[GitHub] 아직 코드리뷰가 익숙하지 않은 분들을 위한... 코드리뷰는 어떻게 해야할까? (+ GitHub에서 PR로 코드리뷰 하는 법 )

728x90
반응형

최근 약 한 달 전부터 넥스트스텝의 '블랙커피' 스터디에 참여하며 매주 스터디원들과 함께 상호 코드리뷰를 하고 있다. 

 

스터디를 시작하기 전까지는 코드리뷰를 받아보기만 했고, 직접 리뷰를 해본 경험은 없었어서

처음엔 내가 코드리뷰를 한다는 것 자체가 낯설기도 하고, 막막하기까지 했었다.

 

하지만 매주 코드리뷰를 반복적으로 진행하다 보니 어느덧 지금은 처음보다 코드리뷰가 훨씬 익숙해지게 되었다.

 

아직은 많이 부족하지만,  코드리뷰를 많이 해보지 않은 분, 코드리뷰가 처음인 분들에게 나의 경험이 조금이나마 도움이 되길 바라며 코드리뷰에 대해 간단히 포스팅해본다.

 

코드리뷰?


코드리뷰는 간단히 말해 상대방의 코드를 검토해보고 피드백을 남겨주는 것이다.   

 

여러 서비스 기업에서 이미 코드리뷰의 장점을 알아 코드리뷰 문화가 활성화되어 있고,

나 또한 이번 스터디에서 상호 코드리뷰 를 진행하면서 그 장점을 직접 느낄 수 있었다. 

 


<  내가 느낀 상호 코드리뷰의 장점  >

 

1. 코드를 더 신경 써서 짜게 된다 (코드 작성자의 경우

- 리뷰를 받아야 한다는 사실이 나를 더 부지런하게 만든다.

- 효율적인 코드, 읽기 좋은 코드에 대한 고민을 하게 해, 협업할 수 있는 개발을 할 수 있다. 

 

2. 다른 사람의 코드를 읽어보는 연습이 된다. (리뷰어의 경우

- 내가 짜지 않은 처음 보는 코드를 이해하고, 분석해 나가는 능력이 길러진다. 

 

3. 나만의 사고에 갇히지 않도록 도움을 받는다. 

- 특정 기능에 대해 항상 같은 방식으로만 구현해왔다면, 상호 리뷰를 통해 여러 구현 방식을 접해 볼 수 있다.

- 내가 미처 몰랐던 버그나 중복 코드의 사용을 알 수 있다.

 

4. 새로운 기술들을 알게 되고, 공부할 수 있는 키워드를 얻게 된다. 

 

 

 

 

코드리뷰는 어떻게 하는 게 좋을까?


코드리뷰를 받는 사람과 코드리뷰를 하는 사람 두 가지로 나누어 설명을 해보려고한다.

 

코드리뷰를 받는 사람 ( 코드 작성자 ) 

 

1. 리뷰어를 위해 충분한 정보를 제공해준다.

- 코드의 구조, 설계 방식, 왜 이렇게 구현했는지, 왜 코드를 변경하게 되었는지 등 PR요청 시 충분한 설명을 함께 첨부한다면 리뷰어에게 더 좋은 리뷰를 받을 수 있을 것이다.

 

2. ESLint, Prettier 등의 툴을 이용해 코드 스타일을 보기 편하도록 정리한다.

 

3. 리뷰를 받았다면 이모지나 코멘트를 남겨준다.

-  질문에 대해선 대답을 해주고, 다른 리뷰에 대해서는 리뷰를 잘 받았다는 코멘트를 남기거나 이모지를 달아주면 훨씬 더 서로 소통하는 코드리뷰가 될 것이다.

 


코드리뷰를 하는 사람 ( 리뷰어 )

 

1. 기능이 잘 동작하는지 확인해본다

- 코드 리뷰 때 문제가 없었는데, 정작 기능은 제대로 동작하지 않는 경우가 있을 수 있으므로 로컬에서 pr을 확인해본다.

(참고 - 다른 사람의 pr을 로컬에서 확인하는 방법)

 

[Git] 다른 사람의 pr을 로컬에서 확인하는 법, pull request 가져오기

코드리뷰를 하다보면 다른 사람의 pull request를 로컬로 가져와 실행해볼 때가 있다. 다른 사람의 pr을 로컬에서 확인하려면 아래처럼 실행하면 된다. $ git clone ${ 저장소 주소 } $ cd ${ 저장소 이름 }

joyful-development.tistory.com

 

2. 네이밍이 적절한지 확인한다.

- 변수명, 함수명, 클래스나 컴포넌트, 폴더명 등 

 

3. 코드를 더 간단하게 작성할 수 있는 방법이 있는지 확인한다.

 

4. 중복된 코드나, 불필요한 코드가 없는지 확인한다.

 

5. 코드를 읽으며 궁금한 점이 있으면 질문한다.

 

6.  배울만한 점, 내가 몰랐던 점들에 대해 말하고, 잘한 부분은 칭찬한다.

 

 

+ 좋은 커뮤니케이션 방법

 

 - 예의를 갖춘다.

 

 - 대답을 강요하거나 지시하는 말투는 사용하지 말고,  제안하거나 질문하는 방식으로 말한다.

ex ) 변수 네이밍이 애매하고 이상한데요 좀 더 명확하게 바꾸세요 ( x )
→  변수 네이밍을 ㅇㅇㅇ으로 지은 이유가 있을까요?
      역할을 알아보기 힘든 것 같은데 ㅁㅁㅁ으로 바꿔서 사용하는 건 어떨까요? ( o )

 

- 피드백의 이유를 이해할 수 있도록 알려준다.

ex ) 이건 빼는 게 낫겠네요 ( x )
→  이 부분은 유틸 함수로 분리해서 관리하면 훨씬 코드가 깔끔해질 것 같아요 ( o )

 

 


 

이 정도만 알고 있어도 누구나 어렵지 않게 코드리뷰를 시작할 수 있을 것 같다.

어렵게 생각하지 말고 하나 둘씩 리뷰를 남기는 경험을 계속 하다보면 코드리뷰가 점차 익숙해질 것이다.

 

 

깃헙의 PR로 코드리뷰 하는 법


+ 아직 코드리뷰를 한 번도 해보지 않은  분들을 위해 깃헙 PR로 코드리뷰하는 방법 추가

 

우선 리뷰하고자 하는 pr에 들어가 상단의 Files changed 버튼을 클릭한다.

 

 

 

그럼 전체 코드의 변경사항을 쭉 확인할 수 있는데 

 

리뷰하고자 하는 코드 옆에 + 버튼을 클릭해서 리뷰를 남길 수 있다. 드래그를 통해 여러 줄의 코드에 대한 리뷰를 남기는 것도 가능하다. 

 

 

위처럼 리뷰를 남기고 Add review comment 버튼을 누르면 

 

리뷰가 남겨지고 Pending이라는 라벨이 붙게 되는데, 이 리뷰는 현재 리뷰를 남긴 본인만 확인이 가능하다는 뜻이다. 

 

 

리뷰를 전부 끝낸 뒤 오른쪽 상단의 Finish your review 버튼을 클릭하고 

 

 

최종 코멘트와 함께 Submit review 버튼을 눌러 리뷰를 마무리해주면

 

 

작성한 모든 리뷰가 최종 코멘트와 함께 업로드되고, 아까 붙어있던 Pending 라벨이 사라진 것도 확인할 수 있다. 

 

 

 

 

728x90
반응형