TDD 에 집착해야하는 이유
1. 개념
프로그래밍 의사결정과 피드백 사이의 간극을 의식하고, 이를 제어하는 기술이다.
테스트 기술이 아니다. TDD는 분석기술이고, 설계 기술이다.
Test First Development + Refactoring = Test Driven Development
단순히 테스트를 먼저 작성하는 것을 의미하는 것이 아니다.
중요한 것은 리펙토링. 짧은 리듬의 설계를 지속하는 것.
짧은 설계와 구현을 통해 프로그래밍에 자신감을 더할 수 있다.
2. 과정
실패하는 코드를 먼저 만든다.
통과하는 코드를 짠다.
테스트를 통화한다.
3. TDD에 집착해야하는 이유
요구사항 추가, 변경 때문에 소스 코드를 수정하고 느끼는 불안함을 줄인다.
한번에 한가지에만 집중한다.
먼저 실패하는 테스트를 만든다.
다음 단계 에서는 구현에만 집중할 수 있다.
실패하는 테스트 -> 테스트 성공
로직을 구현하는 것에만 집중한다.
테스트를 통과하기 위해서 어떠한 악행도 허용된다.
마지막 단계에서는 마음의 평화와 함께 창의적인 생각으로 리펙토링에 집중한다.
기능은 똑같으나
메소드, 클래스 설계
클린코드 구현
내가 구현하는 코드에 자부심을 느낄 수 있다.
리펙토링은 많이 하면 할수록 정말 즐겁다.
리펙토링은 예술이다.
4. TDD를 삶에 응용하기
4-1. 책쓰기
현재 상태에서 쓸 수 있는 내용 위주로 빠르게 챕터를 마무리
챕터를 마무리 했으므로 inner peace
챕터 마무리한 후, 편집자 혹은 주변 친구들에게 공유해서 피드백 받는다.
피드백 받아서 챕터별로 퇴고한다. - refactoring
모든 챕터를 마무리한 뒤, 2차 퇴고한다.
마음에 들때까지 무한 루프
4-2. 회사 다니면서 창업하기
측정 가설을 세운다.
구현을 통해서 소비자에게 피드백을 받는다.
개선한다.
측정 가능한 가설을 세운다.
구현을 통해 소비자에게 피드백 받는다.
개선한다.
목표 수익이 달성될떄까지 반복 개성한다.
일정 목표를 달성하면 퇴사한다.
4-3. 일반 사람과 성공하는 사람의 차이
일반인 : 한번에 잘 준비해서 한방에 성공을 노림
성공하는 사람 : 짧게 준비하고 실패한다. 점진적으로 향상되어 앞으로 나아간다.
5. TDD, Refactoring 의 핵심
큰 단위를 작은 단위로 나눠 빠르게 실패한다.
피드백을 통해서 지속적으로 개선한다.
달성하기 힘들 것으로 생각하는 일에 도전할 수 있는 용기를 얻는다.
6. 현존하는 문제
앞으로 해결해야할 상당히 많은 문제는 명확하게 문제가 정의되어 있지 않거나, 분석할 데이터도 없기 때문에 기존의 접근방식으로 해결하기 힘든 complex 영역이다.
끊임없이 작은 실패와 피드백을 통해 점진적으로 개선해 나가는 것이 앞으로 남겨진 문제를 해결하는 좋은 방법이다.
Last updated
