클린 소프트웨어 - 익스트림 프로그래밍 소개

익스트림 프로그래밍 소개

익스트림 프로그래밍 실천방법

Extreme Programming. XP는 애자일 방법 중에서도 가장 유명하며, 단순하면서도 서로 의존적인 실천방법의 집합으로 구성되어 있다. 이는 부분보다는 전체를 구성하기 위해 함께 작동한다.

고객 팀 구성원

고객에게 있어 최선의 상황은 개발자와 같은 공간에서 일하는 것이다. 고객은 개발자와 가까운 거리에서 일해야 한다.

실제 고객을 대신할 수 있고 그럴 의지가 있는 사람과 함께 일하는 것이 좋다.

사용자 스토리

요구사항의 구체적 세부 내용은 변화하기 쉬우므로, 세부 사항을 기록하기보다는 몇 개의 단어를 기록하여 그 대화 내용을 기억한다.

사용자 스토리란 현재 진행 중인 요구사항에 관한 대화의 연상 기호다. 고객이 우선순위와 추정 비용에 근거하여 요구사항의 구현 일정을 수립하게 해주는 계획 툴이다.

짧은 반복

XP 프로젝트는 개발 중인 소프트웨어를 2주마다 공개한다. 각 반복 끝마다 이해당사자의 피드백을 받기 위해 시스템을 시연한다.

반복 계획

반복은 보통 2주 단위로 진행된다. 이는 최종 제품에 반영될 수도 있으며, 반영되지 않을 수도 있다.

반복 계획은 개발자가 세운 예산에 따라 고객이 선택한 사용자 스토리의 집합이다.

개발자는 이전 반복에 미루어 각 반복의 예산을 세운다.

일단 반복이 시작되면, 고객은 그 반복 동안에는 스토리의 정의나 우선순위를 바꾸지 않는 것에 동의해야 한다. 그러면 개발자는 반복 내에서 스토리를 자유롭게 태스크에 나누어 넣고 기술적, 업무적으로 가장 합리적인 순서로 태스크를 수행해 나갈 것이다.

릴리즈 계획

릴리즈는 보통 3개월 단위로 진행된다. 최종 제품에 포함되는 메이저 공개를 의미한다.

개발자는 이전 릴리즈에 미루어 각 릴리즈의 예산을 세운다.

릴리즈는 절대적인 것이 아니며, 고객은 요구 내용을 언제든 변경할 수 있다. 스토리를 취소할 수도, 새로운 스토리를 작성할 수도, 스토리의 우선순위를 변경할 수도 있다.

인수 테스트

사용자 스토리의 세부 사항은 고객이 명시한 인수 테스트의 형태로 기록된다. 이는 시스템이 고객이 명시한 대로 동작하는지 여부를 검증한다.

시스템이 일단 인수 테스트를 통과하면, 통과한 테스트의 본문에 추가되고 다시 실패하는 것이 허용되지 않는다. 인수 테스트 본문의 증가는 하루에도 몇 번씩 계속된다. 인수 테스트가 실패하면 그 빌드는 실패를 선언한다.

따라서 요구사항이 제대로 구현되기만 하면 제대로 동작한다.

짝 프로그래밍

모든 운영 코드는 같은 워크스테이션으로 일하는 개발자 짝들에 의해 구성된다.

각 짝의 한 멤버는 키보드를 잡고 코드를 입력하며, 다른 한 멤버는 입력되는 코드를 보면서 에러와 개선점을 찾는다. 이렇게 짝은 서로 긴밀하게 상호작용하고 작업에 몰입하여 소프트웨어를 작성한다.

짝의 역할은 자주 바뀔 수 있다. 결과물은 두 멤버가 함께 설계하고 만들어낸 것이 된다.

짝은 적어도 하루에 한 번 바뀌어서 모든 개발자가 매일 서로 다른 두 짝으로서 일할 수 있게 해야 한다. 이 과정에서 해당 반복 과정에서 진행되는 모든 작업을 경험할 수 있게 되며, 팀 내부에서 지식이 더 빨리 확산될 수 있다.

