2018.08.27

더 나은 코드 리뷰를 위한 7단계

Rob Whitcomb | InfoWorld
코드 리뷰는 더 나은 소프트웨어는 물론, 더 나은 개발자, 더 나은 팀을 만든다. 올바른 코드 리뷰를 위한 7단계 팁을 소개한다.

소프트웨어 개발처럼 세세한 곳까지 주의를 기울여야 하는 분야에서는 피어 리뷰(Peer Review), 즉 동료의 검토가 필수적이다. 사소한 실수가 프로젝트 전체를 망치는 심각한 오류를 유발할 수 있기 때문에 또 한 쌍의 눈, 또는 여러 쌍의 눈이 있다면, 모든 것이 최상이 되도록 확실히 하는 데 도움이 된다. 물론 자동화된 테스트를 수행해 코드를 검사할 수도 있지만, 사람만큼 좋은 방법은 없다.



코드 리뷰는 개발 프로세스의 속도를 확실히 높인다는 것이 입증된 상태이다. 하지만 코드를 리뷰하는 사람의 책임은 무엇인가? 코드 리뷰를 할 때, 건설적인 피드백을 보장하는 방법이 있는가? 프로젝트를 촉진하고 개선하는 피드백을 어떻게 요청하는가? 견실한 코드 리뷰를 수행하기 위한 팁 몇 가지를 소개한다.

1. 목표 설정. 코드 리뷰는 오류나 버그를 찾는 것 이상의 작업이다. 새로운 기능을 추가하는 것이나 그 기능을 구현하는 방법을 생각할 수도 있다. 코드가 조직에서 정한 특정 방식의 기준을 만족하도록 만들고자 할 수도 있다. 목표가 무엇이든, 프로세스의 아주 초기 단계에서 이를 명확히 하는 것이 중요하다. 그리고 팀 내의 모두가 그 목표를 이해하고 같은 방향으로 일을 해야 한다. 만약 팀원 각각이 서로 다른 목표나 관점을 가지고 있으면, 의견 일치를 이루기도 어렵고 프로세스를 진척시키기도 어렵다.

2. 첫 단계. 요청을 받은 후 가능한 한 빨리 첫 단계를 진행하도록 하자. 아직은 상세하게 살펴볼 필요는 없다. 그저 즉석에서 개요를 훑어보고 팀원들에게 첫인상이나 생각을 적도록 한다.

3. 티켓 시스템 사용. 소프트웨어 개발 플랫폼 대부분은 코드의 서로 다른 측면에 대해 언급이나 논의를 촉진한다. 코드에 대한 모든 제안된 변경사항은 새로운 티켓이다. 팀원 누구라도 변경할 필요가 있는 사항을 발견하자마자 티켓을 발행한다. 티켓은 변경사항이 무엇인지, 어디로 가야 하는지, 왜 필요한지 설명해야 한다. 그러면 다른 팀원이 티켓을 검토해 자신의 의견을 추가한다. 이 시스템은 모든 제안된 변경 사항을 추적하는 데 도움이 될 뿐만 아니라 논의를 코드 전반의 개선과 정제로 이끈다.

4. 테스트 실행. 코드의 한줄 한줄을 살펴보며 사소한 오류를 발견하고자 할 수도 있다. 하지만 문제되는 코드 조각을 실행해 어떻게 동작하는지 보는 것이 더 쉬울 때가 많다. 그렇게 하는 과정에서 애플리케이션에 미치는 영향의 맥락에서 버그를 찾는 것이 더 쉬워진다. 또한 어떤 기능이 빠졌고 어떻게 개선할 수 있는지에 대한 인사이트를 얻을 수 있다.

5. 제안된 변경사항 테스트. 코드를 테스트 환경에 넣고 제안된 변경사항을 적용하면 어떻게 기능하는지 살펴본다. 변경사항이 제대로 동작하는가? 소프트웨어가 더 나아지는가 아니면 변경사항이 더 많은 문제를 유발하는가? 이런 변경사항이 프로젝트의 전체 예산에 도움이 되는가? 테스트를 기반으로 티켓을 더 발행해 논의한다.

