엄한소리

몇년동안이나 책장에 덩그러니 꽂혀만 있던 D&EC++을 드디어 다 읽었다. 대략적인 느낌은 왜 지금의 C++이 이모냥밖에 못되었나에 대한 변명..이랄까... 이런 느낌인데, 뭐, (스타게이트 아틀란티스의) 닥터 로드니의 말을 따오자면 "완벽한 세상에서는" 이모냥밖에 안되지 않았겠지. 하지만 우리 세상은 완벽하지 않잖아? 안될거야 아마. -_-a

책을 보면, 각각의 언어 스펙에 대한 변천사가 개략적으로 기술되는데, 일부는 현재의 솔루션이 확실히 진보했다는 느낌이 들고, 일부는 호환성이나 기술적, 관습적 한계 때문에 쉽고 우아하고 효율적인 솔루션을 포기했다는 면이 안타깝다는 느낌.

현재의 상태라서 더 낫다고 생각하는 한가지 예로는 비야네가 '상속을 통한 제약조건'이라고 이름붙인 항목에서 기술한 것이다. 이는 템플릿이 어떤 종류의 매개변수로 스페셜라이제이션 될 수 있는가를 명시할 필요성이 있지 않겠느냐는 논의에서 비롯된다. 템플릿 매개변수가 만족해야 하는 조건을 명시할 필요성은 나도 느끼는 바이고, C++0x의 concept 개념이 매우 마음에 들었지만, 현재 C++0x 표준에서는 떨어졌다고 하는 걸 보면 만족스러운 해결책은 아직도 요원하다. 그런데 이러한 논의는 C++의 템플릿 명세를 처음 만들면서도 했다는 점이다. 비야네의 동료들이 제안한 방안은 템플릿 선언시 매개변수 선언부에서 특정한 클래스에서 상속받은 타입들로만 스페셜라이제이션할 수 있음을 명시하면 어떻겠느냐는 것이다.
일견 타당해 보이기도 하지만, 비야네의 생각으로는 근본적으로 'T가 비교가능해야 한다'고 명시하는 대신에 'T가 Comparable에서 상속받아야 한다'라고 명시하는 것은 틀린 개념이라고 봤다고 한다. 여기엔 나 역시 동의한다. C++의 템플릿 매개변수가 저런 식으로 제약조건을 명시해야 했다면 활용도가 크게 떨어졌을 듯.

C++에서 빠져서 아쉬운 것중의 하나는, 비야네가 생각만 하고 있었다는 include 키워드(프리프로세서 명령이  아닌!).
#include 전처리기 명령은 매우 무식한 방법으로 작동하여, 스코프 룰을 완전히 무시하고, 순서의존성이 매우 크다. 윈도우에서 프로그래밍해본 사람이라면 std::max 템플릿을 쓰기 위해서는 windows.h 헤더에서 선언된 max 매크로를 요리조리 피해가야 했던 경험이 있을 것 같다. 비야네는 include라는 키워드를 도입하여 유일성을 자동으로 보장해주며,  include로 포함되는 헤더에서 선언된 매크로는 해당 헤더파일 안에서만 동작하고, 거꾸로 include로 포함된 헤더에서 선언되지 않은 매크로는 해당 헤더에서 동작하지 않도록 만들고 싶었다고 한다. 대략적으로 자바의 import와 비슷하게 동작할 수 있도록 만들고 싶었던 모냥. 이는 나도 적극 찬성인데, C++에 들어가지 못한 것은 매우 안타깝다.

책 전체에 걸쳐서 이건 이렇게 하려고 했었는데 이런이런 문제가 발생해서 결국 이렇게 되고야 말았다... 이런걸 구구절절하게 써놔서..... 난 무척 재미있었다. 아! 비야네도 불완전한 세상에 살수밖에 없는 엔지니어였구나. 흑_흑

비야네도 알고 있는, 인류에게 가장 도움이 되는 조언.

드디어 20000hit.

