썰렁한 엔지니어

외부로 노출되는 것과 그렇지 않은 것이 무엇인가? 답은 간단하다. C/C++에서는 static이 붙지 않은 모든 변수와 함수는 외부로 노출된다. 이 말은 늘 이름공간(Name space)을 더럽힌다라는 말과 같이 나오게되는데, 이 개념은 만병의 근원처럼 초보 프로그래머들에게는 쉽게 드러나지 않는 개념으로 생각된다. 그닥 중요하지 않게 취급될 수도 있고, 다른 말로도 설명이 되기 때문이다. 이름공간이라는 것이 무엇인가? 무엇에 대한 이름공간인가? 말 그대로 생각해보면, 이름이 놓여지는 공간을 말하고, 이름이란 서로 다른 두 개를 구별하기 위해 사용되는 일종의 약속이다. 모듈화 프로그램이라는 것은 하나의 프로그램을 수행하기 위해 여러 단위로 나누어 각각을 부분 컴파일한 뒤 링크할 때, 필요로 하는 모듈과 제..

테스트를 위한다면, 정말 피해야 할 것이 테스트들 간의 의존성이다. 테스트들 간의 간섭이 최소화 되려면, 테스트할 대상들의 구분이 명확해야한다. 그럴려면, 함수 안에 여러기능들이 모여 있어서는 아니 될 일이다. 내가 말하고자하는 것은 두 개 이상의 함수에서 몇 줄 동일한 루틴이 발견된다고 해서 무조건 빼어 하나의 함수를 만들라는 것이 아니다. 물론 그렇게 하는 것은 중요한 습관 중의 하나이다. 습관적으로 길어지는 함수는 분명 처음부터 그렇게 만들고 싶어서 그런 것이 아니다. 생각이 있었다면 미리 함수들을 쪼개었을 것이 분명하다. 문제는 간단한 기능을 만들고 간단한 테스트를 한 다음 그 다음 코드를 그 함수에 덧붙여서 만들게 되는 습관때문이다. 왜냐하면, 하나의 함수안에서 기능을 추가해야할 때, 다른 함수..

연재하는 이 글들은 테스터를 위한 글이 아니라 개발자를 위한 것이며, 개발자가 어떻게 하면 테스트하면서 개발할 수 있을지에 대한 제안이다. 복사해서 쓰는 습관은 아주 초보적인 습관이지만, 가장 충동적인 습관이기도하다. 인류가 태어난 이후로 모방이라는 훌륭한 학습도구는 생활 전체에 아주 깊숙이 스며있는 것이기 때문에, 우리는 너무나 자연스럽게 가져다 쓰는 것에 익숙하다. 복사는 다른 사람 코드를 복사하는 것에서부터, 자신이 과거에 작성한 코드 그대로 복사에서 뿐아니라, 변수명이나 함수명을 바꿔서 복사 또는 기능을 추가하는 복사등, 그 변종도 아주 많다. 이 습관을 버리라고하는 이유의 핵심에는 "관리"에 있다. 혼자 연습하면서는 다른 사람의 것을 복사하는 것부터 시작하게된다. 그렇게 해야만 늘게되는 것은 자..

모듈화에 대한 개념은 초창기 분할 컴파일에서부터 시작하여, 동적 라이브러리, 나아가 플러그인, 자동화 객체와 같은 고급기능까지 비슷한 개념에서 출발하여 찬란한 꽃을 피운(?) 분야이다. 어떻게 모듈에 들어가는 함수들을 선택해야할까, 즉 어떤 함수들을 외부에서 사용하게 만들까. 그것에 대한 기준을 테스트 관점에서 바라보면 다음과 같다. 1. 외부로 노출된 함수들은 모두 테스트한다. 2. 모듈은 관련있는 기능(함수)들만을 모아 놓아야 한다. 테스트하지 않을 함수들은 모두 file scope을 가지게한다. 즉 C 언어로 말하면, static 한정자를 붙여서 외부에서 참조가능하지 않게한다. 왜 이것이 중요하냐면, 외부에서 전혀 사용하지 않는 것들이 외부로 노출될 경우 함수이름 공간에 불필요한 것이 들어가게 되고..

경험을 위주로 작성하는 것이므로 많이 보는 텍스트에서 강조하는 것을 간과할 수도있고, 없는 것도 있을 수 있는 글이 될 것 같다. 테스트 주도형 개발의 가장 기본적인 개념은 테스트 코드를 먼저 작성하고 그 코드가 돌아 갈 수 있는 함수를 만든다는 것이다. 이것만으로도 기존의 습관을 버릴 수 있는 생각의 사유가 되나 전통적인 방식(설계->구현->테스트)의 개발에 익숙한 사람이 쉽사리 옮겨가지 못하는 것은 시간에 대한 두려움이 있기 때문이다. 누구나 다 아는 사실은 테스트 코드를 먼저 작성하여 버그를 줄이는 것이 오히려 전체 시간을 줄일 수 있다는 것인데 그것은 습관적으로 진행되는 것에 의한 관성이 너무도 크기 때문에 쉽게 체득되지 않는 다. 완벽히 XP 방식의 테스트 주도형 개발을 진행하는 것이 어렵다면 ..