6. 심층 검토 단계. 이제 코드 한줄 한줄을 촘촘한 빗으로 걸러내 버그나 스타일 문제, 잘못 들어간 종속 문제 등을 찾아낼 시간이다. 어떤 사람은 이 작업을 제안된 변경사항을 테스트하기 전에 하기를 좋아한다. 이들은 끝까지 기다린 다음에 모든 변경사항을 한 번에 테스트한다. 하지만 첫 단계에서의 변경사항을 테스트하는 것은 두번째 단계에 유익한 정보를 제공한다. 게다가 진행하면서 테스트하는 것이 끝에 가서 한번에 테스트하는 것보다 시간과 돈을 절약한다.

7. 평가 제출. 코딩 오류나 입력 오류 같은 사소한 변경사항은 지속으로 수정할 수 있다. 하지만 큰 변경사항은 반드시 코드 작성자와 먼저 논의해야 한다. 자신에게 물어보기 바란다. 과연 자신이 제안한 변경사항이 정말로 문제인지, 아니면 다른 식으로도 할 수 있는 것인지? 왜냐하면 결국은 작성자의 코드이지 검토자의 코드가 아니다. 일반 코드에 대한 평가를 제출하고 나면, 작성자와 이야기해 왜 그런 식으로 처리했는지 알아내야 한다. 그런 다음에 자신의 접근 방법을 이야기해주고 생각을 듣는다. 각자의 관점에서 대상을 바라볼 수 있고, 그런 인사이트를 사용해 코드를 최상의 상태로 만들 수 있을 것이다.

코드 리뷰는 프로그래밍의 가장 중요한 측면 중 하나이다. 문제를 더 빨리 더 효율적으로 해결할 수 있도록 해준다. 그리고 궁극적으로는 더 높은 품질의 코드와 소프트웨어 제품을 만들 수 있다.

*Rob Whitcomb은 소프트웨어 개발 및 컨설팅 서비스 전문업체인 서지(Surge)의 수석 소프트웨어 엔지니어이다.
editor@itworld.co.kr


2018.08.27

더 나은 코드 리뷰를 위한 7단계

Rob Whitcomb | InfoWorld
코드 리뷰는 더 나은 소프트웨어는 물론, 더 나은 개발자, 더 나은 팀을 만든다. 올바른 코드 리뷰를 위한 7단계 팁을 소개한다.

소프트웨어 개발처럼 세세한 곳까지 주의를 기울여야 하는 분야에서는 피어 리뷰(Peer Review), 즉 동료의 검토가 필수적이다. 사소한 실수가 프로젝트 전체를 망치는 심각한 오류를 유발할 수 있기 때문에 또 한 쌍의 눈, 또는 여러 쌍의 눈이 있다면, 모든 것이 최상이 되도록 확실히 하는 데 도움이 된다. 물론 자동화된 테스트를 수행해 코드를 검사할 수도 있지만, 사람만큼 좋은 방법은 없다.



코드 리뷰는 개발 프로세스의 속도를 확실히 높인다는 것이 입증된 상태이다. 하지만 코드를 리뷰하는 사람의 책임은 무엇인가? 코드 리뷰를 할 때, 건설적인 피드백을 보장하는 방법이 있는가? 프로젝트를 촉진하고 개선하는 피드백을 어떻게 요청하는가? 견실한 코드 리뷰를 수행하기 위한 팁 몇 가지를 소개한다.

1. 목표 설정. 코드 리뷰는 오류나 버그를 찾는 것 이상의 작업이다. 새로운 기능을 추가하는 것이나 그 기능을 구현하는 방법을 생각할 수도 있다. 코드가 조직에서 정한 특정 방식의 기준을 만족하도록 만들고자 할 수도 있다. 목표가 무엇이든, 프로세스의 아주 초기 단계에서 이를 명확히 하는 것이 중요하다. 그리고 팀 내의 모두가 그 목표를 이해하고 같은 방향으로 일을 해야 한다. 만약 팀원 각각이 서로 다른 목표나 관점을 가지고 있으면, 의견 일치를 이루기도 어렵고 프로세스를 진척시키기도 어렵다.

