코드리뷰 적용 작은(?) 성공담
Agile팀에 서의 코드리뷰 - part I
Wojciech Seliga
Atlassian에서 우리는 "애자일" 개발에 대한 믿음을 가지고 있습니다. 가능한 우리는 애자일 스럽게 되려고 하며 확실히 그 장점을 보았습니다.
확실히 "더 애자일" 스러운 팀도 있고, 덜 애자일 스러운 팀도 있습니다.
거의 모든 팀이 서로 다른 애자일 방식을 적용하고 있습니다.
이러한 현상은 우리가 스스로 조직을 구성하고 아래로부터의 진화를 믿는 한은 전혀 문제가 없습니다.
그러나 우리는 애자일 철학에서 4가지 기본 원칙
Crucible
2년이 지난 지금, 코드리뷰는 우리 애자일 개발자들의 하루 일과로 완전히 녹아들었습니다.
어떤 직원은 매우 중독되었습니다. 왜 그런지 이야기해 보겠습니다.
저는 코드리뷰 자체의 명확한 장점인 코드품질의 향상에 대해서는 이야기 하지 않겠습니다. 대신에, 코드 품질은 좋은 부산물이 지, 우리팀의 코드리뷰 목적은 아니라고 이야기 하고 싶습니다.
코드리뷰는 애자일의 기본선언인 "프로세스와 도구를 통한 개인과 상호작용" 원칙을 적용하기 위한 하나의 방법입니다. 여기 코드리뷰가 어떻게 더 좋은 협업을 할 수 있도록 하는지에 대한 예가 있습니다.
새로운 팀 멤버
Atlassian은 지속적으로 성장
코드리뷰는 새로운 코드베이스(소스코드)에 더욱 빠르고 용이하게 접근할 수 있도록 도와줍니다.
그리고 팀과 회사의 기술적인 지식을 유지하도록 도움을 줍니다.
회사의 소스코드에 이미 익숙해진 사람들은 새로운 직원의 댓글에 대해 리뷰하고 (버그나 기능에 대한 코딩을 하는 것보다 제품에 대해 배우는 더 좋은 방법은 없습니다), 새 직원의 디자인 불일치에 대해 조언해 주고, 새 직원이 배우고 익혀야 할 도구나 컴포넌트에 대해 공유합니다.
거꾸로, 새 직원은 중요한 경험과 좋은 기술적 예, 유용한 라이브러리, 훌륭한 패턴, 기법등을 이전의 팀에서 가져와 소스코드를 개선시키는데 도움이 될만한 관점을 제공하기도 합니다.
간단히 말해, 코드리뷰는 양방향 대화인 것입니다. 작성자와 리뷰자가 모두 서로 통신하고 각자에게 배우는 것입니다.
코드리뷰는 중급의 개발자가 팀에 합류할 때 더욱 중요합니다.
고급 개발자는 스스로 코딩을 해야 하므로 중급 개발자를 도와줄 시간이 없습니다.
그렇지만, 중급 개발자의 소스코드를 가끔 리뷰하는 것은 그리 큰 일은 아닙니다.
결과는? 고급 개발자는 자신의 코드 개발에 하루의 대부분을 집중하고 중급 개발자가 변경한 소스코드를 리뷰하는데 하루에 10-15분씩 2,3번 정도 시간을 소비합니다.
중급 개발자는 이 피드백을 통해 도움을 받고, 고급 개발자는 중요한 코딩 시간을 빼앗길 필요가 없는 것입니다.
지리학 적 분산 (Geographical distribution)
Atlassian 회사는 3개의 나라에서 소프트웨어를 개발하며, 각각의 시간대는 10시간이 차이납니다.
동일한 코드베이스의 소스코드 작업을 하는 대부분의 팀들은 같은 지역에 있게 됩니다. (정말로 도움이 됩니다)
그렇지만, 때로는 이것이 실용적이거나 가능하지 않습니다. 그래서 결국 우리는 몇 개의 지리학적인 배포팀을 구성하였습니다. – 짝 프로그래밍과 매일 스탠드업과 같은 일부 애자일 실행방법에서는 큰 문제입니다.
코드리뷰가 지원되는 툴은 여기서 서로 다른 지역간의 지식흐름을 이용하고 활용하는데 좋은 해결책이 됩니다.
비동기적인 코드리뷰를 통해, 시간대의 차이는 단점이 아닌 장점이 될 수 있습니다. 때로는 오후 (그날의 작업에 대한 요약으로서) 에 리뷰를 작성하고 태평양 건너 있는 다른 직원에게 리뷰를 부탁한 후 집으로 갑니다.
다음날 아침 우리가 회사에 도착하면, 리뷰에 대한 피드백을 바로 확인할 수 있습니다: 우리가 잠자고 있을 때 동료직원이 리뷰를 해 준 것입니다.
매일 아침 첫번째 작업으로 이러한 피드백을 답변하고 확인된 문제를 수정한 후, 일상의 개발작업을 진행해 갑니다.
통합
코드베이스(소스코드 저장소)는 분리되어 있지 않습니다. 대부분의 Atlassian 제품은 서로 여러가지 방식으로 통합되어 있습니다.
예들 들면, 저는 미국에서 IDE Connectors
이 API는 지속적으로 개선되는데, 때로는 IDE Connector 팀의 요청에 의해 개선되기도 합니다.
서버 제품 팀은 주로 시드니에서 근무하고 그쪽은 저희 작업이 시작할 때 업무가 끝나는 상황입니다. (미국 캘리포니아와 호주 시드니의 시간차이로 인해)
코드리뷰는 IDE Connector 팀이 의존하는 remote API 관련해 피드백을 제공하는 주요 수단입니다.
Remote API에 관련된 변경사항이 발생 할 때마다, 저는 리뷰어 중 한 사람이 됩니다 – 그래서 서버측에서 상황이 어떻게 된 것인지 알 수 있고 API의 수정상황에 대해 건설적이니 비판을 하기도 하며, 변경사항이 진행되기 전에 최소한 제 팀이 연관된 것임을 확실히 알려주시고 합니다.
유사한 경우가 바로 일반적으로 작업하지 않는 제품에 대해 무엇인가를 프로그래밍 하는 경우가 발생했을 때 입니다. 우리는 이것을 "손님(게스트) 프로그래밍" 이라고 부릅니다 – 예를 들면, 오직 자신만의 개발환경에서만 발생하는 문제를 수정하거나 혹은 누락된 API를 추가하거나 누락된 플러그인 포인트를 추가하는 경우입니다.
코드리뷰는 양쪽을 자극하여 손님(게스트) 프로그래밍을 가능하게 합니다.
제품을 담당하는 팀은 외부사람이 자신들의 코드를 건드리는 것을 좋아하지 않고 손님 프로그래머는 다른 사람들이 나쁜 버그를 막기 위한 자신의 코드를 리뷰해 줄 것이기 때문에 용기를 가질 수 있습니다.
용기에 대해 이야기하면 – 우리 팀 중 일부는 실제로 코드리뷰가 없을 때 매우 걱정을 합니다.
유닛 테스트는 귀찮은 재반복(리그레션) 테스트 없이 코드를 개선하고 리펙토링 할 수 있는 용기를 가지도록하는 안전망을 구성해 줍니다.
유사하게, 코드리뷰는 또 다른 안전망이어서, 사람들에게 당신의 특이한 아이디어가 제품에 반영되기 전에 미리 다른 사람들에게 평가 받을 것이라는 느낌을 주게 하며, 당신의 훌륭한 디자인, 유틸리티, 기법이 다른 팀에 의해 다른 장소에서 재사용될 수 있도록 확산될 기회를 제공합니다. 이것이 진정한 팀워크입니다.
코드리뷰는 어렵고, 실제 적용 유지하는데 비용이 많이 들 수 있습니다.
그러나, 모든 팀과 모든 팀원이 짝 프로그래밍을 원하지는 않는 상황에서, 코드리뷰 미팅은 상당한 시간을 소비하게 합니다.
우리는 Crucible
다음 블로깅
그리고 세번째, 혹은 최종 블로그에서는 코드리뷰와 짝 프로그래밍을 비교해 보고, Atlassian에서 적용해 온 코드리뷰에 대해 몇 가지 규칙을 알려드리도록 하겠습니다.
(골드피처 주)
코드리뷰는 소프트웨어를 개발하는 회사에서는 이제 누구나 한번쯤 들어보았고 필요성에 대해서도 공감을 하는 내용입니다.
그러나 실제 업무에 적용하는 것은 말처럼 그리 간단하지 않은 것이 현실입니다.
우선 소스저장소를 운영하지 않는 회사는 소스저장소를 운영하면서 형상관리툴을 사용하는 것부터 익숙해 져야 하는데 이것도 아직 국내에서는 정착되지 않은 경우가 많습니다. 특히나 오래된 회사일수록 이러한 개발환경을 변경하는 것은 상당한 모험이니까요.
하지만, 언제까지 미룰 수는 없습니다. 코드리뷰가 모든 업무나 모든 사람에게 필요한 것이 아니라 하더라고 분명 효과를 얻을 수 있는 사람이나 부서가 있습니다.
또한 회사차원에서는 신입직원의 교육이나 소스코드에 대한 정보 축적 관점에서는 분명 투자대비 얻는 효과는 부서나 직원이 얻는 효과와는 비교도 되지 않는다고 할 수 있는 것입니다.
이제 직접 시도해 보시지 않으시겠습니다. Crucible
댓글