Korea [국가변경]

홈

제품

서비스 & 솔루션

고객지원 & 다운로드

회원 서비스

한국 developerWorks > 자바 >

Extreme Programming : "XP distilled", Part 2 (한글)

프로그래머 관행

문서 옵션

JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.

제안 및 의견

피드백

난이도 : 초급

Roy W. Miller, 소프트웨어 개발자, RoleModel Software, Inc

2002 년 9 월 01 일
2003 년 7 월 24 일 수정

한 명의 프로그래머가 XP 팀의 일원이 된다는 것의 의미와 6 가지의 프로그래머 관행들이 이 그림에 어떻게 부합되는지를 설명한다. 19 개의 XP 관행들이 모두 중요하지만 프로그래머 관행은 소프트웨어를 만드는 팀에게는 절대적이다.

프로그래머 관행: 시스템 만들기

XP 프로그래머 관행은 팀이 원하는 시스템을 만들 때 프로그래머가 해야 할 일이 무엇인지를 설명한다. 물론 XP는 코드를 작성하는 것 이상이다. 하지만 코드 없는 전체 행동은 시간 낭비일 뿐이다.

테스트 우선 개발

프로그래머가 코드를 변경할 때 마다 그들이 변경한 것이 무언가를 향상시키는 것인지 아니면 어떤 것을 깨트리는 행위인지를 알 필요가 있다. 더 중요한 것은 작업이 수행되는 데 쓰이는 최소한의 코드를 만드는데 필요한 가르침은 유지되어야 한다. 이것이 바로 테스트 우선 개발의 모든 것이다.

XP에는 두 종류의 테스팅이 있다. 단위 테스팅(unit testing)과 인수 테스팅(acceptance testing)이 그것이다. 이들은 전형적인 명칭이지만 나는 별로 좋아하지 않는다. 알아들을 수 없는 말 같다. 나는 Ron Jeffries의 "What is Extreme Programming?" (참고자료)에서 제안한 명칭인 커스터머 테스트(customer test)와 프로그래머 테스트(programmer test)라는 용어를 더 선호한다.

6 가지 프로그래머 관행

테스트 우선 개발
페어 프로그래밍
리팩토링
집합적 소유권 (Collective ownership)
지속적 통합
YAGNI

프로그래머는 코드를 작성할 때 프로그래머 테스트를 작성한다. 고객(Customer)은 이야기를 정의한 후에 커스터머 테스트를 작성한다. 프로그래머 테스트는 개발자들에게 시스템이 어는 시점에서 작동할 것인지를 명령한다. 커스트머 테스트의 경우 사용자들이 이 시스템에게 무엇을 바라는지를 팀에게 알려준다. 여기서는 프로그래머 테스트에 대해 이야기 할 것이다.

팀이 자바 같은 객체 지향 언어를 사용한다고 가정하고 개발자들은 깨질 수 있는 모든 가능한 메소드를 위한 프로그래머 테스트를 작성한다. 물론 그 메소드용 코드를 작성하기 전이다. 그런 다음 테스트가 통과될 수 있도록 코드를 작성한다. 가끔씩 사람들은 이것을 이상하게 여기지만 테스트를 먼저 작성하는 것은 다음과 같은 이점이 있다:

가장 완벽한 테스트 세트; 코드에 대한 자신감을 증대시킨다.
작동할 수 있는 가장 간단한 코드; 이는 나중에 리팩토링하기 쉽다.
코드의 의도를 명백히 볼 수 있다; 후에 이해하기 쉽고 리팩토링도 쉬워진다.

개발자들은 모든 프로그래머 테스트가 통과되기 전까지는 소스 코드 리파지토리의 코드를 검사할 수 없다. 프로그래머 테스트는 개발자들에게 그들이 만든 코드가 작동하고 있다는 확신을 심어준다. 이것은 다른 개발자들에게 넘어가 원래 개발자의 의도를 이해할 수 있도록 돕는다. 프로그래머 테스트는 코드 리팩토링도 돕는다. 테스트가 실패하면 개발자들에게 즉시 알려진다. 프로그래머 테스트는 자동화되어야 하며 통과나 실패 결과를 명확히 주어야한다. xUnit 프레임웍(참고자료)은 이러한 일을 잘 수행하며 따라서 대부분의 XP 팀은 이를 사용하고 있다.

"XP distilled revisited" 시리즈
Part 1: "XP의 진실 " (한글) (2002년 8월)

Part 3: "고객과 관리 습관" (2002년 10월)

