[ Study ] 코드 리뷰를 하는 이유가 무엇일까?

이번 스터디를 진행하면서 처음으로 코드 리뷰라는 것을 경험할 수 있었다.

학부시절에 내가 가지고 있던 마인드는 다음과 같았다.

 

내가 한게 잘 동작하고 있고, 각자 자기가 맡은 부분에 대해서 잘 알고 있으면 되는 거 아닌가?
그리고 리뷰를 한다고해서 얻는 이점은 무엇이 있을까?
하면 좋은건 알겠는데.. 어떤 방식으로 진행하는지 알 수 있는 방법은??

 

하지만 이는 너무나도 잘못된 생각이라는 것을 첫 인턴생활을 하면서 금세 알아버렸다.

각자 맡은 업무를 하느라 팀 동료의 코드를 보는 활동이 일절 없었으며 이러한 활동 자체를 하질 않았다.

해봤자 매주 오전에 모여 각자 본인이 차주에 진행했던 업무에 대한 내용과 이번 주의 계획에 관해 얘기를 하는 것이 끝이었다.

결국 다른 동료가 작성한 부분에 대해서 궁금증이 생기면 그때 개인적으로 질문하고 답변해주고 그랬던 것 같았다.

 

하지만 이번 스터디의 첫 코드리뷰를 참여하면서 참 많은 생각들이 들었다.

우선, 당연하겠지만 사람마다 작성한 코드는 모두 다르다는 점이 매우 흥미로웠다.

같은 베이스 코드를 가지고 작업하는 것이었는데 내가 작성한 부분 중 " ~~ 부분은 좀 비슷하거나 곂치겠지? "라는 생각이 있었는데

이는 전혀 아니었다. 모두 다 달랐고 생각하는 방식도 너무 달랐다. 그런 점에 있어서 굉장히 흥미로웠다.

그전에 필요한 활동은 우선 내가 작성한 코드에 대해서는 왜 그렇게 작성을 했는지에 대한 명확한 근거가 있어야 한다.

그래야 다른 리뷰어(혹은 동료)가 질문을 했을 때 답변을 할 수 있기 때문이다.

이 스터디에서는 리더가 일방적으로 리뷰만 해주는 것이 아니라, 같이 공부하고있는 스터디 동기들과도 서로 리뷰를 주고받을 수 있다는 점에서 굉장히 유의미하다고 생각된다.

또한 다른 사람의 코드를 읽을 줄 아는 능력이 어느정도 필요하다고 생각했다. 그리고 내가 잘 이해가 되지 않는 부분에 있어서는 질문할 줄 알아야 한다.

마지막으로는 사소하더라도 칭찬 또는 격려의 코멘트를 받으니 스스로 매우 뿌듯함도 느낄 수 있었다.

이러한 활동으로 내가 작성한 코드에 대한 확실함이 있어야 함을 느꼈고, 다른 사람의 피드백을 적극 수용할 수 있어야 하며 반대로 내가 다른 사람의 코드를 해석하고 질문도 할 줄 알아야 했다.

어찌 보면 리뷰를 하기 전 엄청난 능력이 필요하다고 생각했고 상당히 많은 지식을 알아야 한다는 생각을 가진 나 자신이 부끄럽다. 처음에는 내 코드를 남에게 보여준다는 게 부끄럽기도 했지만, 막상 공유하고 질문도 받고 이러다 보니 오히려 댓글이 안 달렸다면 허무했을 것 같다.

앞으로 있을 팀활동에 있어서는 좀 더 자신감을 가질 수 있게 된 계기가 될 것이라고 나는 생각한다!

더 나아가 코드 리뷰에 관련하여 궁금증이 생겨서 찾아보다가 아래의 글을 접하게 되었다.

https://brunch.co.kr/@cleancode/43

코드 리뷰 관련 질문!!

올해 초 OKKY에서 백명석님의 온라인으로 진행한 글과 강연 영상을 보았다. 영상에서 핵심 내용만 내 나름대로 정리를 해보려고 한다.

 

왜 코드 리뷰를 해야 하나?

1. 개발 생산성

- 우리는 지금 빠르게 변화하고 있는 시대에 살고 있다.

