eXtreme Programming

소수설 주창중 하나인 eXtreme Programming에 대해 알아보자.

eXtreme Programming (XP)

• Agile 개발론의 일부

Pair Programming

• 짝 프로그래밍
• 90년대 말, 2000년 대초 흥했던 유행어
• 2명이서 한팀으로 진행
• 리뷰 / 코드 나눠서 진행하다가 스위칭 해서 다시 진행
• 주장: 둘은 하나보다 낫다. 나은 품질을 가져온다.
• 근데 실질적으로 인건비 2배 > 품질 2배?
• 실제 효과를 측정해보니 가성비가 안 맞다.
  • 리서치에 따르면 페어 프로그래밍 이후 문제가 15% 줄었다.
  • 즉, 효과가 안 맞는다.
• 다만 코드 리뷰 프로세스는 남아서 업계에 도움이 되고 있다.

지속적 통합 (CI)

• 원래는 Grady Booch(index 창시자)가 주창한 방법
  • 그냥 가져다가 자기가 원조라 말하고 있는 꼴
• Code merge시 문제가 많이 발생함
• 그래서 지속적으로 코드를 병합해야 함을 말함
• 근데 여기서 실수가 많이 발생함
• 각자 브랜치에서 오랫동안 작업을 진행하지 말자!
• 굉장히 좋은 방식임
• 하지만 XP가 주창한 CI가 아님

XP의 CI

• 합치는 횟수는 반드시 하루에 여러번이어야 한다.
• 언제나 최신버전!
• 근데 너무 빈번하면 효과적이지 않을 수 있음
• 테스팅에서 문제가 좀 많음
• 버그의 이유는 보통 구현자가 요구사항을 잘못 이해해서 발생함
• 그래서 구현자가 알아차리기 어려움, 그래서 전문 테스터가 존재하는 것

Test-Driven Development

• 개발 과정을 테스트 우선으로 바꿈
• 기능 구현 이전에 반드시 테스트 하는 코드부터 만들어야 함
• 기능부터 만들던 기존의 방법과 반대
• 테스트 코드작성자 == 구현자

방법

1. 어떤 기능을 만들어야 하는지 숙지
2. 그 기능이 제대로 동작하는지 테스트할 코드를 만듦
   • 해당 기능은 아직 구현하지 않았음
   • 단위테스트 사용
3. 기능 구현
4. 2에서의 테스트 실행
   • 성공
   • 실패: 3으로 돌아감
5. 저장소에 있는 다른 단위테스트를 모두 실행
   • 성공
   • 실패: 남코드 망가트린 것. 3번으로 돌아감
6. 구현, 테스트 코드를 저장소에 추가

주장

• TDD하면 극단적 CI도 문제 없음
• 하루에 여러번 브랜치 합쳐도 자동으로 테스트 됨
• 단, 모든 함수에 대해 단위테스트를 만들어야 함
  • 코드 커버리지 100%
• 언제나 모든 코드를 테스트하니 품질이 높아짐

TDD와 경제논리

• 이렇게 하면 당연히 품질이 높아진다.
  • 다른 조건이 동일하다면
• 가성비가 있는가?
• 왜 업계에서 포기했을까?
• 과연 제대로된 테스트 코드를 작성할 수 있는가?
• 단위 테스트 작성 > 작은 함수 > 모듈화, 유연성 측면에서 좋아짐
• 그런데 왜? 굳이?
• 유연한 설계는 절대적으로 좋은 가치가 아니다.
• 적당한 크기가 좋은 것.

경제논리와 안전

• 버그가 없는 프로그램을 만들고 싶은 것은 인정
• 하지만 경제논리를 배제하고 생각할 수 없음
  • 개발비를 아끼려 사용자에게 테스트를 미룸
  • 차라리 불안정한 제품을 주고 할인을 하는게 나을 수 있음
• 단, 인간의 생명에 직결되는 경우에는 경제논리는 중요하지 않음
  • 안전 마진, 안전 계수(기계공학)

효과적인 테스트

• 최종 테스트
• 부품 테스트
• 둘중 하나만 한다면? 당연히 최종 테스트
• 제품 규모가 커지면 최종 제품만 테스트할 수는 없다.
• 적당한 크기로 분리하고 각 부분 동작 테스트가 더 효과적임
• 테스트는 전문가에게 맡기자.
• mock 객체만드는 비용도 너무 높음, api 통신을 해야할 수도 있음

단위 테스트의 용도

• 안전이 중요하다면 고려하자.
  • 꼼꼼히 테스트하기 위해 가성비 좋지 않은 TDD까지 추가하자.
  • 다만 이 결정은 프로젝트 관리자가 해야함(책임자)
• 전문 테스트 인력이 없는 경우
  • 테스터 대신 프로그래머에게 하는건 가성비가 안맞음
  • 오픈 소스 프로젝트인 경우 진행

단위 테스트가 나쁜 것은 아님

• 비즈니스 로직과 관련 없는 알고리즘 관련이라면 쉽게 사용가능
• 매개변수 만으로 함수에 필요한 데이터를 전달 가능한 경우
• 독립적인 모듈로 만들게 되는 경향이 있음

단위 테스트를 위한 다형성

• Mock 개체가 필요해?
• 모든 걸 인터페이스로 만들어야 하는 이유가 나왔다!
• 즉, 단위테스트 mock개체를 위해 인터페이스로 만들어야 한다고 주장
• 사용자가 사용하는 제품과 상관없이 인터페이스를?

동적 타입과 TDD

• 코드 커버리지 100%는 중요하다.
• 그래야 동적 타입 언어를 사용할 수 있기 때문이다.
• ?
• 제품 만들때 동적 타입 언어는 오히려 피해야 함
• 실수가 많이 나옴
• python…
• javascript… → Typescript

정리

• 무조건, 모든과 같은 단어를 사용한다면 조심하자.
• 권위에 호소하는 주장을 경계하자.
• 경제논리에서 벗어난 것은 현실적으로 말이 안된다.
• 경제논리 기반에서 제품을 만들어내는 것이 엔지니어의 역량이다.
• 제품의 특성, 비즈니스 상황, 연구, 양산등의 상황에 따라 방법론은 달라진다.

Reference

• Pocu Academy