Test driven development 또는 Test driven programming 에 대한 내 의견은 다음과 같다. 테스트가 개발을 주도하기 위해서는 습관을 고쳐야한다. 적어도 테스트 주도형 개발의 참뜻을 알기 위해서는 개발후 모듈테스트 통합테스트, 인수테스트에 대한 과정을 수도없이 퇴짜 맞아봐야 알게 된다. 결코 테스트의 중요성은 종이위의 활자로서 얻어질 수 있는 지식이 아닌것 같다. 만일 이 글을 읽는 사람중에 그런 경험이 없다면 중요성에 대한 이해도가 덜하리라 생각된다. 모듈테스트와 통합테스트가 설계/구현다음에 일어나는 일이라 생각되기 때문에 우리는 테스트할 시간 없이 완성했다고 생각한다. 또한 혼자 개발하는 시절에는 테스트보다는 설계 구현이 더 중요시되고 그러한 사람들이 한 팀을 이루어 ..

이번에도 지난번 글과 같이 간단한 함수의 디스어셈블을 통하여 함수호출시에 일어나는 일들을 살펴보고자 한다. 참고로 이와 같은 학문(?)의 범주는 다음과 같은 위치에 있다. * C 언어 표준 스펙 * intel x86 CPU의 System V Application Binary Interface * gcc의 구현 System V ABI 를 검색어로 찾아 보면 원하는 글을 찾을 수 있을 것이다. void func6( char x1, char x2, char x3) { x1 = 1; x2 = 2; x3 = 3; } struct _p { int a1; int a2; int a3; }; void func7( struct _p p1, int p2 ) { p1.a1 = 1; p1.a2 = 2; p1.a3 = 3; p2..

C 언어는 전통적으로 다음과 같은 방식으로 실행파일이 만들어진다. (1) 편집기를 통한 소스 작성 (2) 전처리기를 통해 소스로부터 매크로 확장 및 주석 제거 (3) 컴파일러를 통해 전처리된 코드로부터 어셈블코드 생성 (4) 어셈블러를 통해 어셈블코드로부터 목적파일 생성 (5) 링커를 통해 목적파일들 (라이브러리 포함)의 결합에 의한 실행파일 생성 이 중에서 (3) 번과정을 재미로 살펴보면서 어떤일들이 일어나는지 알아보고자 한다. 테스트한 환경은 다음과 같다. * x86 CPU * gcc 3.3.2 테스트 코드는 다음과 같다. void func1() { } void func2( int x ) { x = 0; } int func3() { return 7; } void func4() { int y; y = ..

find 를 제법 잘 쓰는 사람은 다 아는 얘기일 것 같지만, 흔히들 사용하면서도 그 많은 옵션이 잘 안들어오는 사람들을 위해 정리하고자 글을 써본다. find의 철학은 그 이름에서 이미 감춰져 있다고 해도 과언이 아니다. find를 통해서 할 수 있는 것이 고작 원하는 이름의 혹은 원하는 속성을 가진 파일을 찾는 것이라 생각한다면 그것은 정말 누구나 사용할 줄 아는 방법으로서의 find 이다. find의 철학은 다음과 같다. 어디에 이런 글이 쓰여있는지는 나도 모르겠지만, 경험상 정리하자면, find 는 true/false에 의한 directory 탐색기이다. 신선한가? 우선 다들 그러하듯이 man find를 한번 수행해보고 true/false라는 말이 얼마나 나오는지 한 번 살펴보시라. 가능하면, 리..

하루에 한번씩 돌아가는 버그 어세신, 유닛 테스트는 업무중 한시간에 한 번씩 자동으로 수행하게 되어 있으며, 메일로 그 성공 여부가 전달된다. 그날의 담당자에게는 버그 어세신 푯말이 세워지고, 그날 발생하는 유닛 테스트의 버그 처리의 주 담당자가 된다. 좀더 자세히 보자 그러나.. 이렇게 하는 이유는 아무리 메일로 보고가 되어도, 메일을 자주 확인하지 않는자와, 다른 일에 치여 사는 자, 혼자 하기에 지쳐버린 자, 뭘 잘 모르는자로 구분되어서이다. 그리고 메일 한번씩 인스톨을 해보자스라. 이건 어제 선서했으므로, 지키겠지.