프로그래머로서 프로그래머 테스트를 거친 코딩과 그렇지 않은 코딩 사이의 차이를 보고 놀랄 때가 종종 있다. 코드를 작성할 때 지극히 적은 단계를 거친다는 것을 깨닫는다. 사실 그 적은 단계동안 디버깅을 많이 할 필요도 없다. 문제가 있는 소스는 명확하기 때문이다.

페어 프로그래밍

XP에서 쌍을 이룬 개발자들이 모든 제품 코드를 작성한다. 대부분의 개발자들은 다른 사람들과 합심하여 코드를 작성한 경험이 전혀 없고 처음에는 낯설다. 페어 프로그래밍은 두 명의 개발자들이 하나의 컴퓨터를 공유하는 것을 의미한다. 한 명은 코드에 주도권을 갖고("driver") 다른 한명은 그가 길을 찾을 수 있도록 돕는다. ("navigator" 또는 "partner"). driver가 혼란스러워하거나 navigator가 좋은 생각을 갖고 있다면 현재의 driver는 제어권을 포기하고 navigator가 잠시동안 그 역할을 맡는다. 각자는 역할을 수시로 바꿔야한다. 이러한 역할에 익숙해지면 역할 변동은 보다 자유롭게 일어난다.

이러한 접근방식이 비효율적으로 비춰질 수도 있다. 이럴 때면 나는 Martin Fowler의 대답을 떠올린다. "페어 프로그래밍이 생산성을 떨어트린다라고 사람들이 말할 때 저는 대답합니다. 프로그래밍의 대부분이 타이핑에 소모된다면 그 말은 사실이라고." 시실 페어 프로그래밍은 더 만은 혜택을 준다:

모든 디자인 결정에 적어도 두 개의 두뇌가 투입된다.
적어도 두 명이 시스템의 모든 부분에 익숙하다.
두 명 모두 테스트나 다른 태스크를 게을리할 경우가 거의 없다.
쌍을 바꾸면 팀간 지식이 확산된다.
코드는 적어도 한 사람에 의해 언제나 리뷰된다.

코드 리뷰는 코드 품질을 증대시킨다는 경험적 연구결과가 있지만 나는 이런 것이 싫다. 또한 정확하게 이를 수행하는 것이 매우 어렵다는 것도 확신한다. 그리고 페어 프로그래밍 만큼 효과적이지도 않다.

The Costs and Benefits of Pair Programming (참고자료) 에서는 쌍을 이루어서 하는 프로그래밍이 프로그래밍 보다 더 효율적임을 나타내고 있다.

리스크의 경우 프로젝트가 실패한 원인에 대해 잠시 생각해보자. 큰 이유 중 하나는 한 명의 영웅에 지나치게 의존하는데 있다. 만일 당신의 프로젝트의 영웅께서 순간적 사고로 숨진다면 프로젝트는 어떻게 될 것인가? 쌍을 이루는 것의 본질은 지식을 곳곳에 퍼트리는 것이다. 또한 자주 변화해야 한다. 지나치게 굳어져있으면 멈춰버린다.

페어 프로그래밍에 대해 여러가지 장점을 얘기했음에도 불구하고 대부분의 개발자들은 이러한 생각을 싫어한다. 이는 자부심의 문제이다. 대부분의 개발자들은 영웅이 되기 원한다.

다른 사람들을 사랑할 때 그들의 장점이 보이며 그들의 성장을 도울 수 있다. 오래 참고, 친절하며 시기하지 않고 관대하며 겸손하고 무례히 행치 않아야 한다. 이러한 친밀한 상호 관계는 대부분의 사람들이 흥미있어하는 것이 아니며 개발자들은 사람이다. (따라서.. ) 이것은 급진적 생각이고 모든 사람들에게 적용될 수는 없다. 하지만 이를 실천했을때 그 보상 역시 크다.

리팩토링

리팩토링은 기능을 변경하지 않고 코드를 향상시킬 수 있는 기술이다. XP 팀은 무자비하게 리팩토링을 한다. 개발자들이 리팩토링 할 수 있는 두 번의 핵심 기회가 존재한다. 기능 구현의 전과 후 이다. 개발자들은 기존 코드를 변경하는 것이 새로운 기능을 더 쉽게 구현할 수 있도록 돕는지의 여부를 결정해야 한다. 예를 들어 추상화의 기회를 보게된다면 구체적 구현에서 중복 코드를 제거하기 위해 리팩토링을 한다. 여기서 중요한 것은 새로운 코드를 디자인하고 작성하거나 기존 코드를 리팩토링 해야한다는 것이다. 그 두 작업을 한번에 시도하지 말라.

XP는 작동 가능한 가장 간단한 코드를 작성하는 것에 중점을 두고 언제나 배울 것을 강요하고 있다. 리팩토링은 배운 것과 코드를 결합할 수 있도록 한다. 이로서 코드는 깨끗하게 유지된다. 오랫동안 생존할 수 있으며 문제는 적어진다.

