우리, 코드 리뷰 해볼래?

게으른 사람은 이제야 퇴고를 하고 후기를 올립니다...

 

🤔 왜 코드 리뷰를 시작했나요?

현재 제가 다니고 있는 회사에는 코드 리뷰 문화가 없습니다. 사내 소스 관리 툴인 GitLab에 Merge Request를 올리고 본인이 본인의 Merge Request를 승인하는 방식으로 코드를 관리하고 있죠. 빠르게 패치해야하는 hotfix건이 많아 코드 리뷰를 할 시간도 없고, 리뷰 문화에 익숙한 사람도 없는 이유로 코드 리뷰 문화를 적용하지 않고 있다고 추측하고 있습니다.

 

코드 리뷰를 진행하지 않고 본인의 코드를 본인이 Merge하는 절차를 따르다 보니 크고 작은 문제들과 불편함이 생겼습니다. 대표적인 케이스들을 예를 들어보면,

1. 한 쪽 파트에서 수정한 사항 때문에 다른 쪽 파트 로직도 함께 바뀌어야 할 때 전달 및 검토가 되지 않는 경우
2. 미처 발견하지 못한 오타가 있는 경우

또 이런 아쉬움도 생겼습니다.

1. 다른 사람의 입장에서 생각한 새로운 로직을 제안받고 싶다.
2. 리팩토링 등으로 코드나 로직이 바뀌었을 때 그렇게 변경한 이유가 궁금하다.
3. 변경사항에 대한 자세한 로그를 남기고 싶다.

이런 불편함과 아쉬움을 조금이라도 덜어보고자 저는 함께 프로젝트를 진행 중인 동기에게 간단한 얼레벌레 코드 리뷰를 제안했고 다행히도 좋은 피드백이 돌아와 둘이서라도 진행해보기로 하였습니다. 🏁

 

✨ Merge Request, 어떻게 하지? 

Template 만들기

처음 리뷰 문화를 제안한 이유 중 하나가 코드 및 로직이 원래 어땠는데 어떻게 바뀌었는지, 왜 이렇게 바뀌었는지를 공유하고 싶다는 생각이었습니다. 또한, 높은 수준의 코드 리뷰가 목적이 아니었기 때문에 저희들끼리 가장 필요하다고 생각한 AS-IS와 TO-BE 그리고 변경 이유를 담아 아래와 같이 템플릿을 만들어 사용하고 있습니다.

템플릿은 저희가 코드 리뷰를 작성하는 과정에서 불편한 점이나 필요 없는 항목, 필요한 항목이 있을 때마다 논의를 통해 추가 및 제거해가며 발전해나가고 있습니다.

규칙 정하기

아무래도 서로의 코드를 분석하고 특정 부분에 대해 자신의 의견을 표정이 보이는 말이 아니라 텍스트로 더하는 일이다 보니 혹시나 감정이 상할 일이 있을까 조금 걱정이 들었습니다. 또, 앞에서 말했듯 급한 hotfix건들이 많은지라 리뷰 없이 바로 올라갈 작업에 대한 기준도 정해야 했죠. 그래서 다음과 같이 정해졌습니다.

1. 서로의 잘못이나 오류를 지적하려는 의도가 아니라는 걸 항상 기억하자.
2. 당장 운영에 문제가 있는 hotfix건과 주석 제거와 같이 로직에 큰 변화가 없는 건은 스킵하자.
3. commit이 너무 많으면 코드를 검토하기 힘드니 작은 작업 및 기능 단위로 MR(Merge Request)를 올리자.

실제로 얼마 전 컨디션도 안 좋고 다른 업무로 바빠서 올라온 리뷰의 코드가 잘 읽히지 않아 한참 보고 있었더니 함께 하는 동기가 혹시 코드 리뷰 때문에 불편했는지 물어본 일도 생겼어요. 당연히 아니었고 필사적으로 리뷰 때문이 아니라고 해명했습니다 🤣

코드 리뷰 작성하기

템플릿을 만들고 본격적인 리뷰를 하려고 하였으나...! 잠시 잊고 있었던 사실이 떠올랐습니다. 백엔드 동기는 자바스크립트를, 저는 자바를 졸업한 후 회사 업무를 하며 약 1년간 사용하지 않았다는 사실을요.

알긴 아는데... 모르겠어.......

그래서 저희는 각자 사용하고 있는 언어를 완벽하게 분석해서 로직의 효율이나 더 나은 활용법 등을 제안하는 등의 고차원적인 리뷰보다 기본적인 것에 집중하기로 했습니다.

