개발/기타

코드 리뷰의 문제점과 개선방안

JonghwanWon 2022. 5. 28. 23:20

이직 후 새로운 회사에서는 이전까지 프로젝트 일정을 핑계 삼아 제대로 하지 못한 Pull Request(PR)와 코드 리뷰 문화에 익숙해지기 시작할 때쯤 느꼈던 불편한 부분들과 이를 어떻게 개선하고자 하였는지에 대해 경험을 공유합니다.


어떤 문제가 발생했나?

제목에만 의존적인 PR

거의 대부분이 제목에만 의존적인 PR로 제목과 함께 변경된 코드들로만 내용을 Reviewer가 추측하고 있었고, 간혹 리뷰를 직접 말로 주고받고 하다보니 중복되는 Comment가 발생하기도 했다.

개발자는 코드로 말한다지만...

코드가 자신을 설명할 수 있다면 정말 좋겠지만, 문제영역과 깊숙하게 연관되어 있는 내용에 대해서는 코드만으로 설명이 어려울 때가 많았다.

 

오랜 기간 진행되어온 프로젝트로 각자 담당하고 있는 파트가 존재했고 담당한 파트가 아닌 부분에 대해서는 점차 복잡해짐에 따라 소홀하기도 하고 책임감의 부재 또한 발생하게 되었다.

 

이러한 상황들로 인해 코드 리뷰라기보다, "나 오늘 이렇게 일 했어요"라는 일일 업무보고서처럼 보이기도 했다.

공격적인 리뷰 태도

소프트웨어 엔지니어링의 근간에는 인간이 있다.
개발자 커뮤니티에서 다른 사람을 괴롭히는건 아무 가치가 없다.

 

누군가 작성 한 코드가 형편없다고 가정해보자.

"이게 좋은 방법인가요? 관련 문서를 다시 읽어보세요"

"더 좋은 방법 없나요?"

이와 같은 공격적인 형태의 리뷰는 당장의 소프트웨어 코드 베이스에는 나쁜 코드가 심어지는 것을 방지하겠지만 이러한 형태의 리뷰로는 더 나은 조직이 되기는 어려울 것이다.

 

"이 중복된 부분은 제거하는게 좋을 것 같습니다"

"이 부분은 이해하기 어려운데 조금 더 명확해지도록 리팩터링 해 줄 수 있을까요?"

이와 같은 친절한 리뷰는 개발자의 잘못된 방향과 "코드"에 가 잘못되었다는 것을 인지시켜 주며, 나쁜 코드가 심어지는 것을 방지했다.

 

코드를 읽고 작성할 개발자는 세상에 많다. 하지만 같이 일하고 싶은 개발자는 누구일까?

원인은 무엇일까?

모든 문제의 원인은 커뮤니케이션에 있는 것으로 보였다.

개발자들이 모두 많은 업무량에 지쳐있는 상태로, 그로인해 내 업무만을 처리하기 위해 각자 달리고 있었다.

 

가장 처음 생각한 것은 PR Template의 도입이었다.

자신이 작성한 코드에 대해서 설명을 하는 것은 다른 개발자로 하여금 이해할 수 있도록 코드를 짜야한다는 말이기도 하고

내가 무슨 일을 하는지 정확히 알고있으며 개발자 자신의 의도를 명확히 표현할 수 있는 방법이 될 것이라 생각했다.

 

두 번째로 시도한 방법은 코드에서 잠시 떨어져 함께 소통하는 시간을 만드는 것이라 생각했다.

자연스럽게 각자가 생각하는 좋은 코드란 무엇인지, 책에서 정의하는 내용은 무엇인지 이에 서로 의견을 나누며 서로의 개발 관점들과 각자를 이해할 수 있을 것이라 생각했기 때문에 "클린 코드" 책을 통한 스터디를 제안했다.

효과는?

사실 PR Template의 도입이나 스터디를 새로 한다는 것은 또 다른 업무 외적인 부담을 주는 것과 같았다.

게다가 이미 과부화된 상태에서 진행하기란 어려운 일이었다. 실제로 계획한 시점보다 1~2주 정도 지나서야 시작할 수 있었다.

 

결과적으로, PR Template의 도입과 스터디의 효과는 예상한 것보다 좋았다.

 

PR Template의 도입은 예상한 효과뿐만 아니라

실제 개발한 영역의 기능을 테스트한 캡처/영상 등을 올리면서 개발자 테스트를 꼼꼼히 진행하게 되어 버그 발생률이 전보다 줄어들었고,

명확히 작업한 부분에 관해 설명을 써야 하니 작업을 확실히 구분해서 작업하게 되는 효과도 있었다.

 

두 번째 스터디의 진행도 마찬가지로 예상했던 효과뿐만 아니라

코드 리뷰의 관점 중 스터디 이후에 클린 코드의 관점에서의 리뷰가 보이기 시작했다는 것이다.

이는 개발자들이 스스로 좋은 코드를 남기고 발전할 수 있는 계기가 만들어진 것이라 본다.

 

우리 팀은 아직 가야할 길이 많이 남았지만, 간단하게 코드 리뷰의 문제와 이를 개선시켰던 경험을 공유하며 글을 마칩니다.

소프트웨어 엔지니어들은 각자 하고 싶은 말이 있다.
그들의 말에 동의를 하든 안 하든 일단 들어라.
그들이 한 말을 정중하게 인정하고 자신의 생각을 건설적인 방식으로 전달하라.

사람은 가끔 화를 낸다. 이해심을 발휘하라. 본인도 화가 날 때가 있고, 그럴 때 동료가 이해해주기를 바라지 않는가?

맥스 카넷-알렉산더, ⌜심플 소프트웨어⌟, 이미령 옮김, 길벗, 2019