2. 첫 단계. 요청을 받은 후 가능한 한 빨리 첫 단계를 진행하도록 하자. 아직은 상세하게 살펴볼 필요는 없다. 그저 즉석에서 개요를 훑어보고 팀원들에게 첫인상이나 생각을 적도록 한다.

3. 티켓 시스템 사용. 소프트웨어 개발 플랫폼 대부분은 코드의 서로 다른 측면에 대해 언급이나 논의를 촉진한다. 코드에 대한 모든 제안된 변경사항은 새로운 티켓이다. 팀원 누구라도 변경할 필요가 있는 사항을 발견하자마자 티켓을 발행한다. 티켓은 변경사항이 무엇인지, 어디로 가야 하는지, 왜 필요한지 설명해야 한다. 그러면 다른 팀원이 티켓을 검토해 자신의 의견을 추가한다. 이 시스템은 모든 제안된 변경 사항을 추적하는 데 도움이 될 뿐만 아니라 논의를 코드 전반의 개선과 정제로 이끈다.

4. 테스트 실행. 코드의 한줄 한줄을 살펴보며 사소한 오류를 발견하고자 할 수도 있다. 하지만 문제되는 코드 조각을 실행해 어떻게 동작하는지 보는 것이 더 쉬울 때가 많다. 그렇게 하는 과정에서 애플리케이션에 미치는 영향의 맥락에서 버그를 찾는 것이 더 쉬워진다. 또한 어떤 기능이 빠졌고 어떻게 개선할 수 있는지에 대한 인사이트를 얻을 수 있다.

5. 제안된 변경사항 테스트. 코드를 테스트 환경에 넣고 제안된 변경사항을 적용하면 어떻게 기능하는지 살펴본다. 변경사항이 제대로 동작하는가? 소프트웨어가 더 나아지는가 아니면 변경사항이 더 많은 문제를 유발하는가? 이런 변경사항이 프로젝트의 전체 예산에 도움이 되는가? 테스트를 기반으로 티켓을 더 발행해 논의한다.

6. 심층 검토 단계. 이제 코드 한줄 한줄을 촘촘한 빗으로 걸러내 버그나 스타일 문제, 잘못 들어간 종속 문제 등을 찾아낼 시간이다. 어떤 사람은 이 작업을 제안된 변경사항을 테스트하기 전에 하기를 좋아한다. 이들은 끝까지 기다린 다음에 모든 변경사항을 한 번에 테스트한다. 하지만 첫 단계에서의 변경사항을 테스트하는 것은 두번째 단계에 유익한 정보를 제공한다. 게다가 진행하면서 테스트하는 것이 끝에 가서 한번에 테스트하는 것보다 시간과 돈을 절약한다.

7. 평가 제출. 코딩 오류나 입력 오류 같은 사소한 변경사항은 지속으로 수정할 수 있다. 하지만 큰 변경사항은 반드시 코드 작성자와 먼저 논의해야 한다. 자신에게 물어보기 바란다. 과연 자신이 제안한 변경사항이 정말로 문제인지, 아니면 다른 식으로도 할 수 있는 것인지? 왜냐하면 결국은 작성자의 코드이지 검토자의 코드가 아니다. 일반 코드에 대한 평가를 제출하고 나면, 작성자와 이야기해 왜 그런 식으로 처리했는지 알아내야 한다. 그런 다음에 자신의 접근 방법을 이야기해주고 생각을 듣는다. 각자의 관점에서 대상을 바라볼 수 있고, 그런 인사이트를 사용해 코드를 최상의 상태로 만들 수 있을 것이다.

코드 리뷰는 프로그래밍의 가장 중요한 측면 중 하나이다. 문제를 더 빨리 더 효율적으로 해결할 수 있도록 해준다. 그리고 궁극적으로는 더 높은 품질의 코드와 소프트웨어 제품을 만들 수 있다.

*Rob Whitcomb은 소프트웨어 개발 및 컨설팅 서비스 전문업체인 서지(Surge)의 수석 소프트웨어 엔지니어이다.
editor@itworld.co.kr


X