각각의 언어 사용법이나 로직에 대해 질문하기, 오타나 기본적인 문법적 오류 고쳐주기, 코드 작성 규칙과 같은 기타 사항 제안하기와 같이 그야말로 얕은 코드 리뷰를 진행한 거죠. 아래는 실제로 주고받은 피드백과 코멘트입니다.

언어에 대해 질문하기

오타나 문법적 오류 고쳐주기

제안하기

 

🎙 지금까지 코드 리뷰, 어땠어?

지금까지 약 3개월 정도 리뷰를 진행한 점을 이렇게 정리해볼 수 있을 것 같습니다.

장점

• 다시 한 번 내가 작성한 코드와 로직을 검토해 실수를 줄일 수 있다.
• 다른 파트에서의 처리가 어떻게 진행되는지 알 수 있다.
• 커밋 메세지와 주석, 네이밍에 신경을 쓰게 된다.
• 다른 사람이 읽었을 때 이해가 잘 되는 코드를 작성하기 위해 노력한다.

단점

• 변경된 코드가 적용되기까지 꽤 긴 시간이 걸린다.
• 서로의 언어에 대한 이해가 완벽하지 않아 높은 수준의 코드 리뷰가 힘들다.

종합 후기

비록 시간이 많이 걸리고 서로 사용하는 언어가 달라 완벽한 이해는 어렵지만 코드 리뷰 과정에서 누락된 조건이나 수정사항을 발견하고 수정하는 과정과 개발 방식 등을 제안함으로써 코드의 품질을 높일 수 있었다고 생각합니다.

 

특히 다른 사람이 내가 작성한 코드를 읽고 이 코드가 어떤 의도를 가지고 작성되었으며 어떤 동작을 하는지 한눈에 알아볼 수 있도록 코드를 작성하기 위해 노력을 기울이게 된 점이 가장 좋은 변화라고 느꼈습니다. 언제나 그렇게 누가 봐도 이해할 수 있는 코드를 짜야지! 하는 생각을 하기만 했지 실천에 옮기진 않았기 때문이죠....... 코드 리뷰를 도입함으로써 작은 노력을 하게 된 것 같아 기쁩니다.

또한 새로운 구조나 코드 스타일을 제안받고 그것이 특정 언어에 맞는지 관련 서적과 다른 사람들의 경우를 찾아보며 더 나은, 더 친절한 코드를 만들기 위해 대화하는 과정이 굉장히 기억에 남습니다. 제안받은 패턴이나 방식이 해당 언어에 적합한지, 적용했을 때 정말 더 나은 코드가 되는지 한참 동안 얘기한 적이 있습니다. 그 과정에서 새로운 제안과 그것을 뒷받침하는 이유 뿐만 아니라 구조나 스타일을 적용시킬 때에는 해당 언어의 기본적인 구조 및 이론을 생각해봐야 정말 맞는 방법인지 알 수 있다는 점을 배울 수 있었습니다.

 

✍ 앞으로는 어떻게 할 거야?

함께 도입한 동기와 이야기해본 결과 코드 리뷰를 계속해서 이어나가기로 결정했습니다. 위에서 언급했던 것과 같이 당장 서비스 운영에 심각한 문제를 일으키는 오류 패치를 제외하고는 모든 Merge Request에 대해 코드 리뷰를 진행할 계획입니다.

 

주니어 개발자 두 명이서 도입하고 진행하는 작은 문화이기 때문에 제대로 하고 있는 게 맞는지, 도움이 되는 건지 가끔씩 의문점이 생기긴 하지만 리뷰를 진행하는 과정에서 새로 배우는 것도, 새로 배운 사실을 통해 발전해나는 것도 경험이자 공부가 될 것 같다고 느꼈습니다. 좋은 선례로 남아 회사 내 개발 문화를 조직하는데 도움이 되었으면 좋겠네요! 🥰

 

다른 분들은 코드 리뷰를 어떻게 진행하시나요? 저희의 방식에 조언이나 다른 좋은 아이디어를 공유하고 싶은 부분이 있으시다면 자유롭게 말씀해주세요! 의견과 저희의 경험을 토대로 더 풍부한 리뷰 문화를 만들어나가 보겠습니다!

 

---

동기의 코드 리뷰 회고도 있습니다! 👉 https://shinsunyoung.tistory.com/92