익스트림 프로그래밍(XP, eXtreme Programming)이란?
익스트림 프로그래밍(XP, eXtreme Programming) 란 소프트웨어 개발 방법론 중 하나로,
기존의 개발 방법론들이 가지고 있던 일부 한계를 극복하고 빠른 속도로 변화에 대응하기 위해 만들어졌습니다.
켄트 백 등이 제안한 소프트웨어 개발 방법으로,
비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법입니다.
XP는 애자일(Agile) 개발 프로세스의 한 가지로 분류되는 개발 프로세스입니다.
그렇기에 특히 작은 규모의 개발 팀에서 유연하고 빠르게 소프트웨어를 개발하고 유지보수하는 데 중점을 두고 있습니다.
익스트림 프로그래밍(XP, eXtreme Programming)의 특징
XP의 특징은 다음과 같습니다.
| 특징 | 설명 |
| 짧은 개발 주기 | 작고 반복적인 개발 주기를 강조하여 빠른 소프트웨어 개발을 가능하게 합니다. |
| 테스트 주도 개발 (Test-Driven Development, TDD) |
테스트 케이스를 먼저 작성하고, 그에 맞춰 코드를 작성하는 방식으로 소프트웨어 품질을 향상시킵니다. |
| 연중 개발 | 개발자들이 지속적으로 코드 작성과 통합을 수행하여 더 자주 배포하고 변화에 대응합니다. |
| 고객 참여 | 고객과의 지속적이고 적극적인 소통을 통해 요구 사항 변경에 빠르게 대응하고 고객 만족도를 높입니다. |
| 간단한 설계 | 단순하면서도 효율적인 설계를 강조하여 유지보수성을 향상시킵니다. |
오늘날 소프트웨어 개발에서 XP가 대두된 이유는 복잡한 소프트웨어 개발 과정을 더 유연하게 만들기 위함에서 출발하였습니다.
기존에 제시된 소프트웨어 개발 방법론들은 큰 프로젝트에서의 복잡성에 대응하기 어렵다는 한계가 존재했습니다.
따라서, 처음 설계를 잘하지 못하면 추가적으로 소프트웨어를 수정하고 보완하는 것이 무척 까다로웠고,
이러한 특징은 요구 사항 변경에 유연하게 대처하지 못한다는 '단점'이 되었습니다.
XP, 애자일 방법론과 함께 비교 설명 되는 개발 프로세스로는 폭포수(Waterfall) 모델 방식이 있는데,
이에 대한 자세한 설명은 아래의 링크를 참조하시면 좋을 것 같습니다.
https://ko.wikipedia.org/wiki/%ED%8F%AD%ED%8F%AC%EC%88%98_%EB%AA%A8%EB%8D%B8
폭포수 모델 - 위키백과, 우리 모두의 백과사전
위키백과, 우리 모두의 백과사전. 폭포수 모델(waterfall model)은 순차적인 소프트웨어 개발 프로세스(소프트웨어를 만들기 위한 프로세스)로, 개발의 흐름이 마치 폭포수처럼 지속적으로 아래로
ko.wikipedia.org
XP는 기존의 소프트웨어 개발 방법이 대응하기 어려웠던 '빠르게 변화하는 환경'에 집중하였습니다.
이러한 환경에 개발자가 보다 쉽게 적응하고 효율적으로 소프트웨어를 개발할 수 있도록 방향성을 제시해주었고,
전 세계의 많은 개발자로부터 인기를 얻게 되었습니다.
XP(eXtreame Programming)의 5가지 가치
| 가치 | 설명 |
| 용기 (Courage) |
- 용기를 가지고 자신감 있게 개발 - 코드를 작성하기 전에 테스트, 빠르게 피드백, 테스트에 부합하지 못하는 코드를 리팩토링 할 수 있는 용기 |
| 단순성 (Simplicity) |
- 필요한 것만 하고 그 이상의 것들은 하지 않음 |
| 의사소통 (Communication) |
- 개발자, 관리자, 고객 간의 원활한 소통 |
| 피드백 (Feedback) |
- 의사소통에 대한 피드백 |
| 존중 (Respect) |
- 팀원 간의 상호 존중 |
XP(eXtream Progamming)의 12가지 기본 원리
XP의 효율성은 다음의 12가지의 기본 원리로부터 얻어낼 수 있습니다.
| 기본 원리 | 설명 |
| 짝 프로그래밍 (Pair Programming) |
- 두 명이서 짝이 되고 개발 |
| 공동 코드 소유 (Collective Ownership) |
- 시스템에 있는 소스 코드는 누구든지 언제라도 수정 가능하다는 원리 |
| 지속적인 통합 (CI, Continuous Integration) |
- 매일 여러번 소프트웨어를 통합하고 빌드 해야 한다는 원리 |
| 계획 세우기 (Planning Process) |
- 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 원리 |
| 작은 릴리즈 (Small Release) |
- 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리 |
| 메타포어 (Metaphor) |
- 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리 |
| 간단한 디자인 (Simple Design) |
- 현재의 요구사항에 적합한 단순한 시스템을 설계한다는 원리 |
| 테스트 기반 개발 (TDD, Test Driven Development) |
- 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리 |
| 리팩토링 (Refactoring) |
- 프로그램의 기능을 바꾸지 않으면서 중복된 기능을 제거하고 코드를 단순화하여 시스템을 재구성하는 것 |
| 40시간 작업 (40-Hour Work) |
- 개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상 일하지 않는다는 원칙 |
| 고객 상주 (On Site Customer) |
- 개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리 |
| 코드 표준 (Coding Standard) |
- 효과적인 공동 작업을 위해서는 모든 코드에 대한 코드 표준을 정의해야 한다는 원리 |
