5. XP란?
• 철학이란 뭔가요?
• 임마누엘 칸트, “철학은 가르칠 수 없다. 다만
철학함을 가르칠 수 있을 뿐이다.”
• XP란 뭔가요?
• 켄트 백, “XP란 사회적 변화에 관한 것이다.”
• 그래서 XP가 뭔가요…
6. XP란?
• 오래되고 효과가 없는 사회적 습관들을 버리고
효과 있는 새로운 습관을 채택하는 것.
• 오늘 내가 기울인 모든 노력에 대해 자신을
인정해 주는 것.
• 내일은 좀 더 잘 해보려고 애쓰는 것.
7. XP란?
• 팀 전체가 공유하는 목표에 내가 얼마나
기여했는지를 잣대로 자신을 평가하는 것.
• 소프트웨어 개발을 하는 중에도 여러분의
인간적 욕구 가운데 일부를 채우겠다고
요구하는 것.
8. XP의 핵심 아이디어
• **잦고 효과적인 의사소통을 지향하자**
• 내가, 네가, 우리가 사람임을 인정하자
• 아기의 걸음처럼: 작은 보폭으로, 우선 순위가
높은 기능부터
• 깨끗한 소프트웨어를 만들기 위한 여러 노력
• 페어 프로그래밍
• 빠른 릴리즈 주기
• 단위 테스트, 기능 테스트, 그리고 테스트 자동화
9. XP가 대처할 수 있는 것들
• 비용 문제
• 일정 밀림
• 시스템 이상
• 결함 비율
• 이름뿐인 풍부한 기능
10. XP가 대처할 수 있는 것들
• 커뮤니케이션 문제
• 비지니스에 대한 오해
• 비지니스의 변화
• 직원 교체
12. 방법론으로써의 XP – 짝 코딩
• 건초염이 옴.
• 어쩔 수 없이 키보드를 못치는 상태.
• 회사 이사님께서 하신 제안,
• “이렇게 된거, 짝 프로그래밍으로 간다!”
• 이렇게 된거, 회복하는 한달 동안 매일 짝 코딩을
하게 되는데…
• 켄트 백은 ”출시를 위한 코드는 페어
프로그래밍을 꼭 하라” 라고 주장.
13. 방법론으로써의 XP – 짝 코딩
• 우리가 세운 원칙 : “네비게이터” 와 “드라이버”
를 결정
• 네비게이터
• 옆에서 이래라 저래라 하는 역할
• 현재 작업의 방향성을 결정
• 단, 전체적인 방향성, “이 시간에 무슨 일을 할까?”는 함께
정한다.
• 드라이버의 작업에 세세한 실수를 보정, 같이 토론
• 아이디어나 추상적인 생각에 여유를 가지고 작업
14. 방법론으로써의 XP – 짝 코딩
• 우리가 세운 원칙 : “네비게이터” 와 “드라이버”
를 결정
• 드라이버
• 네비게이터의 노예
• 네비게이터의 방향성 대로 코딩
• 네비게이터의 방향성에 대한 피드백
• 코드에 더 집중한 구체적인 아이디어를 내기 좋음
15. 방법론으로써의 XP – 짝 코딩
• 실제 적용
• 손이 아프던 내가 네비게이터, 이사님이
드라이버를 잡으심(죄송합니다)
• 저 원칙 이외에 특별한 원칙을 갖지 않았지만,
효과는 확실했다.
• 효율이 실제로 뛰어나서 건초염이 낫고도
한동안은 페어 프로그래밍
• 드라이버로 전직하게 된건 안비밀…
16. 방법론으로써의 XP – 짝 코딩
• 실제 적용
• 안좋았던 점
• 처음에 익숙해 지는 시간 필요
• “굉장한” 피로감.
• 한명이 정신이 나가면 도움이 안됨
• 특히 네비게이터가 정신이 나가면 안됨!!
17. 방법론으로써의 XP – 짝 코딩
• 실제 적용
• 좋았던 점
• 서로에게 배운다. 아주 사소한 것부터, 통찰력까지.
• 기쁨은 나누면 배가 되고 고통은 나누면 반이 된다
• 내가 힘들 떄 믿고 의지할 사람이 있음
• 개발자끼리 친해짐
• 가장 중요한, “실제 효율이 증가!”
18. 방법론으로써의 XP – CI
• 실제 Jenkins를 이용한 개발은 잘 안해봄
• 하지만, github을 이용한 (부분적인) 지속적인
통합은 효과를 많이 봄!
• 네이버 D2 FEST를 출전하면서 본격적으로 익힘.
• 질문: git은 잘 쓰시나요?
• Keyword: issue, pull request, wiki
19. 방법론으로써의 XP – TDD
• Test Driven Development
• 소프트웨어 장인이라는 책을 읽고 뽐뿌를 받아
시작
• 원칙: 테스트를 먼저 작성하고, 그 테스트에 맞는
코드를 작성하라!
20. 방법론으로써의 XP – TDD
• 실제 적용:
• 현재 MFER 라는 의학 파형 데이터
인코더/디코더를 TDD를 통해 작성 중
• 단점:
• 수련이 필요함
• 하지만, 켄트 백과 함께라면 우린 최고야!
• 적용이 안되는 분야도 있음
• AI, Interactive한 UX, Multithreading 상황등…
• 장점:
• 나머지 다
• 장난이고…
21. 방법론으로써의 XP – TDD
• 실제 적용:
• 장점:
• Test가 자동으로 되기 때문에 느껴지는 안정감
• 이제 내가 자유롭게 수정해도 상관없겠구나
• **잦은 리팩토링이 일어나므로 코드 질 상승**
• 코드는 계속 고민하고 건드릴수록 발전
• “쓸 함수”를 가정하므로 코드 질 상승
• 쓰지 않을 함수를 만들지 않으므로 생산성 향상
23. 가치로써의 XP: 인간임을 인정
• 문제가 있을 수 있음을 인정한다.
• 고로 피드백을 수용하고, 적극적으로 제안한다.
• 상대방을 존중한다.
• 차카게 살자
24. 가치로써의 XP: 인간임을 인정
• 실제 사례:
• 현재 회사에서는 내가 의견을 내면 굉장히
경청해주는 편
• 꼭 내 문제가 아니더라도 의견을 낼 수 있게
해주고, 실제로 방향성을 그에 맞춰서 가는
경우도 많았음.
• 덕분에 이사님들이 나에게 조언을 하시더라도
피드백으로 느껴질 뿐, 꼰대질로 안느껴짐.
25. 가치로써의 XP: 인간임을 인정
• 실제 사례:
• 항상 실패하는 경우는
• 내가 오만에 가득찰 때
• 커뮤니케이션이 부족할 때.
• 실패해도 된다: 회고하고 반성하고 그 실수가
나온 요인을 해결하면 된다.
• 항상 대화하고 문제를 미리 부각시킴으로써
효과적으로 풀어야 하는 문제를 풀자!
26. 가치로써의 XP: 가치의 실현
• 가장 첫 질문: “어떤 가치를 실현할까?
• 모든 선택 이전에 고민해 볼 것
• 토론은 일어 날 수 밖에 없다. 이때 결정은
권위나 떼쓰는 것이 아니고, “우리의 공통
가치에 부합하는가?”
• 이게 가능하려면 항상 모두가 공통의 가치를
깊게 공감해야 한다.
• 가치와 상관없는 기능은 가감없이 뺴버리자.
• 커뮤니케이션이 필요하다!
28. 어떻게 할 것인가 - 가치
• 같이 재밌게 공부하고 대화하자.
• 내가 생각하는 우리 모임의 제 1 가치:
• “재미있게 발전하자!”
• 재미를 침해하는 것을 배격하고, 어떻게 하면
재밌을 수 있을지
• 발전을 침해하는 것을 배격하고, 어떻게 하면
발전할 수 있을지
29. 어떻게 할 것인가 - 방법
• 함께 할 수 있는 것을 하자,
• ”Pair Programming!”
• 기본적인 원칙은 한번 토론해 봅시다.
• 우리의 가치를 실현할 수 있는 여타 방법론의
도입도 해봅시다.
• 애자일에 대해서 글을 읽어 봅시다.
30. 왜 KeyValuePair인가?
• … 사실 slack url을 뭔가 정해야 해서 개발오덕
스러운 “Pair”가 들어가는 단어를 쓴 것
• ”TDD를 적용할 수 없다면, 어떻게 하나요?” 에
대한 소프트웨어 장인의 대답: PP를 하세요.
• 어쩌면 핵심 가치를 창출할 수 있는 가장
도입하기 쉽고 빠르고 중요한 방법론이 Pair
Progrmaming이 아닌가…
• 그래서 “핵심 가치를 창출하는 짝궁” 이라는
의미의 KeyValuePair가 됨.
31. 참고 문헌
• 켄트 백
• Extreme Programming Explained
• Test Driven Development by example
• 그 외
• 소프트웨어 장인
• 클린 코드를 위한 파이썬을 이용한 테스트 주도 개발