[책/읽기전] 테스트 주도개발 - 켄트백 ( 김창준, 강규영 옮김 )

이번에 책을 무려 3권이나 구입했는데, 그 중에 하나.

  테스트 주도 개발  

켄트 벡 지음, 김창준 외 옮김
최근 학계와 업계에서 많은 주목을 받고 있는 프로그래밍 방법인 '테스트 주도 개발(Test-Driven Development)'에 대해 설명한 책이다. 테스트 주도 개발을 퍼뜨린 장본인이며 객체 지향 프로그래밍의 선구자 중 한 사람인 켄트 벡이 직접 서술했고, 부록에는 TDD 시연 동영상을 수록했다.

지금은 겨우 서문을 다 읽고 1부의 1장을 아주 조금 읽었다.
실제 내용은 겨우 5-6페이지 읽었을 뿐이다.

책의 앞에는 옮긴이의 서문과, 옮긴이가 쓴 TDD 수련법, 옮긴이와 글쓴이의 인터뷰내용이 들어 있다.
이 내용은 테스트주도개발을 처음 접하는 독자들에게는 그렇게 크게 느낄만한 내용이 없다.

처음 읽는 사람은테스트 주도 개발이 뭔지도, 왜 필요한지도 모르기 때문이다.


저자의 글에서 몇가지 정리하면..

. 매 결정사항에 대해 피드백을 제공하는 실행 가능한 코드를 기반으로 하는 유기적인 설계를 해야 한다.
. 테스트를 쉽게 만들려면 반드시 응집도는 높고 결합도는 낮은 컴포넌트들로 구성되게끔 설계해야 한다.

| 용기 |
두려움이란 나쁜 의미의 - 무서워요. 프로그래머는 젖꼭지가 필요해요 - 두려움을 뜻하는 것이 아니고, "정말 어려운 문제라서 시작 단계인 지금은 어떻게 마무리될지 알 수 없군" 하고 생각하는 식의 합리적인 두려움을 말한다.

. 두려움은 여러분을 망설이게 만든다.
. 두려움은 여러분이 커뮤니케이션을 덜 하게 만든다.
. 두려움은 여러분이 피드백 받는 것을 피하도록 만든다.

프로그래밍 문제가 어려울수록 각각의 테스트는 좀 더 작은 부분을 커버해야 한다.

순수하게 TDD로만 풀어낼 수는 없는 프로그래밍 작업이 분명히 있을 것이다( 혹은 최소한 아직까지는). 예를들면 보안 소프트웨어와 동시성(concurrency)은, TDD로 해당 소프트웨어의 목표가 달성되었다는것을 기계적으로 보여주기에 부족한 두 가지 주제라고 할 수 있다.

설계는 반드시 잘 되어야 한다. 그렇게 해야만 Test를 이용해서 개발하기가 쉬워진다. 즉, 테스트가 설계를 잘 하도록 도와주지는 않는다. 그렇기 때문에

설계가 우선 되어야 한다.

들어가는 글에서..

"... 하지만 미합중국 달러로 명명된 채권만 다루더군요. 저는 새로운 채권 펀드를 시작하려고 하는데 제 전략상 다른 화폐로 채권을 다룰 필요가 있습니다." 라고 했다. 보스가 워드를 돌아보며 말했다. "저기, 우리가 그걸 할 수 있을까요?"
이것이 바로 어떤 소프트웨어 개발자에게든 악몽이 될만한 시나리오다. 당신의 몇가지 가정하에 성공적이고 행복하게 순항하고 있었는데 별안간 모든것이 바뀌었다.

.....

그날 하루가 끝나갈 즈음에는 테스트가 전부 통과했다. 워드는 코드를 빌드에 체크인하고 보스를 찾아갔다. "할 수 있습니다.", 그는 확신에 차서 말했다.

이 이야기에 대해 조금만 생각해보자. 이틀 만에 잠재적 시장이 몇 곱절이나 커졌고 덕분에 와이캐시의 가치 역시 몇 배 늘어났다. 하지만 그렇게 빨리 그토록 많은 비즈니스 가치를 만들어내는 능력은 우연이 아니었다.

저기에서는 저기 빨간 말이 진짜 마음에 와 닿는다.

당신의 몇가지 가정하에 성공적이고 행복하게 순항하고 있었는데 별안간 모든것이 바뀌었다.

대충 요렇다~


딱 요만큼만 보고, 충분히 -_- 필요하다고 공감했다.