애자일 개발이란? - (3) 익스트림 프로그래밍과 리팩토링, TDD 등

 

애자일 개발이란? - (1) 기본 개념 정리

애자일 개발이란? - (2) 애자일 기법의 개념과 사용

애자일 개발이란? - (3) 익스트림 프로그래밍과 리팩토링, TDD 등

애자일 개발이란? - (4) 스크럼 스프린트 사이클

1. 익스트림 프로그래밍(XP)

익스트림 프로그래밍은 1990년대에 개발된 변화하는 소프트웨어 개발 문화를 다루는 가장 중요한 애자일 기법이다.

익스트림 프로그래밍(XP)은 정말 'extreme'하게 개발에 접근한다.

• 매일 새로운 버전을 만들어야 함
• 2주마다 증가분들이 고객에게 전달됨
• 모든 빌드가 테스트를 통과 헤야 허가됨 < 테스트의 중요성이 강조되는 방법론

2. XP release cycle

1. 유저가 원하는 것들 중에서 선택(Select user stories for this release)
2. 원하는 점을 분류(Break down stories to tasks)
3. 계획 세우기(Plan release)
4. 개발 및 통합(Develope/integrate/test software)
5. 소프트웨어 릴리스(Release software)
6. 시스템 평가 후 다시 1번으로 회귀(Evaluate system)

3. XP practices

원칙이나 실무	설명
점증적 계획	요구사항을 "스토리 카드"에 기록한다. 릴리스에 들어가는 스토리를 우선순위를 정한다. 개발자들은 스토리를 개발 작업들로 쪼갠다.
소규모 릴리스들	완전히 새로운 버전을 내놓는게 아닌 작은 단위로 조금씩 개발한다.
단순한 설계	-
테스트 우선 개발(TDD)	기능 자체를 구현하기 전에 새로운 기능에 대한 테스트를 작성하기 위해 자동화된 단위 테스트 프레임워크를 이용한다.
리팩토링	리팩토링은 기능을 바꾸는 작업이 아니다. 코드의 퀄리티를 높이는 작업이다. 개발자들은 개선 가능한 코드가 보이면 게속적으로 리팩토링해 단순하고 유지보수하기 쉬운 코드를 만든다.
페어 프로그래밍	2명씩 짝지어 개발하는 방법이다. 한 명이 개발하고 다른 한 명이 옆에서 개발하는 것을 본다.
공동 소유권	각자 개발하면 각자 책임이고, 개발한 사람외의 사람이 수정하기 어려운데, 그것의 정반대되는 개념이다.
지속적 통합	특정 작업에 대한 업무가 끝나자마자, 전체 시스템에 통합된다. 통합 후, 모든 유닛 테스트를 통과해야 한다.
유지할 수 있는 속도	많은 양의 초과 근무를 허용하지 않는다.
고객의 참여	고객은 개발팀의 구성원이며 구현팀에게 요구사항을 전달할 책임이 있다.

4. 효과적인 XP practices

XP를 완전히 그대로 따라 하기는 힘들고 적당히 adaptation을 거쳐서 사용한다. 그중 효과적인 핵심 XP practice에 대해 하나씩 알아보자.

• User stories for specification
• Refactoring
• Test-first development
• Pair programming

5. User stories for specification

• XP에서 고객은 XP팀의 일원이다. 그리고 요구사항과 결정들을 만드는데 책임이 있다.
• 유저들의 요구사항들은 유저 스토리나 요구사항에 의해 표현된다.
• 그것들은 카드에 적히고 개발팀이 그것들을 수행 가능한 task로 쪼갠다.
• 고객이 다음 릴리스를 생각해 우선순위를 정하고 스토리를 고른다

6. Refactoring

• 기존의 소프트웨어 공학의 지식은 변화를 생각해서 설계하는 것이었다. 그것이 장기적으로 이득이 될 것이라 생각했기 때문이다.
• 하지만 XP에서는 지금 당장 개발해야 하는데 뭔 미래에 바뀔지 안 바뀔지도 모르는 것까지 다 예측해서 미리 만들어야 하냐라고 생각한다. (물론 그렇다고 전부 무시하는 것은 아니다.)
• XP에서는 차라리 리팩터링을 통해 기존의 코드들을 향상하자 제안한다.
• 리팩터링은 코드가 수행하는 기능들은 그대로 두되, 코드 퀄리티를 높이는 작업을 의미한다.
• 개발자들은 개선 가능한 코드를 찾고 지금 당장 개선이 필요 없더라도 리팩터링을 통해 코드를 발전시킨다.
• 위와 같은 작업을 거치면 코드의 가독성이 개선되기 때문에 문서의 필요도를 낮춰준다.
• 코드들이 효율적으로 짜여 있어, 앞으로의 변화들도 쉬워진다.
• 하지만 구조적 리팩터링(root kernel refactoring)을 요구하는 큰 변화들이 생기면 훨씬 큰 비용적 손해를 볼 수 있다.

7. Test-first development(Test driven development, TDD)

테스트를 하는 것은 XP에서 중요하다. TDD에서는 과거에 추가한 부분과 새로 추가한 부분 모두를 테스트해서 문제가 없는지 확인한다. 이 방법을 통해 이전에 추가된 부분들이 계속해서 검증을 거칠 수 있다.

 

다음은 XP에서 수행하는 테스팅의 주요 특징들이다.

1. 테스트 우선 개발: 코드보다 테스트를 먼저 작성 > 개발자가 코드를 작성하면서 테스트를 실행할 수 있고, 개발과정에서 문제점을 찾을 수 있음
2. 시나리오를 통한 점증적 테스트 개발: 고객이야말로 어떤 테스트가 가장 필요한지 누구보다 잘 앎 > 고객의 참여와 관계됨
3. 고객의 참여 > 지켜지기 어렵지만 중요함
4. 테스트 자동화 프레임워크 사용: 테스트하려는 것과 독립적으로 작성돼야 함, 개발이 진행됨에 따라 소프트웨어가 커지고 그 소프트웨어의 부분 부분을 테스트할 수 있는 것이 만들어짐 > 어떤 부분을 고쳤는데 다른 부분에 영향을 줄 수 있음 > 테스트를 전부 돌리면 어디가 문제인지 알 수 있음

테스트 우선 개발의 문제점

• 개발자들은 테스트를 만드는 것보다 프로그램을 만드는 것을 좋아함
• 코드를 짜는 것보다 테스트를 만드는 것이 더 어려운 경우가 있음
• 완벽한 테스트를 만들 수는 없음

8. Pair programming

• 2명이 짝을 이뤄 프로그래밍을 함
• 한 명이 개발을 하고 다른 한 명은 개발하는 것을 지켜보며 피드백을 줌
• 개인만이 아닌 팀 전체가 코드를 이해할 수 있다.
• 페어 프로그래밍이 효율적이라는 증거가 있음에도 잘 받아들여지지 않고 있음

 

출처:https://hodev.tistory.com/