한 연구에 의하면, 짝 프로그래밍은 효율성을 떨어뜨리는 대신 오히려 결함 발생률을 줄여준다고 한다.

테스트 주도 개발

모든 운영 코드는 실패하는 단위 테스트를 통과하기 위해 작성된다.

먼저 프로그램에 테스트하는 기능이 구현되어 있지 않으므로 당연히 실패하는 단위 테스트 프로그램을 작성한다. 그런 다음 그 테스트를 통과하는 코드를 작성한다.

테스트 케이스를 작성하는 시간과 코드를 작성하는 시간 사이의 간격은 매우 짧다. 테스트 케이스를 작성하는 시간이 약간 앞서는 정도이다.

테스트 케이스의 완성된 본문은 코드와 함께 발전한다. 테스트는 개발자가 프로그램이 잘 동작하는지 점검할 수 있게 해주며, 코드에 변경이 일어난 경우 문제가 있는지 확인해 준다. 그러므로 리팩토링을 굉장히 용이하게 만든다.

테스트하기 위해 테스트 가능한 코드를 작성할 수 있어야 하며, 이를 위해 코드를 모듈별로 분리하여 각각 독립적으로 테스트될 수 있게 해야 한다는 필요성이 강조되고 있다. 이러한 코드는 상호 간섭이 아주 적으며, 객체 지향 설계 원칙이 이러한 비간섭화를 구현하는 데 큰 역할을 한다.

공동 소유권

개발자는 하나의 개별적인 모듈이나 기술에 대해 개인적으로 책임을 지지 않는다. 모든 팀원이 모든 부분 작업에 참여할 수 있다. 아무도 어떠한 모듈이나 기술에 대해 다른 사람보다 더한 권한을 갖지 않는다.

이는 전문성을 부정한다는 의미가 아니다. 팀원이 또 다른 분야에 대해 전문성을 키우고 싶다면 그 작업에 참가하여 해당 분야를 가르쳐줄 전문가와 함께 일할 수 있게 되어, 전문 분야의 일에만 묶여 있지 않을 수 있다.

지속적인 통합

개발자는 자신의 코드를 푸시하고 하루에 몇 번씩 그것을 통합한다. 개발자들은 아무 때나 어떠한 모듈이라도 내려받을 수 있다. 개발자가 모듈을 수정한 후 그것을 다리 푸시하려면, 먼저 그 모듈을 푸시한 다른 사람이 수정한 부분과 병합할 준비가 되어 있어야 한다.

이러한 과정이 길어지는 것을 피하기 위해 팀원은 모듈을 매우 빈번하게 푸시한다.

짝은 한두 시간 동안 테스트 케이스 및 운영 코드를 작성하는 것에 매달리고, 테스트가 작동하는지 확인한 후 새로운 코드를 이미 존재하는 기반 코드에 통합한다. 통합되면 새로운 시스템을 빌드하고 모든 테스트를 실행한다. 이전에 동작한 부분이 망가졌다면 그 부분을 다시 수정한다. 모든 테스트를 통과하면 체크인을 마친다.

XP 팀은 하루에도 여러 번 처음부터 끝까지 전체 시스템을 빌드한다. 시스템의 최종 결과가 웹 사이트라면 대개 테스트 서버에 그 웹 사이트를 설치한다.

지속 가능한 속도

꾸준히, 적당한 속도로 작업을 진행해야 한다.

XP 팀은 초과 근무를 하지 않으며, 릴리즈를 일 주일 앞둔 시기는 예외다.

열린 작업 공간

팀은 열린 공간에서 함께 일하며, 대화하는 낮은 웅성거림으로 가득 차 있다. 각 짝은 서로의 목소리가 잘 들리는 거리에 있으며, 각 팀원은 누군가에게 문제가 발생했을 때 그것을 들을 수 있다.

이러한 환경이 생산성을 더욱 향상시켜 준다는 연구 결과가 있다.

