|
개인적으로 기다리던 것 중 대표적인 두개 중 하나가 플레이스테이션 3이고 나머지 하나가 바로 이 책 Test-Driven Development by Example, 번역서명 테스트 주도 개발이다. 길을 가다 추위를 피해 잠시 들렀던 서점에서 이 책을 본 순간 지갑을 열 수 밖에 없었다.
책장을 펼치기 전에 먼저 걱정스러웠던 것은 이 책이 번역된다는 소식을 들은지도 꽤 되었고 번역서는 찾아보기 힘들지만 TDD에 대한 정보들도 그 때 보다는 많이 접할 수 있는 터라 번역서가 과거의 TDD를 이야기 하고 있다면 어쩌나 하는 점이었다.
하지만 몇 페이지를 넘기지 않아서 번역에 걸린 시간을 오히려 앞서갈 수 있도록 옮긴이의 내공이 더해져 있는 책이라는 것을 알 수 있었다.
기민한 방법론(Agile Methods) 등을 이야기할 때 빠지지 않는 수파리(守破離)라는 비유를 들자면 수(守)라는 단계에 한걸음 내딛기 위해 책을 손에 넣은 입장에서 리(離)의 단계를 이야기하고 있는 옮긴이의 깨달음이 존경스러울 따름이다.
그런 이유인지 지은이가 이야기하고 있는 바에 대해 반론 혹은 다른 의견을 제시하는 옮긴이의 주석이 다른 번역서를 읽을 때 처럼 건방지다거나 말꼬리를 잡는것 같다는 느낌도 없다.
지은이가 이야기하는 흐름을 거스리지 않고 읽는이의 앞길을 좀 더 밝혀주는 뱃머리의 등 같은 역자 주가 원서에는 없는 또 하나의 양념이 되고 있는 책이다.
별다섯 원서에 별다섯 번역이 가미된 좀처럼 만나기 어려운 기회를 접한 것 같다.
아직 하얀 띠도 매지 못하고 도장 창문을 기웃거리는 수준에서 이 책의 내용을 이야기 한다면 건방짐 또는 말꼬리 잡기 이상이 아닐 것 같다.
요새 뭐가 그리 피곤한지 좋은 책을 만나도 밤새 읽고 동트는 창을 본 기억이 거의 없었다.
오늘 밤 이독(二讀)에 도전하면서 창고에 넣어둔 헬스 기구처럼 책꽂이를 차지하는 책이 아니라 다음 단계를 꿈꾸며 나에게 끊임없는 수(守)를 수행하게 하는 자극제로서 이 책이 기억되기를 바래본다.
한가지 하드커버 제본된 책이라 들고 다니며 보기에는 좀 무겁다는 아쉬움이 남는 것은 수행에 앞서 편하고자 하는 마음이 여전히 남아 있는 탓일지도 모르겠다. [인상깊은구절] 한국어판 인터뷰 중에서... "저는 가능하면 테스트 우선으로 작업하겠다고 다짐합니다." 라는 구절이 인상에 남는다. XP에서도 그랬지만 지은이 켄트 벡은 TDD가 소프트웨어 개발의 만병통치약임을 주장하는 약장사가 아니다. 나무를 잘 자라게하는 비료를 광고하는 것이 아니라 나무를 잘 가꾸기위한 정원사의 자세를 이야기 하고 있다는 느낌을 받은 구절이다. |
|
/*
예전부터 본다본다 했는데, 조금 두꺼운 책 분량때문에
주저주저 하다가 결국은 허겁지겁 통독을 했다.
(사실 책 내용을 완전히 이해하기에는 정독이 필요하다.)
TDD의 목표 ''작동하는 깔끔한 코드(clean code that works)'' 다.
그리고 TDD의 리듬은 다음으로 요약된다.
1. 테스트를 추가하고 실패하는지 확인한다.
2. 테스트가 성공하도록 코드를 수정하고 성공하는지 확인한다.
3. 리팩토링으로 중복을 제거한다.
설명을 하자면...
1> 테스트는 테스트가 충분히 이해되고 신속한 구현이 가능한 단위로부터
시작한다. 어려울수록 좀더 잘게 나눈다.
순서는 상관이 없으나 가능한 핵심 요구사항을
우선적으로 시작하는 것이 바람직하다.
(그리고 반드시 테스트가 실패하는것을 확인해라.)
2> 로직의 올바름은 상관하지 않고
가능한 빨리 테스트를 통과할수 있도록 코드를 수정한다.
목표는 테스트를 합격하느냐에 있다.
3> 테스트를 통과하기 위해 허겁지겁 채웠던 코드들을 리팩토링한다.
객체의 책임과 역할에 맞게 위치를 바꾸고,
상수를 변수화하고, 메소드를 통합하거나 분리하고
라면을 끓이고 계란후라이를 만들어야 한다.
곰곰히 생각해보면
TEST는 소프트웨어에 대한 기능요구사항이자 제약사항이 된다.
프로그래머는 TEST시점에 스트레스와 불안감을 가지게 되는데
내가 만든 프로그램에 빠뜨린 것이나 실수는 없는지,
또는 내가 사용하는 미지의 솔루션에 어떤 버그가 있는건 아닌지,
출시일이 다가오는데 새로운 요구사항이 튀어나오는건 아닌지...
실수를 걱정해야할 것들이 무엇이 있는지
눈에 보이게 드러내는것이 필요하다.
그리고 그 걱정거리들을 한입에 베어먹을수 있도록
적절하게 잘라두는 것도.
그리고 이왕이면 타이머에 맞춰서 알아서 체크해주는 개인비서(자동화)도
있으면 좋다.
그게 TDD다.
처음 볼때는 불필요한 작업으로 보이는 과정이지만
그 과정을 앞으로 당겨서 얻게 되는 효과는
목적에 충실한 설계와 목적의 수행이다.
책을 읽고나서 당장 의욕이 넘쳐 무엇인가 하기에는
아직 넘어야 할 산이 많다.
하지만 다양한 시도들과 사례들을 통해서
가능성을 타진해보고 시도해볼수 있을 것이다.
*/ [인상깊은구절] 데이브 웅가(Dave Ungar)는 이걸 샤워 방법론이라고 부른다. 뭘 해야 할지 모르겠으면 샤워하러 가서 뭘 해야 할지 생각날 때까지 계속 샤워를 한다. 그의 방법론을 따른다면 많은 팀들이 더 행복해질 것이고 생산성도 향상될 것이며 냄새도 훨씬 덜 날 것이다. TDD는 웅가의 샤워 방법론을 정제한 것이다. 키보드로 뭘 쳐야 할지 알면, 명백한 구현을 한다. 잘 모르겠다면 가짜 구현을 한다. 올바른 설계가 명확하지 않다면 삼각측량 기법을 사용한다. 그래도 모르겠다면 샤워나 하러 가는 거다. |
| 프로그램을 짜는데 있어서 시스템을 개발하는 데 있어서 가장 좋은 방법은 무엇일까? 끊임없는 알고리즘 공부? 아니면 다양한 패턴의 습득? 사람들은 흔히 머리로 열심히 생각하고 하나 하나 함수를 구현하고 프로그램을 완성 한 후 어느정도 성과(?)가 있다고 생각될 때 테스트를 시작한다. 하지만 이 방법에 과감한 도전을 한 켄트 벡은 책 속에 사람을 감탄하게 만드는 이야기와 방식을 가득 채워 두었다. JUNIT이라는 테스트 도구로 하나 하나 테스트 해가면서 프로그램을 완성해 가는 모습은 감탄사를 끊임없이 연발하게 만든다. 쓸데 없는 나무를 잔뜩 성장시키고 하나 하나 가지치는 모습이 기존의 프로그래밍 방법이었다면 효율적으로 나무를 하나 하나 만들어 가는 모습이.. 마치 어린 나무일때부터 열심히 가지치기 하구 관리해서 딱 필요한 만큼만 키우는 모습이 이 경탄할만한 프로그래밍의 스킬이 아닌가 생각한다. 한번도 테스트 주도형 개발을 경험하지 않은 사람이라면 한번 쯤 그 세상에 빠져 보는 것은 어떨까? 하고 감히 추천해 본다. |
|
사실 이 책은 전부터 봐왔지만 사보진 않았던 책이다. JUnit 같은 테스트 툴에 대한 책인가 싶은 생각도 있었고 나름대로 테스트 모듈로 먼저 테스트를 하고 개발하는 습관을 들이고 있기 때문에 필요성을 느끼진 못했다. 간만에 아르바이트 좀 뛰고.. 여유가 좀 생겨서.. 이 책 저책 사면서.. 이 책도 또한 함 읽어볼까 해서 샀다. 책의 부피가 조금 얇아서..첨에 놀랬다. -_-;;; 책의 진행 방향은 좀 흥미로웠다. 정말로 테스트 주도 개발을 위해 하나의 토픽을 놓고 그에 따라 테스트 모듈을 만들어 가는 과정을 다루고 있었다. 테스트 개발에 있어서 어떤 정해진 룰과 규칙을 가지고 하나하나 만들어 가면서 그에 따라 결과물에 대해 리팩토링도 하고 패턴 적용도 하고 하는 부분들이 흥미로웠다. 이 책또한 한번쯤 읽어보면서 이 책에서 다루는 그러한 과정을 습관화 시킨다면 많은 향상이 있지 않을까 싶다. 다만...우리나라와 같이 빨리빨리 를 강조하는 곳에서 그러한 과정을 습관화 시킬 마음의 여유를 가질수 있을지가..조금은 의문이지만 -_-; 마음의 여유를 가지게 되고 습관화시킨다면..일반적으로 버그에 둘러쌓여서.. 무조건 빨리만 개발하려는 것보단.. 퍼포먼스가 확실히 날거 같긴 한데.... |
|
TDD, 처음에는 한 개발자의 객기라고 생각했다. 프로그래밍에 앞서서 테스트를 먼저 만들라니, 이게 말이 되는 소리인가.
근데, 이거 물건이다. 클래스를 만들다보면 이 기능 저 기능 필요 이상 더 많이 넣게 되는데, 나중에는 복잡해져서 깔끔한 구조의 클래스를 얻기가 힘들어 진다.
TDD의 위력은 바로 클래스를 어떻게 사용할 것인가를 먼저 결정하는데 있다. 방식은 테스트 주도이지만, 테스트를 주도하기 위해 은연 중에 클래스의 디자인을 먼저 결정하게 된다.
클래스를 어떻게 사용하고 테스트에 이용할 것인가가 결정나게 되면, 클래스의 디자인이 얻어지게 되고, 이를 따라 프로그래밍하면 군더더기 없는 깔끔한 구조의 클래스를 얻을 수 있다.
나중을 위해 더 많은 내용을 넣을 수도 있지만, 그건 그 때 가서 리팩토링하면서 할 일이다. 테스트 세트가 이미 마련되어 있기 때문에 리팩토링도 안심하면서 할 수 있다. 물론 테스트를 추가하면서.
이제 시작한 하수에 불과하지만, 경험과 함께 자라갈 좋은 도구를 얻은 것 같다. |