TDD에 대한 단상

TDD에 대한 단상

---

몇가지 전제

일단 TDD에 대해서는 책 한 권(테스트 주도 개발 TDD 실천법과 도구) 

읽은 것 외에는 아직 제대로 된 지식이 없다.

물론 설계도 내 경력에 비해 그리 잘한다고는 할 수 없고...

또한 TDD와 설계는 모두 구체적인 실체가 드러나기 전해 행해지는
작업이라는 부분에 초점을 맞추고 있다.

그리고 이 글은 초급 개발자들이 이러한 기술들을 습득하는 과정에 대한
이야기다.

---

무에서 유를 창조하다.

앞서 전제를 달았듯이 TDD나 설계가 어려운 이유는 일단 아무런 구체적
실체가 없는 상태에서 시작을 하기 때문이다.

조금 더 엄밀하게 표현을 하자면 현재는 아무것도 없지만 과거의 경험이 
밑바탕이 되어 수행이되는 작업으로 경험이 밑바탕이 된다는 점에서
역시나 고급 경력자들에게나 걸맞는 일이다.

하지만 설계는 그렇다 쳐도 TDD의 경우에는 팀 전체가 일관된 룰을 
따라야 할 필요가 있다. 이는 곧 팀에서 가장 경력이 짧은 팀원들도
TDD를 익히고 이 방법을 따라야 한다는 말이다(물론 프로젝트 상황에
따라 다를 수 있고 또 페어 프로그래밍 등으로 보완할 수는 있겠다).

하지만 적절한 경력이 쌓이지 않은 상태에서 이런 작업은 결코 쉽지 않다.
사실 ‘무’라고 표현을 했지만 ‘추상적’이라고 말하는 것이 조금 더 
적합할지도 모르겠다.

굳이 별다른 예를 들지 않더라도 우리는 일상 생활에서 보다 쉬운
이해를 돕기 위해 구체적인 예를 든다. 물론 내가 읽은 TDD 책에서도
은행에서의 금전출납을 예로들어 설명을 하고있다. 하지만 그럼에도
불구하고 쉽게 이해가 가지 않고 어렵게만 느껴지는 것이 TDD가
단순히 값의 옳고 그름만을 판단하는 기능을 하는 것이 아니기 때문일
것이다.

이러한 상황은 결국 학습 곡선을 길게 만들고 장기 프로젝트가
아닌 다음에는 쉽게 경험을 하기도 힘들고 다른 측면으로는 익숙하지
않은 기술을 실제로 적용함으로써 발생하는 비용 또한 고려를 하게 만들 것이다.

---

단계를 바꾸어보자.

누차 반복하지만 TDD나 설계를 쉽게 익힐 수 없는 것은 그 것이
추상으로부터 시작하는 작업이며, 결국 경험에 의존할 수 밖에
없기 때문이다.

거꾸로 이야기 하면 충분한 경험을 쌓기 전에는 TDD나 설계를 하기가
힘든 것이다. 하지만 여기서 중요한 것은 경험에 숨어있는 한 단어다.
바로 자~~알...좋은 경험을 해야 좋은 TDD와 설계가 나올 수 있는
것이다. 좋은 코드를 작성해본 적이 없는데 좋은 TDD나 좋은 설게를
할 수는 없는 법이다.

그럼 좋은 코드를 만드는 것은 어떻게 경험을 할 수 있을까?
바로 우리가 잘 알고있는 Refactoring이 그 답이 아닐까 한다.

자꾸 내 경험을 이야기해봐야 객관성은 떨어지지만(어차기 내 글 자체가
객관성하고는 거리가 멀다...ㅠ.ㅠ) 사실 TDD 책을 읽을 때에 비하면
리팩토링 책(Refactorting, 대청)을 읽을 때 더 이해가 쉬웠고 더불어
이해한 내용을 직접 실전 적용해볼 샘플들이 넘쳐났다.(그렇다고 해서
모든 내용을 다 이해한 것은 아니다!)

다시 강조하지만 지지고 볶을 실체를 놓고 그 것을 개선하는 Refactoring이
좀 더 초보자들에게는 쉬운 접근법이라고 판단된다.

그렇다고 실제 프로젝트에서 개판 오분전인 코드를 그냥 두지는 않을 것이고
하다못해 PMD를 돌려서라도 어느 정도 정적 분석정도는 거치고 난 경우가
많을 것이다. 최소한 그정도 수준이라면 Refactoring을 통해 어떻게 해야
보다 나은 코드를 만들 수 있는지에 대한 경험을 쌓기에는 충분하지 않을까 한다.

결국 일반적인 코딩 작업 -> Refactoring -> Unit Test -> TDD로 나가는
방향이 맞을 것으로 보인다.

이렇게 쓰고 보니 TDD는 말 그대로 테스트 주도, 테스트를 먼저하는 (먼저 실패하라!)
방법인데 이걸 어떻게 적절하게 써먹느냐는 딜레마가 생겨버린다.

---

무작정 좋은 것은 없다.

언제나 합리적인 이론, 좋은 방법, 훌륭한 도구들은 끊임없이 있어왔다.
하지만 누구나 만족할 수 있는 것은 아직 없었다.

누군가에게는 완벽한 솔루션이지만 누군가에게는 힘겨운 장애가 되는 수도
허다하다.

결국 얼마나 상황에 맞는 방법이나 도구를 알맞게 사용하느냐가 관건이리라

2개의 루프를 돌려도 좋으리라 고경력자들은 TDD를 위한 테스트케이스를 만들고
초급개발자들은 그 테스트케이스를 이해한 후 실제 코딩에 들어가고 
하지만 여전히 그에 앞서 보다 구체적으로 좋은 코드에 대한 경험을
쌓게 해주는 것이 더 좋지 않을까 하는 생각이다.

아마 나도 조금 더 TDD에 대해 깊이 이해하게 된다면 오늘의 이 글과는 
또 다른 글을 쓸지도 모르겠다...

---

여담

나쁜 코딩 습관 중 나는 중복 코딩 만큼은 충분히 용인해주고싶다.
불필요한 코드의 증가와 변경이 발생했을 때의 수정 범위가 넒어진다는
치명적인 단점이 있지만 속도면에서 C&P를 따라갈 만한 것이 없다.
더군다나 이러한 중복 코드들은 나중에 Refactoring을 할 때에도
큰 부담 없이 진행을 할 수 있으며 이 과정에서 코드를 다시 보는 과정이 생겨
더 나은 코드에 대한 고민을 가능하게 한다.

혹시라도 나중에 시간에 쫓기는 프로젝트를 할 기회가 있으면 한 번
중복 코드로 도배를 하면서 시작을 해봐야겠다...^^;;;