Overview of XP with Planning, Testing and Refactoring

 

익스트림 프로그래밍(영어: eXtreme Programming, XP)는 소프트웨어 개발 방법이다.
이는 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법이다.
애자일 개발 프로세스라 불리는 개발 방법 중의 대표적인 하나로 꼽힌다.

10~12개 정도의 구체적인 실천 방법(Practice)을 정의하고 있어, 비교적 적은 규모의 인원의 개발 프로젝트에 적용하기 좋다. 개발 문서 보다는 소스코드를, 조직적인 개발의 움직임 보다는 개개인의 책임과 용기에 중점을 두는 경향이 크다.

XP의 목적은 '고객이 원하는 양질의 소프트웨어를 빠른 시간안에 전달하는 것'이다. 수시로 발생하는 고객의 요구사항에 대처하고, 고객이 원하는 SW를 고객이 원하는 시간에 인도하기 위해서는 고객과 팀원간의 대화를 통해 해결한다.

 

제안자 켄트 백은 XP를 이끄는 가치와 원칙에 대해서도 강조했다. XP에서 실천 방법에만 집중하고 가치와 원칙을 무시하면 제대로 XP를 실천하고 있다 하기 힘들 것이다. 원칙은 가치와 실천 방법을 잇는 다리 같은 것이다.

• 가치 : 의사소통, 단순성, 피드백, 용기, 존중
• 원칙 : 인간성, 경제성, 상호이익, 자기 유사성, 개선, 다양성, 반성, 흐름, 잉여, 실패, 품질

---

Planning

XP에서 계획을 세우는데에는 중요한 2가지가 있다. 

 

첫 번째, 이번 반복(iteration)에는 어떤 개발 과정을 끝마칠 것인가. 

두 번째, 그 이후 개발 반복(iteration)에서는 무엇을 할것인가이다. 

 

XP는 일반적으로 2주를 주기로 계획을 세우고 프로토 타입을 만든다. 주기마다 Whole Team 은 (최종 사용자 혹은 프로젝트를 의뢰한 의뢰인과 함께) 무엇이 얼만큼 개발이 되었는지 혹은 알맞은 방향으로 개발이 진행이 되어가고 있는지 검사 혹은 회의를 한다. 그렇기 때문에 그 기한안에 프로젝트 혹은 프로토 타입은 반드시 개발이 완료가 되어야 한다. 만약 그렇지 못해서 기한을 연장하게 되면, 그에따른 추가 비용및 시간적 손실이 발생하게 된다. 또한, 이를 통해서 소프트웨어 개발의 투명성을 확보 할 수가 있다. 기업의 입장에서 좋은 점은 그들의 실력및 가능성을 보여줄수 있는 기회로 사용될 수 있으며, 사용자 혹은 의뢰인 입장에서는 더욱 큰 금전적 손실이 발생하기 전에 프로젝트를 취소하고 다른 개발팀을 찾아 볼 수 있는 기회로 사용될 수도 있다.

 

반복에서 반복, 완료에서 완료에 이르기까지 프로젝트는 예측 가능하고 편안한 리듬에 빠진다. 

whole team은 무엇을 기대하고 언제 기대해야 하는지 알고 있습니다.

stakeholders는 자주 그리고 상당한 진전을 봅니다. 그들에게 다이어그램과 계획으로 가득 찬 노트를 보여주기 보다는 만지고 느끼고 피드백을 제공할 수 있는 작동하는 소프트웨어를 보여준다.
개발자들은 자신의 추정치를 바탕으로 합리적인 계획을 세우고, 자신이 측정한 속도에 의해 통제되며, 자신이 일하기에 편안하다고 느끼는 작업을 선택하고, 자신의 작업 품질을 높게 유지한다.
관리자들은 매번 반복적으로 데이터를 받는다. 이 데이터를 사용하여 프로젝트를 제어하고 관리한다. 임의적이고 비현실적인 날짜를 맞추기 위해 압력, 위협 또는 충성심에 호소할 필요가 없다.

 

---

Testing

다른 애자일 방법론과 구분되는 XP만의 특징에는 테스팅이 있다. 

 

XP는 프로그래머들이 코딩을 할때에 테스트 코드를 작성하도록함과 동시에 테스트를 기반으로 프로젝트를 완성시켜 나가도록 한다. 가장 흔히 발생하는 소프트웨어 개발 실패중 하나는 개발이 끝난 제품 혹은 소프트웨어가 처음 사용자 혹은 의뢰인이 원했던것과 다르다는 것이다. 또한 이러한 테스트에 기반을둔 프로젝트 발전 과정은 애자일 방법론의 기본 개념인 "반복적으로 프로토 타입을 고객에 전달함으로써 고객의 요구사항 변화에 민첩하게 대응한다" 를 실천하는데에 큰 도움을 줄 수 있다. 왜냐하면 매번 프로토 타입을 고객에 전달해주며 개발자들이 잘못 이해하고 있었던 부분에 대해서 수정을 거치기도 한다. 더욱더 의뢰인 혹은 최종 사용자의 요구에 부합하는 소프트웨어를 만들어 내게 된다.

 

