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