애자일 팀은 팀 전반에 걸친 기술 집합을 통해 스스로 조직화합니다. 이는 부분적으로 코드 검토를 통해 이루어집니다. 코드 검토는 개발자가 코드 베이스를 알아보는 데 뿐만 아니라, 기술 집합을 성장시켜 주는 새로운 기술과 기법을 배우는 데도 도움이 됩니다.
그렇다면 코드 검토란 정확히 무엇입니까?
개발자가 이슈에 대한 작업을 마치면 다른 개발자가 코드를 살펴보고 다음과 같은 질문을 생각해 봅니다.
- 코드에 명백한 논리 오류가 있습니까?
- 요구 사항을 봤을 때, 모든 사례가 완전히 구현되었습니까?
- 자동화된 새 테스트가 새 코드에 사용하기에 충분합니까? 코드의 변경 사항이 고려되도록 기존의 자동화된 테스트를 다시 작성해야 합니까?
- 새 코드가 기존의 스타일 가이드라인을 준수합니까?
코드 검토는 팀의 기존 프로세스와 통합되어야 합니다. 예를 들어, 팀에서 작업 브랜치 워크플로를 사용하는 경우 모든 코드가 작성되고 자동화된 테스트가 실행 및 통과된 후에 코드 검토를 시작하되, 코드가 업스트림으로 병합되기 전에 수행하세요. 그러면 코드 검토자는 컴퓨터가 놓친 것을 확인하는 데 시간을 보내도록 하고, 잘못된 코딩 결정으로 인해 개발의 메인 라인의 효율을 떨어뜨리는 상황을 방지할 수 있습니다.
애자일 팀에게 어떤 이점을 제공합니까?
개발 방법론에 관계없이, 모든 팀은 코드 검토의 이점을 얻을 수 있습니다. 하지만 애자일 팀의 경우 업무가 팀 전체에 분산되어 있기 때문에 엄청난 이점을 실현할 수 있습니다. 코드 베이스의 특정 부분을 오직 한 팀원만 아는 경우는 없습니다. 간단히 말해, 코드 검토는 코드 베이스와 팀 전체에서 지식을 공유하도록 지원합니다.
코드 검토는 지식을 공유합니다
모든 애자일 팀의 중심에는 유연성, 즉 모든 팀원이 백로그에서 작업을 가져다가 실행을 시작할 수 있는 능력이 있습니다. 결과적으로, "주요 경로"에 해당하는 팀원이 없으므로 팀은 새로운 작업에 더 효과적으로 협력할 수 있습니다. 풀스택 엔지니어는 서버 측 작업뿐만 아니라 프런트엔드 작업도 처리할 수 있습니다.
코드 검토를 통해 더 나은 추정치를 얻게 됩니다
추정에 대한 섹션을 기억하십니까? 추정은 팀 단위의 활동이며, 제품 지식이 팀 전체에 분산되어 있으므로 팀은 더 효과적으로 추정하게 됩니다. 기존 코드에 새로운 기능이 추가되면 원래 개발자는 좋은 피드백과 추정치를 제공할 수 있습니다. 또한 모든 코드 검토자는 코드 베이스에서 해당 영역의 복잡성, 알려진 이슈 및 우려 사항에 노출됩니다. 그런 다음 코드 검토자는 코드 베이스에서 해당 부분을 작성한 원래 개발자에 대한 지식을 공유합니다. 이 관행은 정보 기반의 여러 입력을 만들어내며, 최종 추정치에 사용되는 경우 항상 그 추정치를 더 강력하고 신뢰할 수 있게 만들어 줍니다.
코드 검토를 통해 휴가를 갈 수 있습니다
코드에 대한 유일한 연락 담당자가 되고 싶어 하는 팀원은 없습니다. 마찬가지로, 자신이 작성하지 않은 중요한 코드를 다루고 싶어하는 팀원도 없습니다. 특히 프로덕션 비상 상황에서는 더욱 그렇습니다. 코드 검토는 팀 전체에서 지식을 공유하므로 어떤 팀원이든 직접 고삐를 잡고 선박을 계속 조종할 수 있습니다. (Atlassian에서는 여러 은유적인 표현을 함께 사용하기 좋아합니다!) 하지만 중요한 점은, 주요 경로에 해당하는 한 명의 개발자란 없기 때문에 팀원들이 필요에 따라 휴가를 갈 수 있다는 의미이기도 합니다. 버전 제어 시스템에 얽매여 휴가를 떠나지 못하고 있다면, 코드 검토는 자유를 찾아주는 훌륭한 방법입니다. 내게 필요했던 휴가를 갈 자유, 또는 제품의 다른 부분에 시간을 쏟을 자유를 누리게 됩니다.
코드 검토는 신입 엔지니어에게 멘토링을 제공합니다
애자일의 특별한 점은 신규 팀원이 합류하면 많은 경험을 보유한 엔지니어가 새 팀원을 멘토링한다는 것입니다. 또한 코드 검토는 코드 베이스에 대한 대화를 지원합니다. 팀에서는 코드 검토 중에 코드 내에 숨겨진 지식이 드러나는 경우가 많습니다. 새로운 시각을 가진 새 팀원은 코드 베이스에서 새로운 관점이 필요한, 시간이 많이 걸리는 비효율적인 영역을 발견합니다. 따라서 코드 검토는 기존 지식으로 새로운 인사이트를 강화하는 데에도 도움이 됩니다.
코드 검토는 선임 팀원이 후임 팀원의 코드를 검토하는 경우만 있는 것이 아닙니다. 코드 검토는 팀 전체에서 모든 방향으로 이루어져야 합니다. 지식에는 경계가 없습니다! 코드 검토는 신입 엔지니어에게 분명 도움이 될 수 있지만, 단지 멘토링 활동으로만 사용해서는 안 됩니다.
하지만 코드 검토에는 시간이 걸립니다!
물론 시간이 걸릴 것입니다. 하지만 시간이 낭비되는 것이 아니라, 아주 유용하게 사용됩니다.
이를 위해 최적화하는 3가지 방법은 다음과 같습니다.
작업량 나누기
Atlassian의 많은 팀은 코드를 코드 베이스에 체크인하기 전에 두 차례의 검토를 필요로 합니다. 오버헤드가 높아 보일 수 있지만 사실 그렇지 않습니다. 코드 작성자가 검토자를 선택할 때는 팀 전체에서 엔지니어 두 명 아무나 입력을 제공할 수 있습니다. 이렇게 하면 프로세스가 분산되어 병목 현상이 발생하지 않으며 팀 전반에서 코드 검토가 원활하게 이루어집니다.
병합 전 검토
업스트림을 병합하기 전에 코드 검토를 요구하면 모든 코드를 검토할 수 있습니다. 즉, 오전 2시에 의심스러운 아키텍처 결정이 내려지거나 인턴이 팩토리 패턴을 부적절하게 사용한 경우, 이러한 문제는 애플리케이션에 지속적인(그리고 후회스러운) 영향을 미칠 기회를 갖기 전에 발견됩니다.
동료 집단으로부터 받는 압력을 이용
팀원이 코드를 검토할 것이라는 사실을 아는 개발자는 모든 테스트가 통과하고 코드가 최대한 잘 설계되어 검토가 순조롭게 진행되도록 더 많은 노력을 기울입니다. 이러한 점을 인식함으로써 코딩 프로세스가 더 원활해지고 결과적으로 더 빨라지기도 합니다.
개발 주기 초기에 피드백이 필요한 경우 코드 검토를 할 때까지 가만히 기다리지 마세요. 초기 피드백은 코드를 개선해주는 경우가 많으므로, 주저하지 말고 다른 팀원의 도움을 받으세요. 그러면 작업이 개선될 뿐만 아니라 팀원도 더 나은 코드 검토자가 될 수 있습니다. 이 선순환은 계속됩니다...!