모듈이나 애플리케이션을 testable 하게 하려면 모듈이나 애플리케이션을 분리해야 한다. 

이들은 테스트 가능할수록 분리된다. Acceptance Test 와 Unit Test 를 고려하는 행위는 소프트웨어의 구조에 매우 긍정적인 영향을 미칩니다.

 

---

Refactoring

코드가 썩는 경향이 있습니다. 기능 뒤에 기능을 추가하고 버그 뒤에 버그를 처리하면 코드의 구조가 저하된다. 이 저하를 방지하지 않은 채로 두면 유지할 수 없는 혼란이 발생한다. XP 팀은 잦은 리팩토링을 통해 혼란을 방지한다. 리팩토링이란 시스템의 동작에 영향을 주지 않고 시스템의 구조를 개선하는 일련의 작은 변환을 수행하는 것이다. 각각의 변환은 사소하지만 그들은 함께 시스템의 설계와 아키텍처의 중요한 변환이 된다.

작은 변환이 끝나면 단위 테스트를 실행하여 고장이 없었는지 확인하고, 다음 변환을 수행하고, 그 다음과 다음 테스트를 수행한다. 이와 같은 방식으로 시스템의 작동을 유지하는 동시에 설계를 변환한다. 리팩토링은 프로젝트가 끝날 때나 릴리스가 끝날 때, 반복이 끝날 때나 심지어 하루가 끝날 때보다 계속해서 이루어진다. 리팩토링을 통해 코드를 가능한 한 깨끗하고 단순하고 표현적으로 유지한다.

 

소프트웨어 모듈에는 세 가지 기능이 있다.

첫 번째는 실행 중에 동작하는 기능으로, 이 기능은 그 모듈의 존재 이유가 된다.

두 번째는 변경 기능이다. 변경하기 어려운 모듈은 그것이 제대로 동작한다 하더라도 망가진 것이며 수리가 필요하다.

세 번째는 읽기 쉬워야 한다.

 

1. 독립된 함수로 나누어야 함 - 함수는 한가지 기능만! 개별적인 메소드로 추출하기

2. 읽기 쉽게 ex) f= new boolean[maxValue +1], for문 에서 (i < f.length) 그대로 쓰기, 이중부정쓰지 않기--혼란 <- 함수로 빼고 이름부여 if(notCrossed(i)) uncrossed[i] = false 대신

 

---

Agile Manifesto 가 나온 이유는 무엇이라고 생각하는가?
즉, 어떤 문제가 있었고 어떻게 풀겠다는 이야기인가? 설명하라.

 

 소프트웨어를 개발하는 데에 있어 계획이 너무 없다면, 일을 효율적으로 하지 못한다. 전체 프로세스에서 중요하지 않은 부분에 시간을 너무 많이 쓸 수도 있고, 이후 프로세스를 예상하지 못한다.
 반면 소프트웨어를 개발하는데에 있어 계획이 너무 많다면 해당 프로세스를 따르기 위한 시간과 비용 소모가 꽤나 들것이 다. 또한 계획에 너무 의존하게 된다면 개발 흐름이 느려질 수 있다.
 에자일 방법론은 이러한 개발방법들 사이에서 타협점을 찾기위해, 그래서 실질적인 코딩을 하기 위해 탄생되었다.

 

XP 는 무엇이고, 어떻게 Agile manifesto 의 정신을 구현했는지 설명해보라.

 

 XP 는 에자일 개발 방법 중 하나이다. 그리고 수업을 통해 Agile manifesto는 소프트웨어 팀이 빠르게 일하고 변화에 반응할 수 있도록 하는 가치와 원칙이라는 것을 배웠다. XP 의 목적은 고객이 요구하는 양질의 소프트웨어를 빠른 시간안에 전달하는 것이고, 이는 Agile manifesto 에 부합한다.
  XP 는 2주 단위로 iteration 을 가져 그때마다 검사 또는 회의를 한다. 그렇기 때문에 개발자는, 그 기한안에 프로젝트나 프로톤타입 개발 완료해야한다. 고객은 프로토 타입을 받아보고, 요구사항이나 수정사항 등을 전달할 수 있다. 이러한 계획은 효율적이며 비용과 시간의 최적점을 찾을 수 있고, 실질적인 코딩을 할 수 있게 된다.
  또한 XP 는 testing에 기반을 두었다. 테스트에 기반을 둔 프로젝트는 애자일의 기본 개념을 실천할 수 있다. 매번 프로토 타입을 고객에게 전달해주며 개발자들이 잘못 이해하고 있던 부분에 대해 빠른 수정을 할 수 있다. 최종적으로는 end user 의 요구에 부합하는 소프트웨어를 만들어 낼 수 있다.

 

 

---

출처

https://ko.wikipedia.org/wiki/익스트림_프로그래밍

Agile Softeware Development, First Edition, Pearson, 2014