'코드 리뷰의 정수'라는 글을 읽었다.

https://bharatmane.medium.com/the-art-of-code-review-b37ca8fa7ba6

The Art of Code Review

 

위 글을 보고 남기는 후기 같은 글이다.

 

코드리뷰를 간과하는 사람이 많다. 예를 들어서 코드를 보지도 않고 LGTM 를 한다든가...

 

하지만 수많은 연구결과가 말하듯이 코드리뷰는 제품의 퀄리티를 보장하는 최고의 방법이다. 뿐만 아니라 두 사람이 서로 코드리뷰를 열심히 했다면 그 중 한 사람이 퇴사를 하거나, 몸이 아픈 등 다양한 이유로 일을 더 이상 할 수 없을 때 다른 한 사람이 그 일을 수월하게 맡아서 할 수 있다. 단순히 코드를 읽고 "잘 읽었습니다 ^^" 를 남발하는 게 아니라 서로의 기술적 컨센서스를 맞출 수 있는 기회다. 그렇기 때문에 이를 소중한 기회로 생각하는 문화가 팀 내에 깔려있어야 한다. 이게 첫 번째 단계다.

 

모든 구성원이 코드 리뷰에 적극적이라고 하더라도 많은 난관이 남아있다. 예를 들어서, 우리는 코드에 대해 리뷰하지만, 그 코드는 사람이 쓴 것이기 때문에 작성자가 어떤 의도로 해당 코드를 썻는지 파악하기 힘들 때가 많다. 이를 피하기 위해서 코드리뷰에 어떻게 접근할 지를 항상 마음에 새기고 있어야 한다.

 

첫째, 중요한 일을 해준 것에 대해 감사를 표현하기.

내가 접한 수많은 개발자는 자기 효용감이 중요한 사람들이었다. 한 일에 대한 따뜻한 칭찬과 감사는 분위기를 한층 좋게 만들 수 있다.

비판을 할지라도 말의 시작은 부드럽고 따뜻하다면, 상대방이 비판을 더 잘 수용할 수 있다. 

😻 Yay! You used the new feature
💚 Thanks for adding test coverage!
🏆 omg finally someone refactored this code
💯 The strategy pattern fits perfectly here

저자는 위와 같은 예시를 든다. 이모지를 적극 활용하면 좋을 것 같다.

 

둘째 코드의 사이즈는 중요하다.

코드 라인이 200~400 줄이면 평균적으로 60~90분의 리뷰 시간이 필요하다. 신기한 건 코드 라인이 이것보다 많아지면 코드 리뷰에 30분이 채 안걸린다는 점이다. 우리의 인지용량은 한계가 있고, 그 용량을 벗어나면 쉽게 피로해진다. 피로하면 코드리뷰고 뭐고 LGTM 을 쓰고싶어진다. 당연히 결점을 찾는 능력도 저하된다. 되도록이면 2~3개 파일의 400줄 미만의 코드로 코드리뷰를 신청하자!

 

셋째 헌신이 필요하다.

코드의 성공을 팀의 목표로 삼아야 한다. "누가 이런 코드를 쓴거야?" "대체 누가 이걸 Approve 한거야?" 와 같이 책임 소재를 묻는 마인드에서 벗어나야한다. 그리고 팀 전체가 코드리뷰에 진심이어야한다. 코드 리뷰는, Request 가 올라온 후 두 시간 이내에 이루어져야 가장 효율적이다. Commit it!!

 

넷째 툴을 잘 활용하자.

이건 아마 많은 팀이 지키고 있는 룰일 것 같다. Sonarlint 나 SonarQube 를 활용해서 최대한 잔실수를 막을 수 있다.  표면적인 지침은 도구 사용에 대한 얘기지만, 중요한 건 다른 사람에게 리뷰를 요청하기전에 코드 작성자도 다른 사람의 시간을 아껴주는 마음가짐을 갖추어야 한다는 측면인 것 같다. 본인이 할 수 있는 것을 다 한 다음에 리뷰를 요청하는 게 팀원으로서의 매너라는 생각이 든다.

 

다섯째. 테스트 케이스는 필수다.

리뷰를 할 때 테스트 케이스도 당연히 같이 리뷰해야한다. 제일 좋은 건 단순한 Unit Test 를 넘어서서 Mutation Test 도 하면 좋다.

 

여섯째, 항상 겸손하고, 함께 만들어 나간다는 마음가짐이 필요하다.

코드리뷰를 할 때 작성자를 지적하는 게 아니라, 친근한 톤으로 코드 작성자가 다른 관점에서 생각하도록 한다 라는 측면으로 접근해야한다.

이럴 때 유용한 건 "너"를 "우리"로 바꿔는 것이다. 

 

"너 혹시 이렇게 생각해보지 않을래?" 가 아니라 "우리 이렇게도 한번 생각해볼까요?" 라는 식이다.

Not good
❌ "you forgot a variable here" 

Good
✅ "We are missing a variable here"
✅ "There is a variable missing here: [code block]"

그리고 예시를 제공해주면 더 좋다.

"이 부분은 더 다듬을 수 있을 것 같아요." 보다는 "이 부분은 Strategy 패턴을 활용하면 더 추상화시킬 수 있지않을까요?" 라고 말할 수 있다. 

 

일곱째, 코드 리뷰 과정에서 배워나간다.

코드 리뷰는 지식이 전파되는 굉장히 유용한 창구다. 우리는 코드 리뷰 속에서 좋은 관점을 배울 수 있다.

 

 

주제는 코드리뷰였지만 모든 커뮤니케이션에 부합한다고 생각한다.

"상대방을 배려하면서 말하고, 더 나은 대안이 있다면 그것도 함께 전하기."

 

이것을 잘 지킬 수 있다면 코드 리뷰 속에서 팀워크도 더 좋아질 수 있다고 생각한다.