'테스트 주도 개발' 책에서 또 관심을 끌었던 부분입니다. 마치는 글을 마틴
파울러가 장식을 했군요.
그 부분도 올려봅니다.
이 글은 실제로 TDD를 하면서 나타나는 일에 대한 집중도에 관해서 설명을
하고 있습니다. 저도 TDD를 쓰며 개발하면서 느끼는 것은 역시 일에 대한
집중도에 놀랐었는데, 마틴 파울러가 이 부분을 잘 지적을 하고 있는듯 합니다.
파울러가 장식을 했군요.
그 부분도 올려봅니다.
테스트 주도 개발에 대해 설명하기 어려운 것 중 하나는 TDD를 하면
돌입하게 되는 정신상태다. C3 프로젝트에서 랄프 베티(Ralph Beattie)와
함께 했던 세션을 기억한다. 우리는 복잡한 지불 조건을 구현해야만
했다. 랄프는 그걸 여러 개의 테스트 케이스로 쪼갰고, 우리는 그것들이
작동하도록 하나씩 접근했다. 꾸준히 서두르지 않으면서
진행했다. 서두르지 않았기 때문에 느린 것처럼 보였지만, 얼마나 많은
일을 했는지 뒤돌아 보면 , 작업시의 느긋한 느낌에도 불구하고 진행
속도는 매우 빨랐다.
우리가 가진 화려한 도구들에도 불구하고, 프로그래밍은 여전히
어렵다. 동시에 여러 개의 공을 공중에 띄워놓고 저글링할 때처럼 ,
프로그래밍할 때도 잠시만 집중을 놓치면 모든 게 무너져 버릴 것 같은
느낌을 받은 적이 많다. 테스트 주도 개발은 이런 느낌을 감소시키는 데
도움이 되고, 그 결과로 신속한 느긋함을 얻게 된다.
그렇게 생각하는 이유는, 테스트 주도 개발 스타일로 작업하면 한 번에
딱 하나의 공만 공중에 띄우는 느낌이 들고, 그렇기 때문에 그 공에
충분히 집중할 수 있고 그 일을 정말 훌륭히 해낼 수 있다는
것이다. 나는 새로운 기능을 추가하려고 할 때, 이 함수에는 정말 어떤
설계가 좋을지 고민하지 않고 , 할 수 있는 한 가장 쉽게 테스트를
통과시키려고만 노력한다. 리팩토링 모드로 바뀌면 새로운 기능을
추가하는 것에 신경 쓰지 않고, 올바른 설계를 얻는 데만 신경 쓴다. 이
양자를 통해 한 번에 딱 하나에만 집중하게 되고, 그 결과 그 한 가지에
대해 더 잘 집중할 수 있다.
테스트 우선으로 기능을 추가하는 것과 리팩토링은 프로그래밍의 두 가지
단일사고적 특색이다. 최근 키보드를 두드리다가 또 다른 하나를 경험하게
됐다. 그것은 패턴 복사하기다. 데이터베이스에서 어떤 데이터를 가져오는
작은 루비 스크립트를 작성하고 있었다. 이 일을 하면서 데이터베이스
테이블을 감싸는(wrap) 클래스에 대해 작업을 시작했다. 그때 데이터베이스
패턴 책을 한 권 끝냈기 때문에 패턴을 하나 사용해야 한다는 생각이
들었다. 예제 코드는 자바였지만, 그걸 루비에 적용하는 건 어렵지
않았다. 프로그래밍하면서 문제에 대해서는 별로 생각하지 않고, 그 패턴을
현재 언어와 내가 다루던 특정 자료에 어떻게 멋지게 적용할까에 대해
생각했다.
패턴 복사하기 자체는 훌륭한 프로그래밍이 아니다. 이 사실은 내가 패턴에
대해 이야기 할 때면 늘 강조한다. 패턴은 언제나 반숙 상태며, 자신의
프로젝트 오븐 속에서 적응시켜야 한다. 하지만 이렇게 하기 위한 좋은 방법
중 하나는 일단 무턱대고 패턴을 복사하고 나서, 리팩토링과 테스트 우선을
섞어 사용해서 그 적응과정을 수행하는 것이다. 패턴 복사를 할 때 이렇게
하면 해당 패턴에 대해서만 집중할 수 있게 된다(한번에 하나씩).
XP 커뮤니티는 전체 그림에서 패턴이 어디에 위치해야 하는지 고심해
왔다. XP 주창자와 패턴 주창자들 사이에는 상당히 큰 일치점이 있기 때문에
(워드와 켄트는 두 분야 모두 리더다) XP 커뮤니티는 분명 패턴을
좋아한다고 볼 수 있다. 테스트 우선과 리팩토링이 그 자체로는 위험하지만
함께 하면 강력한 것처럼, 패턴 복사는 그 둘과 함께 가야 할 세 번째 단일
사고적 모드일지도 모르겠다.
핵심 작업을 분간하고 한 번에 딱 하나만 집중하도록 하는 것이 어떤
활동을 체계화하는 데 주요한 역할을 한다. 조립 라인은 이런 예 중 정신을
멍하게 하는 예가 된다. 언제나 정해진 한 가지만 하기 때문이다. 아마
테스트 주도 개발이 제안하는 것은 프로그래밍의 행위를 여러 기본적 모드로
나누되, 그런 모드를 재빨리 전환해 가면서 단조로움을 피하는 것이지
않을까, 단일사고적 모드들과 전환의 조합을 통해 집중의 이득을 얻을 수
있고, 조립 라인의 단조로움 없이 뇌에 가해지는 스트레스를 낮출 수
있다.
이 생각들이 다소 미숙하다는 것을 인정한다. 이 글을 쓰면서도 여전히
내가 하는 말을 스스로 믿는지 확신하지 못하고, 이 생각들을 몇 개월,
아니 꽤 오랫동안 고민할 것이라는 걸 안다. 하지만 어쨌거나, 테스트 우선
개발이 속하는 더 큰 그림에 대한 생각을 자극하기 때문에 독자가 내
아이디어를 좋아하지 않을까 하는 생각을 했다. 아직 우리가 분명히 볼 수
있는 그림은 아니지만 서서히 자신을 드러내고 있는 그림이라고 생각한다.
돌입하게 되는 정신상태다. C3 프로젝트에서 랄프 베티(Ralph Beattie)와
함께 했던 세션을 기억한다. 우리는 복잡한 지불 조건을 구현해야만
했다. 랄프는 그걸 여러 개의 테스트 케이스로 쪼갰고, 우리는 그것들이
작동하도록 하나씩 접근했다. 꾸준히 서두르지 않으면서
진행했다. 서두르지 않았기 때문에 느린 것처럼 보였지만, 얼마나 많은
일을 했는지 뒤돌아 보면 , 작업시의 느긋한 느낌에도 불구하고 진행
속도는 매우 빨랐다.
우리가 가진 화려한 도구들에도 불구하고, 프로그래밍은 여전히
어렵다. 동시에 여러 개의 공을 공중에 띄워놓고 저글링할 때처럼 ,
프로그래밍할 때도 잠시만 집중을 놓치면 모든 게 무너져 버릴 것 같은
느낌을 받은 적이 많다. 테스트 주도 개발은 이런 느낌을 감소시키는 데
도움이 되고, 그 결과로 신속한 느긋함을 얻게 된다.
그렇게 생각하는 이유는, 테스트 주도 개발 스타일로 작업하면 한 번에
딱 하나의 공만 공중에 띄우는 느낌이 들고, 그렇기 때문에 그 공에
충분히 집중할 수 있고 그 일을 정말 훌륭히 해낼 수 있다는
것이다. 나는 새로운 기능을 추가하려고 할 때, 이 함수에는 정말 어떤
설계가 좋을지 고민하지 않고 , 할 수 있는 한 가장 쉽게 테스트를
통과시키려고만 노력한다. 리팩토링 모드로 바뀌면 새로운 기능을
추가하는 것에 신경 쓰지 않고, 올바른 설계를 얻는 데만 신경 쓴다. 이
양자를 통해 한 번에 딱 하나에만 집중하게 되고, 그 결과 그 한 가지에
대해 더 잘 집중할 수 있다.
테스트 우선으로 기능을 추가하는 것과 리팩토링은 프로그래밍의 두 가지
단일사고적 특색이다. 최근 키보드를 두드리다가 또 다른 하나를 경험하게
됐다. 그것은 패턴 복사하기다. 데이터베이스에서 어떤 데이터를 가져오는
작은 루비 스크립트를 작성하고 있었다. 이 일을 하면서 데이터베이스
테이블을 감싸는(wrap) 클래스에 대해 작업을 시작했다. 그때 데이터베이스
패턴 책을 한 권 끝냈기 때문에 패턴을 하나 사용해야 한다는 생각이
들었다. 예제 코드는 자바였지만, 그걸 루비에 적용하는 건 어렵지
않았다. 프로그래밍하면서 문제에 대해서는 별로 생각하지 않고, 그 패턴을
현재 언어와 내가 다루던 특정 자료에 어떻게 멋지게 적용할까에 대해
생각했다.
패턴 복사하기 자체는 훌륭한 프로그래밍이 아니다. 이 사실은 내가 패턴에
대해 이야기 할 때면 늘 강조한다. 패턴은 언제나 반숙 상태며, 자신의
프로젝트 오븐 속에서 적응시켜야 한다. 하지만 이렇게 하기 위한 좋은 방법
중 하나는 일단 무턱대고 패턴을 복사하고 나서, 리팩토링과 테스트 우선을
섞어 사용해서 그 적응과정을 수행하는 것이다. 패턴 복사를 할 때 이렇게
하면 해당 패턴에 대해서만 집중할 수 있게 된다(한번에 하나씩).
XP 커뮤니티는 전체 그림에서 패턴이 어디에 위치해야 하는지 고심해
왔다. XP 주창자와 패턴 주창자들 사이에는 상당히 큰 일치점이 있기 때문에
(워드와 켄트는 두 분야 모두 리더다) XP 커뮤니티는 분명 패턴을
좋아한다고 볼 수 있다. 테스트 우선과 리팩토링이 그 자체로는 위험하지만
함께 하면 강력한 것처럼, 패턴 복사는 그 둘과 함께 가야 할 세 번째 단일
사고적 모드일지도 모르겠다.
핵심 작업을 분간하고 한 번에 딱 하나만 집중하도록 하는 것이 어떤
활동을 체계화하는 데 주요한 역할을 한다. 조립 라인은 이런 예 중 정신을
멍하게 하는 예가 된다. 언제나 정해진 한 가지만 하기 때문이다. 아마
테스트 주도 개발이 제안하는 것은 프로그래밍의 행위를 여러 기본적 모드로
나누되, 그런 모드를 재빨리 전환해 가면서 단조로움을 피하는 것이지
않을까, 단일사고적 모드들과 전환의 조합을 통해 집중의 이득을 얻을 수
있고, 조립 라인의 단조로움 없이 뇌에 가해지는 스트레스를 낮출 수
있다.
이 생각들이 다소 미숙하다는 것을 인정한다. 이 글을 쓰면서도 여전히
내가 하는 말을 스스로 믿는지 확신하지 못하고, 이 생각들을 몇 개월,
아니 꽤 오랫동안 고민할 것이라는 걸 안다. 하지만 어쨌거나, 테스트 우선
개발이 속하는 더 큰 그림에 대한 생각을 자극하기 때문에 독자가 내
아이디어를 좋아하지 않을까 하는 생각을 했다. 아직 우리가 분명히 볼 수
있는 그림은 아니지만 서서히 자신을 드러내고 있는 그림이라고 생각한다.
이 글은 실제로 TDD를 하면서 나타나는 일에 대한 집중도에 관해서 설명을
하고 있습니다. 저도 TDD를 쓰며 개발하면서 느끼는 것은 역시 일에 대한
집중도에 놀랐었는데, 마틴 파울러가 이 부분을 잘 지적을 하고 있는듯 합니다.
