저자의 글
작동하는 깔끔한 코드가 훌륭한 목표임을 말해주는 이유
- 예측 가능한 개발 방법이다. 끊임없이 발생할 버그에 대해 걱정하지 않고, 일이 언제 마무리되는지 알 수 있다.
- 코드가 가르쳐주는 모든 교훈을 학습할 기회를 갖게 된다.
- 당신이 만든 소프트웨어는 사용자의 삶을 향상시켜준다.
- 동료들이 당신을 존경할 수 있게 해주며, 당신 또한 동료들을 존경할 수 있게 된다.
- 작성하는 동안 기분이 좋다.
깔끔한 코드를 얻기 위해서는 자동화된 테스트로 개발을 이끌어가야 하는데 이런 개발 방식이 테스트 주도 개발이다.
TDD(테스트 주도 개발)에서는 두 가지 규칙만을 따른다.
위 규칙들은 다음과 같은 행동패턴을 만들어낸다.
- 유기적인 설계
- 직접 테스트 작성
- 작은 변화에도 빠르게 반응하는 개발 환경
- 응집도는 높고 결합도는 낮은 컴포넌트 설계
프로그래밍 순서 또한 결정된다.
1. 빨강 - 실패하는 작은 테스트 작성
2. 초록 - 빨리 테스트가 통과하게끔 만든다. (어떤식으로든, 테스트만 간신히 통과하도록)
3. 리팩토링 - 생겨난 모든 중복을 제거한다.
위와 같이 프로그래밍 해야하는 이유가 뭘까?
만약 위와 같이 프로그래밍하여 코드의 결함율을 극적으로 낮추고, 팀원 누구나 코드를 알아볼 수 있다면
- 결함 밀도를 낮출 수 있다면 → QA를 수동적인 작업에서 능동적인 작업으로 전환 할 수 있다.
→ 새 기능의 선적 가능한(?) 소프트웨어를 매일 갖게 되고,
이를 고객과 새로운 비즈니스 관계에 이를 수 있다.
- 역한 예외 상황의 숫자를 낮출 수 있다면 → PM이 정확히 추정할 수 있어 고객을 매일의 개발 과정(?)에 참여시킬 수 있다.
- 기술적 대화의 주제가 분명해질 수 있다면 → 소프트웨어 엔지니어들은 분 단위로 협력하며 일할 수 있다.
이런 장점이 있다해서 왜 개발자가 테스트를 만드려고 추가작업을 해야하는 지 이해하지 못할 수 있다.
보통 개발자들은 "정말 어려운 문제라서 시작 단계인 지금은 어떻게 마무리 될 지 알 수 없군" 과 같은 합리적인 두려움을 자주 느낀다.
이러한 두려움은 개발자들을 망설이게 만들고, 커뮤니케이션을 덜 하게 만들고, 피드박 받는 것을 피하도록 만든다. 이것들은 어떠한 것도 프로그래밍에는 도움이 되지 않는다. 따라서 이런 것들에 맞서 구체적인 학습을 하고, 커뮤니케이션 하고, 피드백을 회피하지 않아야 한다.
TDD를 배우는 대다수의 개발자들은 자신의 프로그래밍 방법이 영원히 바뀌어 버렸다는 걸 깨닫는다. TDD를 배운 후에는 꿈도 못 꿀 만큼, 더 많은 테스트를 일찍 작성하고, 또 더 작은 단계로 작업하고 있다는 것을 깨닫게 될 것이다.
이 책을 끝까지 읽고 나면
- 단순하게 시작하고
- 자동화된 테스트를 만들고
- 새로운 설계 결정을 한 번에 하나씩 도입하기 위해 리팩토링을 준비할 것이다.
Last modified: 31 January 2024