계획 세우기 게임

업무와 개발의 책임 분리.

고객은 기능 요소가 얼마나 중요한지를 결정하고, 개발자는 그 기능 요소를 구현하는 데 얼마나 많은 비용이 들 것일지를 결정한다.

이러한 과정을 통해 고객은 개발자가 얼마나 빨리 진행할 수 있는지에 대한 감을 잡게 될 것이고, 이를 기반으로 프로젝트의 소요 기간과 비용을 정할 수 있게 될 것이다.

단순한 설계

가능한 한 단순하고 표현적으로 설계한다. 현재 반복에서 작업하기로 계획했던 스토리에만 초점을 맞추어 작업한다.

다음 반복으로 넘어갈 때 시스템의 설계를 마이그레이션하여 시스템이 현재 구현하고 있는 스토리에 가장 적합한 설계가 되도록 한다.

이는 XP 팀이 기반구조를 이용해 시작하지 않을 것임을 의미한다. 그들은 가능한 한 가장 단순한 방식으로 동작할 수 있도록 구현할 것이다.

어떻게든 동작하는 가장 단순한 것을 생각하기

현재 스토리를 구현하는 가장 간단한 방법을 사용하며, 실제로 구현할 수 있을 정도로 최대한 단순한 솔루션을 선택한다.

필요하지 않을 것이라는 가정에서 시작하기

언젠가 기반구조가 필요해질 것이다. 하지만 이러한 것이 필요하지 않을 것이라는 가정 하에서 프로젝트를 시작한다.

팀은 현재 상황에서 기반구조를 추가하는 것이 추가하지 않고 기다리는 것보다 비용 면에서 효과적이라는 확실한 증거가 있을 때 기반구조를 추가한다.

코드를 중복하여 사용하지 않기

코드 중복은 허용되지 않는다. 코드 중복이 발견될 때마다 이를 제거한다.

함수나 부모 클래스를 만들어 제거할 수 있다.

둘 이상의 알고리즘이 비슷하나 미묘한 부분에서 다른 경우가 있는 경우, 함수로 바꾸거나 템플릿 메소드 패턴을 사용할 수 있다.

중복의 원인이 무엇이든간에 일단 발견되면 그대로 두지 않는다.

중복성을 제거하는 최선의 방법은 추상화다. 결과적으로 결합도가 낮아진다.

리팩토링

코드가 추가됨에 따라 코드는 부패된다. 점검하지 않은 채로 내버려두면 이는 엉키고 유지보수할 수 없는 더러운 코드가 되어버리고 만다.

이러한 퇴화는 잦은 리팩토링을 통해 반전된다.

리팩토링은 행위에 영향을 주지 않고 시스템의 구조를 개선하는 일련의 작은 변화를 만드는 방식이다. 이들이 함께 모여 결합되면 시스템의 설계와 아키텍처에 있어 중요한 변환이 된다.

리팩토링 후 단위 테스트를 수행하여 아무 문제도 없음을 확인해야 한다. 각 변환 끝에 테스트를 실시하면서 다음 변환을 계속 수행한다.

리팩토링은 30분 혹은 1시간마다 수행된다. 다시 말해서 매번 수행될 수 있어야 한다. 이를 통해 가능한 한 깔끔하고 단순하며 의미 있는 코드를 유지할 수 있다.

메타포

전체 시스템을 하나로 묶는 큰 그림. 개별적인 모듈의 위치와 형태를 명백하게 만드는 시스템의 비전이다.

모듈의 형태가 메타포와 일치하지 않는다면 그 모듈이 잘못되었음을 알 수 있다.

1초에 60개의 글자를 화면에 텍스트로 전송하는 시스템 : 쓰레기(글자)를 운반하는 덤프트럭(전송 시스템)

위처럼 시스템을 현실 세계의 어떠한 현상으로 비유할 수 있다.

결론

XP는 애자일 개발 프로세스를 구성하는 단순하고 구체적인 방식의 집합이다.