매끄러운 '코드 리뷰'를 돕는 10가지 방법
‘코드 리뷰’란 말 그대로 코드를 검토해주는 과정을 뜻한다. 보통 누군가가 작성한 소스코드에 예상치 못한 오류나 개선돼야 할 방향이 없는지 코드 작성에 참여하지 않는 개발자가 살펴봐준다.
하지만 코드 리뷰를 시작하는 것은 쉽지 않다. 과연 한국 사회에서 자신보다 직급이 높은 사람에게 무언가를 지적할 수 있을까? 경력이 많은 개발자가 지적한 내용에 신입 개발자가 반박할 수 있을까?
팀 페터슨 아틀라시안 개발자 프로바커터는 “몇 가지 원칙이 있고 문화가 형성되면 가능하다”라고 말했다.
코드 리뷰를 하다보면 같은 코드를 여러 사람이 함께 본다. 그래서 코드 리뷰로 왠지 할일이 늘어날 것 같고, 코드 작성에 들어갈 시간이 줄어들 것 같다. 이러한 과정이 혹시 제품 출시 시점을 늦추진 않을까. 팀 페터슨 개발자 프로바커터는 오히려 “코드 리뷰 때문에 배포 속도가 더 빨라진다”라며 “코드 리뷰를 통해 코드에 대한 자신감도 높아질 수 있다”라고 말했다. 특히 시간이 지날수록 배포 속도는 더욱 빨라질 수 있다고.
그리고 팀 페터슨 개발자 프로바커터는 코드 리뷰를 좀 더 효율적으로 적용할 수 있는 10가지 팁을 알려줬다. 여기서 말한 개념은 ‘깃’같은 버전 관리도구를 이용할 때 더욱 잘 활용할 수 있다.
리뷰를 하다가 갑자기 다른 버그가 보일 수 있고, 스타일이나 포맷을 고치고 싶은 마음이 들 수 있다. 일단 그것은 제쳐두고 원래 고치려고 했던 내용 하나만을 보고 리뷰하고 고치는 게 더 효율적이다.
3. 검토하는 사람은 리뷰항목대비 1.5~2.5배 정도로 두자.
버전 관리도구에 이제 막 수정된 2가지 코드 내용이 올라왔다고 치자. 검토자는 이를 살펴보고 최종 프로그램에 합칠지 승인한다. 이때 검토자는 3명(2×1.5=3) 혹은 5명(2×2.5=5)을 두는 게 바람직하다. 모든 검토자가 이상이 없는지 확인하는 건 아니다. 만약 검토자가 3명이라면, 3명 중 한 사람이 승인하면 수정된 코드가 실제 프로그램에 적용된다. 따라서 검토자 중 한 사람이 바쁘거나 휴가를 내도 수정된 코드는 금세 프로그램에 반영될 수 있다. 보통 아틀라시안 내부 팀에서는 2가지 이슈를 승인하기 위해서 3~5명 정도의 검토자를 할당하고 있다고 한다. 개발 속도를 더 빠르게 하기 위해서는 더 많은 검토자를 배정하고 있다.
‘깃 블레임‘이라는 깃 명령어를 활용하라. 이 명령어를 이용하면 각 코드마다 마지막으로 수정한 사람이 누구인지, 최종 커밋 시간은 언제였는지 확인할 수 있다. 팀 페터슨 개발자 프로바커터가 직접 만든 오픈소스 ‘깃 길트‘를 이용해도 된다. 깃 길트는 깃 블레임 내용을 요약하고 정리해주는 무료 커맨드라인 도구다.
코드 리뷰를 하다보면 의견 차이가 생길 수 있다. 당사자끼리 화를 내거나 온라인에 감정적인 논쟁이 길어질 때도 있다. 이런 논쟁이 발생했다면 바로 상사, 아키텍트, 다른 개발자들 등이 나서서 중재해야 한다. 특히 온라인에서 의견을 교환하는 것을 중단하고 당사자들끼리 얼굴을 맞대고 해결할 수 있도록 도와줘야 한다.
코드 리뷰 도구를 이용하다보면 리뷰해야 할 코드가 무엇인지 모아 볼 수 있다. 그런데 시간이 지나면서 해야 할 코드 리뷰가 산더미처럼 쌓일 때가 있다. 따라서 ‘특정 요일에는 코드 리뷰할 과제를 모두 해결하자’는 식의 규칙을 만들면 좋다. 예를 들어 ‘매주 화요일에는 코드리뷰함에 있는 항목들을 다 해결하자’라는 내부 팀 규칙을 만드는 것이다.
코드 리뷰 도구나 프로젝트 추적기에서는 코드 내부에 메모나 글을 적을 수 있다. 이러한 기능을 활용해 특정 전문가나 관련자에게 코드에 대한 질문을 작성해 코드 리뷰를 해보자.
개발자들은 소스코드를 작성하면서 “// TODO fix this later”같은 주석을 달곤한다. 나중에 다시 고치기 위해 일단 메모하는 것이다. 개발자는 가끔씩 이 주석을 잊고 수정을 안 한 채 코드를 제출하기도 한다. 만약 코드 검토자가 이러한 주석을 발견했다면 개발자에게 다시 알려주거나 구체적으로 이슈 주소를 만들어 주석에 추가하는게 좋다. 나중에 좀 더 쉽게 추적하기 위해서다.
코드검토자는 코드 내용을 잘 이해 못 할 수도 있다. 이럴 때 검토자는 코드를 작성한 사람에게 찾아가 코드에 대한 설명을 듣는다. 코드 검토자는 이 내용을 말로만 듣지 말고 코드에 기록하면 좋다. 특히 코드작성자에게 들을 내용을 주석 형태로 코드에 아예 삽입해 놓으면, 향후 유지보수를 하는 개발자에게 큰 도움이 된다. 코드를 작성한 사람이 이에 대한 설명을 스스로 코드 주석으로 적는 것도 좋다.
풀 리퀘스트(Pull Request)를 언제 적용할지 팀이 회의해서 규칙을 만들어놔야 한다.
자, 이제 10가지 방법을 사내에 '은근슬쩍' 공유하자. 그리고 거침없이 리뷰해보자. 드라마속 일터에서 늘 사랑이 넘치는 것처럼. 코드 리뷰하다 사랑이 샘솟는(?) 그날까지!
