Extreme Programming (XP)

익스트림 프로그래밍이란?

- 애자일

- 12개의 키 프랙티스

- 개발자와 사용자를 위한 마인드셋

- 만능은 아니고 그냥 가이드라인

 

The 12 Practices

- The Planning Game

- Small Releases

- Metaphor

- Simple Design

- Refactoring

- Pair Programming

- Collective Ownership

- Continuous Integration

- 40-Hour Workweek

- On-site Customer

- Coding Standards

---

1. The Planning Game

- 다가오는 반복(iteration)을 위한 계획

- 고객이 제공한 스토리 사용

- 기술 담당자가 일정, 추정치, 비용 등을 결정

- 고객과 개발자 간의 협업 결과

- 마치 게임하듯이 편하게 앞으로의 진행을 계획

* 고객 -> 유저 스토리 .. Scrum에는 원래 유저스토리 없었는데 여기서 가져옴

* 여기의 유저 스토리는 ~로서 ~해서 ~하고싶다 이런 거 없음

 

장점

- 쓸모없는 기능에 낭비되는 시간 감소

- 기능의 비용에 대한 고객의 이해도 향상

- 계획에서 추측 작업 감소 (고객과 협업하기에 추측 감소함)

 

단점

- 고객이 항상 있을 순 없음

- 그렇게까지 자주 계획이 필요한가?

 

2. Small Releases

- 기능 측면에서 작음

- 기능이 적을수록 더 자주 릴리즈

- planning game을 지원  

 

장점

- 피드백이 자주 됨

- 추적 가능

- 전체 프로젝트 이탈 가능성 감소

 

단점

- 모든 프로젝트에서 쉽진 않음

- 모든 프로젝트에 필요하지도 않음

- 버전 문제 .. 조각이 많으면 관리가 힘듦

 

3. Metaphor

- 시스템의 구두 아키텍처

- 공통된 용어 집합

=> 용어 통일

 

장점

- 시스템을 위한 공통 용어 세트를 장려

- 못알아먹을 말 감소

- 시스템을 빠르고 쉽게 설명할 수 있는 방법 제공

 

단점

- 메타포가 종종 시스템 자체가 됨 (설명 도구로서의 목적을 잃고, 시스템으로 받아들여짐)

- 의사소통이 오히려 잘 안될 수도 있음

- 시스템이 메타포로 잘 이해되지 않을 때도 있음

 

4. Simple Design

- 필요한 것만 해라

 

장점

- 불필요한 기능 추가로 시간을 낭비하지 않음

- 진행 상황을 더 쉽게 이해할 수 있음

- Refactoring과 collective ownership이 가능해짐

- 프로그래머가 올바른 방향으로 작업하도록 도움

 

단점

- 어디까지가 심플이냐

- 심플이 언제나 최선은 아니고 디테일이 필요한 순간이 있음

 

5. Testing

- 유닛 테스팅

- Test-first design (테스트를 염두에 둬라)

- 자동화

 

장점

- 유닛 테스트는 테스트의 완전성을 촉진

- Test-first 접근 방식은 개발자에게 목표를 제공

- 자동화 -> 회귀 테스트의 집합을 제공

- TDD (Test-Driven Developement)

 

단점

- 자동화된 유닛 테스트가 모든 상황에 접합하진 않음 .. 그리고 자동화가 쉽지 않음

- 단위 테스트에만 의존하는 건 좋은 방법이 아님 .. 모듈 통합 시 문제도 있음

- 테스트 결과는 테스트 자체 품질에 달림

 

6. Refactoring

- 시스템의 구조는 변경하지만, 수행하는 작업 자체는 변경하지 않음

- 시스템의 품질을 어떤 방식으로든 향상

 

장점

- 개발자가 제품 전체를 능동적으로 개선하도록 유도

- 개발자의 시스템에 대한 지식을 향상

 

단점

- 모든 사람이 리팩토링을 할 수 있는 것은 아님

- 리팩토링이 항상 적합하진 않음

- 초기 설계를 잘 하면 필요성은 줄음

 

7. Pair Programming

- 2 개발자 / 1 모니터 1 키보드

- 한 명은 코드짜고 한 명은 생각하고

- 필요하면 역할 스위칭

 

장점

- 둘이 하나보단 낫다

- 집중력 향상

- 전체 접근 방식이 작동할까? / 작동하지 않을 수 있는 테스크 케이스? / 단순화할 방법? 같은 질문에 답할 가능성이 더 높음

 

단점

- 둘이나 필요한 작업이 얼마나 있다고

- 고객에게 납득시키기 어려움

- 모든 사람에게 적합하지 않음

 

8. Collective Ownership

- 코드에 대한 공동 소유권

- 누구든 꺼내서 리팩토링 가능

 

장점

-  팀원 이직 시 손실 완화

- 개발자가 시스템의 일부가 아닌 전체에 대해 책임을 지도록 장려

 

단점

- 실적 평가는 어떻게 하는가 -> 책임감 상실

- 시스템이 커지면 쉽지 않음

 

9. Continous Integration

- 새로운 기능과 변경 사항이 시스템에 즉시 반영

- 코드는 하루 이상 통합되지 않은 상태로 작업되지 않음

 

장점

- 긴 프로세스를 줄여줌

- Small Releases를 가능하게 함

 

단점

- 하루 제한이 언제나 실용적이진 않음

- 깊이 생각해낸 아키텍처의 중요성이 하락

 

10. 40-Hour Week

- 주에 40시간 일 제한

- 정기적인 초과 근무 -> 문제의 증상이지 장기적 해결책이 아님

 

장점

- 개발자들의 효율 향상

- 개발자 복지

- 관리자가 진짜 해결책을 찾도록 강제

 

단점

- 근본적인 원칙에 결함

- 40시간이 매직 넘버?

- 40시간보다 더 필요한 경우는 있을 수밖에 없음

 

11. On-Site Customor

- 고객은 개발자랑 같이 있어야 함

- 프로젝트를 조정하는 역할

- 개발팀에 빠르고 지속적인 피드백을 제공

 

장점

- 실제 개발 관련 질문에 빠르고 전문적인 답변을 제공할 수 있음

- 개발된 것이 필요한 것인지 확인 가능

- 기능 우선순위를 올바르게 설정 가능

 

단점

- 항상 옆에 있는 고객 구하기 힘듦

- 고객이 문제에 대한 지식이 없을 수 있음

- 고객이 결정권이 없을 수 있음

- 계속 옆에 있으면 고객사 손해

 

12. Coding Standards

- 모든 코드가 같은 사람이 짠 거 같아야 함

 

장점

- 개발자가 다른 사람의 코드를 리포매팅 하는 시간을 줄임

- 내부 주석 작성의 필요성을 줄임

- 명확하고 모호하지 않은 코드 작성을 요구

 

단점

- 인라인 문서화의 품질 저하 (주석 필요성이 감소되기 때문)

---

XP 장점

- Built-in Quality (모든 단계에 걸쳐 품질이 일관)

- 전체적인 단순성

- 프로그래머 파워

- 커스터머 파워

- 프랙티스 간 시너지

 

XP 단점

- 비공식적이고, 적거나 없는 문서

- 확장성

- 계약 문제

- 변화 비용에 대한 인지 부족

- Tailoring (수정 필요)

 

유리한 경우

- 크게 불안정한 환경

- 내부 프로젝트

- 합작 투자

 

불리한 경우

- 크고, 복잡한 환경

- 안전이 중요한 상황

- 요구사항이 명확히 이해됨

- 고객이 멀리 있거나 항상 이용할 수 없는 경우