TDD는 코딩 전에 테스트를 정의하는 방법론이다. TDD가 말하는 바는, 작성하는 코드가 어떻게 동작하여야 하는지를 정의하고, 이 정의에 부합하도록 동작하는지, 그리고 이 정의에 부합하지 않는 쪽으로 동작하지 않는지를 검증하는 코드를 먼저 짜야 한다는 것이다. 내가 지금까지 코딩해왔던 방식이랑 비교하자면, 난 일단 특정 모듈의 행동양식을 정의하고, 사용처에서 사용하고자 하는 방식을 적어놓고 컴파일해본다. 컴파일 에러가 모두 사라지고 구현하면 동작하는 코드가 나오는 방식.
의식의 흐름 기법으로 정리해 보면.

1. "파일에서 뭘 하나 읽어와야겠군"
   
   int XXX::open_file( const string& filename )
   {
   }
2. "그럼 스트림을 추상화해야겠군"
   
   int XXX::open_file( const string& filename )
   {
       stream file( filename );
       file.read( this->buffer, this->size );
   }
   
3. "컴파일 에러로군"
   
   class stream
   {
   public:
       stream( const string& name );
       int read( void* buffer, size_t size );
   };
   
   int XXX::open_file( const string& name )
   {
       stream file( name );
       return file.read( this->buffer, this->size );
   }
4. "구현을 해야겠지?"
   
   class stream
   {
   public:
       stream( const string& name );
       int read( void* buffer, size_t size );
   };
   
   int XXX::open_file( const string& name )
   {
       stream file( name );
       return file.read( this->buffer, this->size );
   }
   
   stream::stream( const string& name )
   {
       // ...................
   }
   int stream::read( void* buffer, size_t size )
   {
       // ...................
   }
5. "파일이 제대로 열리나?"
   
   class stream
   {
   public:
       stream( const string& name );
       int read( void* buffer, size_t size );
   };
   
   int XXX::open_file( const string& name )
   {
       stream file( name );
       return file.read( this->buffer, this->size );
   }
   
   stream::stream( const string& name )
   {
       // ...................
   }
   int stream::read( void* buffer, size_t size )
   {
       // ...................
   }
   
   int main()
   {
       // ...................
       XXX x;
       int result = x.open_file( ",,,,,,,,,,,,,,,," );
       assert( result != ERROR );
       assert( memcmp( x.buffer, dummy ) == 0 );
   }
6. "버그 잡자"

내가 코딩하는 방식과 TDD에서 제시하는 방식의 차이는, 바라는 동작을 정의하는 부분이 워킹 코드이냐 테스트용 코드이냐 하는 점이다. 지금 내 방식의 단점은, 코드가 바뀌고 나면 동작의 일관성이 깨져도 그걸 체크할 방법이 바뀐 코드와 함께 유실돼 버린다는 것. TDD의 유용성이 느껴지는 부분이다.

TDD의 방법론은 실천 지침이 명확하다는 점에서 유용한 듯 하다. "코드보다 테스트코드 먼저". 이 얼마나 간단 명료한 지침인가. 내 생각으로는, 이 간단한 지침에 숨겨진 효용은 대충 이런 것 같다. 테스트를 작성하기 위해서는 내가 쓰고자 하는 코드가 어떤 식으로 동작해야 하는지를 정의해야 한다. 동작을 정의하기 위해서는 설계를 머리 속에 담고 있어야 하고, 이는 결국 코딩하기 전에 생각하라-는 오래된 금언을 실천하기 위한 매우 유용한 방법론인 것이다.
생각해 보면, 코딩하기 전에 생각하는 것이 습관화된 사람에게 TDD는 별달리 임팩트를 주진 않을 것 같다. TDD의 사용자에게 작용하는 궁극적이고 장기적인 영향은 코딩하기 전에 생각하는 습관을 들이게 하는 거라는 점에서 그렇다. (TDD의 다른 장점은 프로젝트에 작용하는 장점이지, 사람에게 작용하는 장점이 아니다) 하지만 그럼에도 장점은 있는데, 일단 남들에게 가르치기 쉽고, 또한 각 단계가 매우 짧고 보상이 정확하기 때문에 마치 게임을 하는 것처럼 코딩을 할 수 있다는 거다. "만렙까지 알아서 레벨 올리세요"와 "남쪽골짜기에서 토끼를 잡으면 레벨이 하나 올라요"의 차이랄까. 나에게 TDD란, 프로그래밍이란 게임의 규칙이란 느낌. 한 단계씩 레벨 올려서 만렙이 되면 프로그램이 완성되는 게임.