코드 리뷰를 하다가 감정이 상하는 경우가 있다. 이상적인 세계에서는 없어야할 일이지만, 현실에선 생긴다. 이유는 사소하게 다양하다. 엔지니어들 중에는 소위 ‘말 이쁘게 하는법’을 잘 모르는 사람들도 있다. 프로그래밍 언어처럼 딱딱하게 말하는 유형이다. 당연히 듣는 사람에 대한 배려와 완충재가 불충분하기 때문에 경우에 따라서는 수신자는 너무 말이 ‘세다’고 느낀다. 이런경우 감정이 상하는 것으로 이어지기도 한다.
혹은 코드리뷰에서 너무 사소해 보이는 것을 지적하는 것도 그렇다. 코드에서 개선점은 객관적인 것들도 있지만 주관적인 것들도 많다. 예를들면, ‘본인 취향’의 코드스타일 같은 것. 변수명을 accumChrgAmount로 지을지 accumulatedChargeAmount로 지을지 같은게 해당하기도 한다. 이런 것들을 리뷰에서 지적하면 리뷰 받는 사람은 시어머니를 모시는 기분이 들어 기분이 불쾌할 수도 있다.
오늘은 내가 경험해본 코드리뷰를 위한 괜찮은 문화들을 두어 가지 소개해 보려고 한다.
가독성 리뷰는 팀 내 명확한 기준을 세우자
가독성을 위한 스타일가이드 제정
사실 이 정도는 거의 대부분의 기업이 하고 있을 것이라 생각한다. 따라서 간단하게만 적어본다.
팀별로 스타일 가이드를 세세하게 작성한다. 온보딩하는 팀원이 팀 내 컨벤션을 알기 쉽고, 코드리뷰시 명확한 기준이 생겨 오해와 충돌의 소지를 줄일 수 있다.
더불어 lint 등을 활용해 커밋/push시 스타일가이드가 적용되게 하거나 검증하도록 해서 코드리뷰 이전에 미리 스타일가이드가 적용되게 하면 더 좋다.
가독성 리뷰 제도
이는 직접 경험해 보지는 않았고, <구글 엔지니어는 이렇게 일한다>에 나오는 방식이다. 각 언어별로 가독성 리뷰어를 선정하는데, 그 언어에 정통하고 모범이 되는 코드 스타일을 가진 사람을 적절한 기준으로 선별한다고 한다.
새로 작성한 코드가 코드베이스에 머지되기 위해서는 각 언어별로 가독성 리뷰어에게 반드시 코드 리뷰를 받아야 한다.
구글 내에서도 이 가독성 리뷰 제도에 대해 반발이 있었지만, 저자에 따르면 정성/정량적인 평가 결과 가독성 리뷰 제도가 단점보다는 장점이 많은 것으로 판명되었다고 한다.
대략 이런식으로 접근할 수 있을 것 같다.
- 사내 주요 언어, 기술스택에 대해 가독성 리뷰어 선정
- 각 팀에서 자체적인 리뷰 진행
- 머지 전 가독성 리뷰어의 approve 받기
- 코드베이스에 기능 머지
아직 경험해보지 않은 것인데, 소수의 사람들이 코드 스타일이나 가독성에 대한 규정을 전담해 리뷰하게 함으로써, 사내에 일관된 코드 스타일이나 퀄리티를 유지하는 데 도움이 될 것 같다고 생각한다.
단, 단점으로는 가독성 리뷰어들의 업무가 가중될 수 있고 이것이 전반적인 사내 개발 퍼포먼스에 병목으로 작용할 수도 있을 것 같다.
리뷰에 우선순위를 매기자
이 방법은 이전에 근무했던 회사에서 경험한 것인데, 생각보다 효과적이었다.
목표는 “사소한 차이에서 뉘앙스가 달라지면 의도가 왜곡되는 언어적인 요소를 명확한 수치로 전달하는 것”이다.
대략 이런식이다
p1: 반드시 고쳐주세요
p2: 고치면 좋을 것 같은데 리뷰에서 더 논의해봐도 좋을 것 같습니다
p3: 고치면 좋을 것 같은데 고치지 않는다고 해도 괜찮습니다.
p4: 가벼운 제안이런식으로 각 팀마다 p(priority의 약자)와 번호를 활용해 규칙을 정한다.
p1, p2가 무엇을 의미하는지, 총 몇개의 우선순위 단계를 둘지 등을 정하고 공유하면 된다.
실제 리뷰는 이런식으로 하게 된다.
p1;
for문 안에서 await을 사용하고 있는데 이 경우에 동기적으로 실행되게 됩니다.
async/await을 non-blocking으로 적절히 사용하기 위해
Promise.all 등을 사용해 처리하는 것이 나을 것 같습니다.이렇게 작성하는 코멘트의 최 상단에 p{n}을 붙이는 것이다.
예를 들어,
for문 보다 reduce를 사용하는 것이 낫습니다.이런 리뷰가 달렸다고 해보자.
이건 권유일까? 아니면 무조건 바꾸라는 의미일까?
만약 본인이 생각하기에 for문이 낫다고 생각한다면, 어떻게 코멘트를 달아야할까?
상대방이 이 리뷰를 달면서 리뷰가 얼마나 중요하게 반영되어야 하는지를 명확하게 드러내지 않고 있기 때문에, 리뷰받는 사람은 많은 고민을 하게 된다.
또, 위 문장은 단정적으로 얘기하고 있는데, 생각보다 많은 개발자들이 말재주가 부족해 저런식으로 소통하기도 한다.
알다시피 저런 단정적인 문장은 ‘그럼 내가 지금 잘못된 코드를 짰다는 건가?’라고 받아들일 수 있어 분란을 일으킬 수도 있다.
이것을 우선순위를 함께 지정한다면,
p4;
for문 보다 reduce를 사용하는 것이 낫습니다.예를 들어 이렇게 바뀌었다고 하자. 그럼, ‘아, 중요도가 낮으니 제안이구나’ 이렇게 보다 명확히 이해하게 되므로, 제안이었는데 상대방은 강압으로 받아들이는 사례를 방지할 수 있다.
요약해보자면, 이 방식의 장점은 다음과 같다.
- 코멘트에 명확하게 리뷰어가 생각하는 중요도가 표시됨에 따라, 리뷰어가 중요하지 않게 생각하는 리뷰는 서로 힘빼며 싸우지 않게 된다.
- 리뷰를 다는 사람이 생각하는 중요성의 정도가 명확히 전달되기 때문에, 가벼운 리뷰인데 딱딱한 말투로 인해 상대방이 기분 상할 일을 방지할 수 있다.
- 일정이 빡빡하면 중요도 높은 리뷰만 우선 반영할 수도 있다. 예를 들어 p3 이하의 리뷰에는 “이 부분은 일정이 촉박하여 이후 리팩토링 과정에서 반영하겠습니다~”를 코멘트로 달아 양해를 구할 수 있게 되는 것이다.
결론적으로 이전 회사에서 코드 리뷰 과정에서 언쟁으로 이어진 사례가 여러 차례 있었는데, 이 제도를 도입한 후 그 빈도가 줄어드는 것을 경험했다.
마치며
세상이 완벽하게 논리적이고 이성적이라면, 프로그래머가 인공지능이라면 리뷰를 하며 얼굴을 붉힐 일도 없을 것이다.
하지만 현실은 다르다. 리뷰를 받다 보면 지적을 받는 느낌이 들어서 리뷰 받기를 꺼려하는 경우도 많고, 리뷰 과정에서 의견 충돌이 감정의 충돌로 이어지는 경우도 종종 목격된다.
어떤 제도도 사실 이런 감정적 충돌을 미연에 방지할 수는 없다.
하지만, 회사는 시스템으로 돌아가는 게 베스트이므로, 최대한 시스템적으로 이런 오해의 소지를 줄이고, 효율성을 높일 방법을 강구하는 게 맞다고 생각한다.
아직 여러 회사를 경험해보지 못해서 다양한 방법을 알지는 못하지만, 내가 아는 선에서 간단히 정리해 보았다.
좋은 리뷰 문화가 많이 공유되고, 각 회사들의 노하우가 많이 전파되면 좋을 것 같다.