Code Review, 왜 해야되나요?

과거에 코드리뷰가 없는 곳에서 코드리뷰 문화를 도입하려고 하다 보니 어느 정도 궁금해하는 분들도 있고 거부감도 있으신 분들이 있어 이를 해소하기 위해서 간단하게 발표했던 내용을 기록할 겸, 블로그에 작성해두려고 한다.

 

코드리뷰 자체에 대한 개인적인 의견과 왜 해야하는지에 대한 생각을 담은 글입니다, 사견이 진하게 들어가 있습니다.

---

코드리뷰라고 하면, 코드 자체에 대한 회고와 더불어 만들어낸 결과물에 대한 다른 사람의 의견을 들을 수 있는 기회라고 생각한다. 어느 정도의 시간이 소요되긴 하지만, 소요되는 시간보다 코드리뷰를 통해 예방할 수 있는 문제들이나 개인의 성장을 통한 장기적인 생산성 향상 등 다양한 기대효과가 더 큰 만큼 코드를 같이 섞는 사람이 없는 게 아니라면 개인적으로는 하는 게 당연하다고 생각한다.

 

한 프로덕트를 여러 사람이 보게 되지만, 유지보수를 하는 과정에서 첫 코드 작성자가 끝까지 그 파트를 맡는다면 어쩌면 필요 없을 수도 있겠다. 본인만 코드를 알고 이해하고 있으면 추가적인 비용이 발생하지 않고도 이를 수정, 개선할 수 있을 테니. 

그렇지만 이렇게 개발이 가능한 사례는 본적도, 들어본적도 없다. 결국 사람이 여럿 거치게 되면 이를 이해하고 설명시키는 과정이 추가적으로도 필요한데 이 과정을 코드리뷰를 통해서 대신해 줄수도 있게 된다. 본인의 코드는 본인이 제일 잘 알지 않겠는가?

앞선 내용도 충분히 중요하지만, 코드리뷰를 하는 이유 중 가장 큰 부분은 이번 슬라이드라고 생각한다.

일을 하다보면 당연히 내가 경험하지 못한 일들도 발생하고, 예측하지 못한 이슈도 발생할 수 있다. 특히, 무언가 새로운 것을 시도해보려고 했을 때 가장 많이 발생할 수 있다. 이를 코드리뷰를 통해서 공유하고 다른 사람들의 의견을 들어볼 수도 있으며, 실제로 리뷰어 중 경험을 해본 사람이 있다면 이를 사전에 방지하는 것 또한 어려운 일이 아니다.

다같이 모른다면 모르는 대로 개인이 알고있는 아이디어를 공유함으로서 더 좋은 답을 찾아가는 과정이기도 하다.

 

이를 위해서는 당연히 Reviewer의 역할과 역량도 중요하지만, 무엇보다도 리뷰를 받는 Author의 노력이 정말 중요하다고 생각한다.

그도 그럴 것이 1.내 코드를 가장 잘 아는 사람은 나이고 하면서 2.어려웠던 점을 느끼는 것 또한 나일 뿐 아니라 코드를 이해하기 까지의 과정이 정량적으로도 Reviewer 보다 Author가 많다. 이를 얼마나 잘 이해시키는지에 따라서도 당연히 Reviewer가 해줄 수 있는 리뷰의 품질이 달라질 수 밖에 없지 않겠는가.

 

당시에 공유했던 PR 관련 규칙들은 다음과 같았다.

1. 가장 먼저 개발한 코드가 어떤 목적으로 만들어졌는지 공유할 것
2. 개발 과정에서 어려웠던 부분이 무엇이었는지 공유할 것
3. 간단한 구현이어도 '왜'를 담아서 3줄 이상은 작성해 볼 것

이렇게 함으로서, 작성하는 과정에서도 본인의 코드를 돌아볼 수 있고 Reviewer 입장에서도 코드를 이해하기 쉬워진다고 생각했다. 도입 후에 익숙해지기까지는 꽤나 시간이 걸렸지만, 의미있는 일이라고 생각했다.

 

Reviewer와 Author끼리 나름의 주의사항도 있었는데, 크게 세가지를 담았다.

• 코드가 왜 멋진지, 멋지지 않은지가 아니라 품질 자체에 대한 검수를 하는 것
• 코드에 대한 비판이 자기 자신을 향한 비판이 아님을 인지할 것
• 당연히 잘한 것과 아쉬운 것이 있고 둘다 공유할 것

 

그래서 코드리뷰란?

토픽을 기반으로 경험과 지식공유가 용이하고
소스코드를 서로 공유하고 의견을 주고 받는 일종의 SNS 기능을 하며
이 과정에서 다같이 배우고 성장할 수 있는 문화

 

개인적으로 내린 결론이다. 발표했던 시기가 약 2년정도 지났고 지금도 스크립트를 보며 리뷰를 했지만, 코드리뷰에 대한 생각이 바뀌진 않았다. 개발팀이 무언가 한 문화를 가져야 한다면, 코드리뷰가 아닐까?

 

간만에 사견이 듬뿍담긴 글을 작성했다. 아직까지 찾아주는 사람이 많이 없는 블로그이지만, 혹시 이 글을 봤다면 당신의 의견도 궁금하다.