리팩토링의 요지는 기존 코드의 디자인을 향상시키는 것이다. 팀은 프로그래머 테스트 슈트와 커스터머 테스트 슈트를 자동화 해야한다. 전자는 언제나 통과해야 하며 후자는 고객이 요구하는 수준까지 통과하면 된다. 테스트를 실행하라. 코드를 리팩토링하라. 프로그래머 테스트가 잘못되었는가? 문제를 해결하라. 고객의 요구가 있는가? 문제를 해결하라. 테스트 없이 코드를 변경하는 것은 억측 게임과도 같다.

집합적 소유권 (Collective ownership)

팀의 누구라도 코드를 개선하기 위해 변경할 권한을 가져야 한다. 누구나 모든 코드를 소유한다는 것은 다시말하면 책임도 져야한다는 것을 의미한다.

누구나 코드를 소유한다는 것이 어떤 누구도 코드를 소유하지 않는 것과 같은 것은 아니다. 아무도 코드를 소유하지 않으면 원하는 어디엔가 코드를 유출시키고 어떤 책임도 지지 않는다. XP는 "당신이 망쳤으면, 당신이 픽스하라."고 요구한다.

지속적 통합

새로운 변화를 매번 시스템에 통합시키고 전체를 자동으로 재구현하라. 모든 테스트가 실행될 때까지 변화를 누설하지 말라. 테스트가 실패하면 두 개의 선택이 있다. 고치고 통합하는 것과 통합하지 않는 것. 고칠 수 없는 실패한 테스트는 통합해서는 안된다.

지속적 통합이라고 해서 수시로 통합하는 것을 의미하는 것은 아니다. 더 빨리 자주 통합하라는 의미이다. 매일은 부족하다. 많은 사람들이 이 말을 듣고 경악하겠지만 테스트가 이러한 공포를 날려보낼 것이다.

YAGNI("You aren't going to need it"; 더 이상 이것이 필요하지 않을 것이다)

"XP distilled" 칼럼에서 Chris Collins와 나는 "XP의 반대자들이 프로세스가 디자인을 무시한다고 주장하고 있다는 것을 밝힌 바 있다.

반대 의사가 시사하는 바는 사람들은 이러한 신생의 디자인에 편안함을 느끼지 않는다는 것이다. 방향을 설정하고 이정표를 마련한 다음 여행을 시작하는 것이다. 이러한 접근 방식을 싫어하는 사람들은 이러한 방식이 다듬어 지지 않은 방식이라고 간주한다. 실제로 이는 현실적인 접근 방식인데 말이다.

전형적인 방식은 수평의 정적 그림을 가져다가 그곳에 도달 할 완벽한 지도를 그리려는 것과 같다. 요구사항이 항상 같다면 이것은 좋은 접근 방식이다. 실제로는 대부분의 개발자들은 전에 한번도 풀지 못한 문제를 경험하게 되고 전에 한번도 시도하지 못한 솔루션을 구현하고 있다. 오늘날 대부분의 시스템은 끊임 없이 변화하는 시장에서 경쟁 할 용도로 디자인되고 있다.

이와 같이 요구 사항이 매 시간 변하는 상황에서 요구 사항이 일정하리라는 보장이 없다. 큰, 업프론트 디자인이 부적절하다. 최선의 방법은 일반적인 방향을 설정한 다음 작게 만들고 수시로 조정하는 것이다. XP는 모든 과정에서 단순함을 요구한다. 필요할 때 마다 방향을 바꿀 수 있도록 하기 위해서이다.

Kent Beck에 따르면 작동이 가능한 가장 간단한 디자인은 다음과 같은 것이다:

모든 테스트를 실행한다.
중복 코드를 포함하지 않는다.
모든 코드에 대한 프로그래머의 의도를 명확히 언급한다.
최소한의 클래스와 메소드를 포함한다.

단순한 디자인을 요구한다고 해서 모든 디자인이 작거나 간단해야 하는 것을 의미하는 것은 아니다. 가능한 단순한 상태를 유지해서 작동하게 하는 것이다. 사용하지도 않는 과잉의 기능을 추가하지 말라. 우리는 그와 같은 것을 YAGNI라고 부른다. 이는 '더 이상 이것이 필요하지 않을 것이다'라는 의미이다. 다시 말해서 필요할 것 같은 것을 설계하지 말라는 의미이다. 다음 통합 때 이를 깨닫게 될 것이다. 대신 테스트를 작성하고 테스트가 통과 할 수 있는 코드를 만드는 것이다.

참고자료