'잘 하시는 분이니까 잘 짜셨겠지'
'뭔소린지 모르겠는건 내가 부족해서겠지'
'뭔가 깊은 뜻이 있겠지'
'내가 도메인 지식이 부족해서 그렇겠지'
혹시 이렇게 생각하고 approve를 누르는 적 없나요?
PR 저자가 기다리고 계실테니 빨리빨리 넘기는게 낫다고 생각하기도 했고, 정말로 위와 같은 생각을 하기도 하죠.
코드리뷰는 경력이 많은 분이 경력이 낮은 개발자에게 코드에 대한 리뷰를 해주는거라고 알고 계신 분들도 있어요.
OKKY에서 진행된 '한번 듣고 평생 써먹는 코드 리뷰 노하우' 세미나를 유튜브로 보고 내용을 정리해보려고 합니다.
왜 코드리뷰를 해야 하나?
SW의 진정한 비용은 유지보수에서 나옵니다. 전체의 80% 이상이라고 해요.
한번 작성한 코드는 10번 이상 읽게 됩니다. 작성보다 이해하는 데에 10배의 노력이 소요되는 셈이죠.
따라서 90% 이상의 시간을 어떤 코드를 '이해'하는데 사용합니다.
멀리 봤을 때 더 비용을 적게 들게 하는 방법이 무엇일까요?
코드리뷰의 목적
코드리뷰의 주목적은 품질 문제 검수입니다. 버그나 장애를 미리 캐치하는 거죠.
그리고 더 나은 코드 품질을 위해서입니다.
지금 시간을 더 써서 코드리뷰를 하고 품질을 올리면 그 시간을 프로젝트가 진행됨에 따라 조금씩 보상받습니다. 다만 느낄 수 없을뿐...
학습 및 지식 전달의 목적도 있는데요, 대개의 경우 리뷰어들도 리뷰 과정에서 지식을 얻게 된다고 해요.
상포 책임감이 증대되기도 합니다. 저희 회사의 경우 프론트엔드 개발자분들이 각자 다른 프로젝트에 소속되어 다른 일을 하고 있는데요. 서로 코드리뷰를 해주면 자연스럽게 내 동료가 무슨 일을 하고 있는지 알게 됩니다. 반대로 누군가 제 코드리뷰를 해주면 내가 하고 있는 일에 관심을 가져주고 있는 느낌을 받죠.
다른 블로그에서 보고 인상깊었던 문구입니다.
짤 같은걸 써서 즐거운 분위기로 만들라는게 특히 마음에 들었습니다. :)
효율적인 PR 방법
지루한 작업은 컴퓨터로 처리합니다. Formatting Tool로 공백, 들여쓰기 오류 등을 미리 해결하고 PR을 올리도록 합니다.
팀내에서 스타일 가이드를 정해서 스타일 논쟁을 미리 해소합니다.
PR을 올릴 때 주석을 달아서 코드를 더 이해하기 쉽게 합니다.
더 많은 사람들이 코드리뷰에 참여하게 해서 버그를 더 잘 찾아낼 수 있게 합니다.
의미있는 커밋으로 분리하고, 커밋 메시지를 의미있게 쓰도록 합니다.
본인이 작성한 코드라도 2주후에 보면 남이 짠 코드처럼 보인답니다. 설령 혼자 개발하는 프로젝트더라도, 커밋로그와 PR을 잘 작성하는 습관을 들이도록 합니다.
저자는 PR 작성시 잘한 것, 아쉬운 것, 눈여겨 볼 것에 대해 기술합니다.
다이어그램을 그려도 좋고, 링크를 걸어도 좋습니다. Gif 캡쳐 프로그램을 사용하는 것도 좋은 방법입니다.
리뷰어가 집중해서 봐줬으면 하는 부분에 미리 코멘트를 남겨두어도 좋습니다.
가장 중요한 것은, 저자가 고생해서 리뷰어들의 시간을 아껴줘야 한다는 것입니다.
리뷰는 즉시 시작하도록 합니다. 모든 팀원들이 하루에 두번 작은양의 PR을 리뷰할 수 있고 최대 4시간 안에 리뷰가 완료되도록 합니다.
코드리뷰의 근본적인 문제는 사람들이 리뷰할 시간이 없다고 느낀다는 것입니다. 이런 경우는 리뷰를 하는 것의 문제라기보다는 조직적인 문제입니다. '개인 기여'로만 평가를 받고 있다면, 팀을 돕기 위해 수행하는 모든 일은 시간 낭비처럼 보일 수 있습니다. 하지만 코드리뷰를 하는 이유에 대해서 위에서 설명하였듯이, 코드리뷰는 팀의 생산성을 높이는 방법입니다.
고수준(크리티컬한 버그 등)으로 리뷰를 시작하고, 저수준(변수명 변경, 주석을 명확하게 하는 것 등) 이슈를 처리하도록 하게 합니다.
예제 코드 제공에 관대해져야 합니다. 이는 저자를 기분 좋게 하기 위한 방법 중 하나입니다. 다만, 너무 긴 예제는 관대한 것이 아니라 억압적으로 보일 수 있습니다.
리뷰의 범위 또한 존중되어야 합니다. PR 근처의 코드를 보고 저자에게 수정을 요청하면 안됩니다. PR에 포함되지 않은 라인은 리뷰 범위가 아닙니다. 다만 예외로 PR이 둘러싼 코드에 영향을 미칠 때는 언급해도 됩니다.
Nit 등의 태그를 활용해서 저자가 무시할 수 있도록 합니다.
한 두 등급만 코드 레벨을 올리는 것을 목표로 합니다. 예를 들어, D 등급의 PR을 받으면 저자가 C나 B등급을 받도록 도와주는 것입니다. A+ 등급을 목표로 하지 않도록 합니다.
건설적인 피드백을 합시다. 동료들 간의 코드리뷰를 비판이 아닌 학습의 과정으로 인지할 수 있어야 합니다.
대부분의 리뷰어들은 잘못된 부분에만 집중하는데요. 좋은 변경이 있다면
"오, 이런 API가 있나요. 정말 유용해요"
"정말 좋은 해결책이네요. 생각도 못했네요."
"함수를 분리한 것은 좋은 생각이에요. 훨씬 단순해졌어요."
이런 코멘트를 남겨보는 것은 어떨까요?
피드백은 명령이 아니라 요청으로 표현하세요.
"~ 하는 것을 제안합니다."
"~ 하는게 어떨까요?"
의견이 아니라 원칙에 기반하여 피드백하세요.
저자에게 의견을 줄 때는 "제안하는 변경"과 "변경의 이유"를 모두 설명해야 합니다.
객관적으로 설명할 수 있도록 합시다.
결정은 저자가
"완벽한 설계"가 아니라 "당신이 할 수 있는 최고의 설계"를 추구합시다.
코드리뷰의 목적은 비난이 아니라 배움입니다.
리뷰를 한다고 100% 버그를 사전에 잡을 수는 없습니다.
참고
OKKY 한번 듣고 평생 써먹는 코드 리뷰 노하우 강의
[OKKY 1월 세미나] 한번 듣고 평생 써먹는 코드 리뷰 노하우 후기
코드 리뷰 잘 하는 법(Jr ver.)