- 출시 회차는 개발자수와 비례한다. 반면 회차가 늘어갈수록 개발자는 많지만 생산성은 반대로 떨어진다.

- 좋은 설계를 하지 않고 개발을 하게 되면 순간적인 생산성은 좋지만 어느 일정 시점이 지나면서 이전에 개발했던 기술 부채들을 해결하는데 시간을 투자하여 생산성이 떨어지게 된다.

2. SW공학 특성

- 공학의 최종 목적은 빌드할 수 있는 종류의 재생산이 가능한 문서를 만들어내는 것이다.

- 건축에서의 설계와 빌드는 분리되어 있음. 또한 빌드 비용이 비싸며 유지보수 비용이 상대적으로 낮다.

- 반면 SW 공학의 설계와 빌드에서는 건축과는 좀 다르다. 따라서 재생산 가능한 문서를 만드는것 즉, 소스코드가 SW공학에서 설계단계이고 SW 빌드는 곧 컴파일을 의미한다.

- 따라서 좋은 설계는 곧 클린 코드이며 SW 엔지니어는 설계를 잘하는 사람(코드를 잘 작성하는 사람)이다.

3. SW 장인정신

- 본인의 지식과 경험을 공유하는 것이 전문성을 찾춘 개발자 육성에 있어 중요하다.

- 이를 공유하는 활동이 바로 코드 리뷰이다. 당장 할 수 있는 활동이며 좋은 개발자가 되기 위한 활동

 

코드 리뷰의 목적?

주된 목적은 품질 문제 검수이다. 버그 및 장애를 개선하기 위함이라고 볼 수 있다.

또 다른 목적으로는 학습 및 지식 전달에 있다. 공유를 통해 역량을 증대할 수 있고 리뷰 과정에서 지식(하드 스킬, 소프트 스킬)을 얻을 수 있음.

연차가 비슷하면 주로 하드 스킬에 관련된 기술적인 얘기를 주고받지만 시니어가 주니어에게 설명을 하려고 할 때 시니어는 주니어에게 어떻게 하면 더 잘 이해할 수 있도록 할 수 있을까? 와 같은 스킬을 기를 수 있다.

또한 내가 가장 공감되는 말로 상호 책임감 증대가 있다. 만약 10명에게 10가지 일이 주어진다고 할 때, 2-3가지의 업무를 갖고 2-3명이서 그룹을 이루면 서로에게 관심도 갖게 될 것이고 의사소통도 자주 하게 될 것이다. 이로 인해 팀워크와 결속이 증대되는 효과를 받을 수 있다.

반면, 각자 일을 1개씩 부여받아서 진행한다면, 우리는 과연 같은 팀이 맞을까? 라는 생각을 하기 마련이다. 이에 너무 공감하는 바이다.

 

코드 리뷰의 절차?

 

1. 작성자가 리뷰어들에게 변경 이력을 전달
2. 리뷰어들은 변경 이력을 확인하고 작성자에게 피드백 전달
3. (1)과 (2)의 과정을 반복하다가 리뷰어가 작성자의 작성된 부분을 승인
4. 팀 레포에 병합

 

좋은 PR의 예시

Description
: ~~ 기능에 대한 추가 및 ~~로직 개선

How To Test
: 테스트를 할 수 있는 방법에 대해서 기술

Commits
1. ~~~ 추가
2. [메소드이름] : ~~ 는 ~~ 기능을 하며 ~~를 제공함
3. ~~ 코드 변경
4. ~~ 주석 정리 및 수정

저자는 리뷰를 받고자 하는 내용에 대해서 최대한 자세하고 상세하게 작성해야 하며 리뷰어의 시간을 절약할 수 있도록 해야 한다.

또한 여기서의 핵심은 작은 단위로 PR을 올릴 수 있도록 해야 한다는 것이다. 양이 많거나 변경 이력을 상세하게 작성하지 않는다면 오히려 리뷰어들을 힘들게 하기 때문!

 

코드 리뷰가 어려운 이유?

In aviation, for example, people who greatly overestimate their level of skills are all dead

- 코드에 대한 비판을 본인에 대한 비판으로 오해하는 경우가 있어 갈등을 만들어 낼 수 있음. 이에 유의하자

 

 

" 코드 리뷰의 목적은 비난이 아니라 배움이다. "