Peter Norvig 이 생각하는 TDD

최근 출퇴근 길에 “Coders at Work”의 eBook을 읽고 있다. 거의 내 맘대로 순서를 정해서 보고있는데, 오늘 출근 길에 읽은 Peter Norvig¹의 인터뷰 중에, 어떻게 프로그램을 짜는게 좋은가에 관한게 나온다.

이 이하의 인용은 Norvig 이 인터뷰한 내용. 모든 저작권은 Seibel 및 출판사에 있다.

Norvig: I thik one of the most important things is being able to keep everythin in your head at once. If you can do that you have a much better chance of being successful. That makes a small program easier. For a bigger problem, you need extra tools to be able to handle that. It’s also import to know what you’re doing. When I wrote my Sudoku solver, some bloggers commented on that. They said, “Look at the contrast – here’s Norvig’s Sudoku thing and then there’s this other guy, whose name I’ve fogottent, one of these test-driven design gurus. He starts off and he says, “Well, I’m going to do Sudoku and I’m going to have this class and first thing I’m going to do is write a bunch of tests.” But then he never got anywhere. Hehad five different blog posts and in each on he wrote a little bit more and wrote lots of tests but he never got anything working because he didn’t know how to solve problem.

한 TDD 구루와 자신이 작성한 수도쿠 솔버를 가지고 벌어진 논쟁에 대한 언급.² 피터 노빅이 보기에 가장 중요한 것은 모든 것을 한 번에 머릿속에서 굴리는 것, 그리고 자신이 뭘 하고 있는지를 아는 것. 그래서 TDD 가 도구가 아니라 목적이 되면 – 즉 테스트에 너무 집착하면 – 정작 해야하는 일, 문제 풀이에 집중하지 않게 되고 원하는 결과를 얻지 못할 수도 있다는 것.

물론 TDD 자체에 대한 반감은 아니라고 언급한다.

Then bloggers were arguing back and forth about what this means. I don’t think it means much of anything – I think test-driven design is great. I do that a lot more than I used to do. But you can test all you want and** if you don’t know how to approach the problem, you’re not going to get a solution**.

내 생각에도, 모든 소프트웨어 공학툴이 어떤 은탄환이 아니듯, TDD 역시 하나의 도구일 뿐이다. 도구가 강력하다고 모든 문제를 해결해주는 것이 아니니, 결국 우리가 해야하는 일은 “문제를 풀 수 있도록 자신을 갈고 닦는 일도 병행”하는 수 밖에 없다. 즉, 좋은 도구니까 잘 쓰면 좋을게다. 여기에 집착만 하지 않으면…

PS. Coders at work를 읽고나서 나랑 비슷한 글을 쓴 사람들이 꽤 있다.