프로그래밍로그

1. 단위 테스트를 링크하기 위한 명령어가 테스트 프로그램 자체보다 긴 대규모 C 혹은 C++ 프로젝트

2. 한 모듈의 '간단한' 수정이 이와 관계없는 모듈을 통해 시스템 전역에 퍼져나가는 경우

3. 개발자가 수정한 부분이 시스템에 어떤 영향을 미칠지 몰라 코드의 수정을 두려워 하는 경우

 

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

예외를 지원하는 언어는 리소스 해제에 복잡한 문제가 있을 수 있다. 예외가 던져진 경우, 그 예외 이전에 할당 된 모든 것이 깨끗이 청소된다고 어떻게 보장 할 수 있겠는가?


C++에서 예외와 리소스 사용의 균형

C++은 try...catch 예외 메커니즘을 지원한다. 불행하게도, 이 말은 예외를 잡은 다음 다시 던지는 루틴에서는 언제나 그 루틴에서 나가는 경로가 최소한 두 개는 존재한다는 얘기다.

void doSomething(void) {
    Node* n = new Node;
    try {
        // Do something
    } catch(...) {
        delete n;
        throw;
    }
    delete n;
}

우리가 생성한 노드가 해제되는 장소가 두 군데라는 점을 눈여겨보라. 하나는 루틴이 정상적으로 나가는 경로에 있고, 다른 하나는 예외처리 장소에 있다. 이것은 명백한 Don't repeat yourself 원칙 위반이며, 언제 터질지 모르는 유지보수 문제이기도 하다.

하지만 우리는 C++의 작동방식을 이용 할 수 있다. local 객체들은 자기를 둘러싼 블록에서 나갈 때 자동으로 파괴된다. 이것 덕분에 몇 가지 방법이 생긴다. 만약 상황이 허락한다면, 'n'을 포인터에서 스택에 놓이는 실제 Node 객체로 바꾸면 된다.

void doSomething(void) {
    Node n;
    try {
        // Do something
    } catch(...) {
        throw;
    }
}

이렇게 되면 예외가 생기든 그렇지 않든 Node 객체의 자동 파괴를 C++에게 맡길 수 있다.

포인터에서 다른 것으로 바꾸는 일이 불가능 하다면, 리소스를 다른 클래스로 감싸면 동일한 효과를 볼 수 있다.

class NodeResource {
    Node* n;
public:
    NodeResource() { n = new Node; }
    ~NodeResource() { delete n; }
    Node* operator->() { return n; }
};

void doSomething(void) {
    NodeResource n;
    try {
        // Do something
    } catch(...) {
        throw;
    }
}

이제 wrapper 클래스 NodeResource가 자신의 객체들이 파괴 될 때 관련 노드들 역시 파괴되도록 하는 일을 확실히 해준다. 편의성을 위해, wrapper 클래스는 -> 연산자도 제공해서 사용자가 Node 객체에 들어있는 필드에 바로 접근 할 수 있게 해준다.
이 기법이 너무나도 유용하기 때문에, 표준 C++ 라이브러리에도 동적으로 할당 된 객체들의 자동 wrapper를 제공하는 템플릿 클래스 auto_ptr이 있다.

void doSomething(void) {
    auto_ptr p (new Node);
    try {
        // Do something
    } catch(...) {
        throw;
    }
}


자바에서 리소스 사용의 균형

public void doSomething() throws IOException {
    File tmpFile = new File(tmpFileName);
    FileWriter tmp = new FileWriter(tmpFile);
    try {
        // Do something
    } catch(...) {
        // Do something
    } finally {
        tmpFile.delete();
    }
}

이 루틴에서 사용하는 임시파일은 루틴에서 어떻게 나가든 지워야 한다. Finally 블록이 우리가 뜻하는 바를 이렇게 간결하게 표현 해 준다.

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

 

리소스를 할당한 순서의 반대로 해제하라. 이렇게 해야 한 리소스가 다른 리소스를 참조하는 경우에도 리소스를 고아로 만들지 않는다.

코드의 여러 곳에서 동일한 리소스 집합을 할당하는 경우, 할당 순서를 언제나 같게 하라. deadlock 가능성이 줄어들 것이다. (프로세스 B가 리소스2를 이미 확보하고서 리소스1을 획득하려고 하고 있는데 프로세스 A가 리소스1을 가진 상태로 리소스2를 요청하려고 한다면, 이 두개의 프로세스는 영원히 기다리게 될 것이다.)

어떤 종류의 리소스를 사용하고 있는지는 중요하지 않다. 트랜잭션이나 메모리이건, 파일 혹은 쓰레드, 윈도우이건 모두 기본 패턴이 적용된다. 리소스를 할당하는 것이 누구이든, 그 리소스를 해제할 책임까지 져야 한다.

 

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

예외가 있다는 것은 즉 컨트롤의 이동이 즉각적이고 로컬하지 않다는 것을 말한다. 일종의 연쇄 goto 같은 것이다. 예외를 정상적인 처리 과정의 일부로 사용하는 프로그램은 고전적인 스파게티 코드의 가독성 문제와 관리성 문제를 전부 떠안게 된다. 이런 프로그램은 캡슐화 역시 깨트린다. 예외 처리를 통해 루틴과 그 호출자들 사이의 결합도가 높아져 버린다.

에러 처리기는 또 다른 대안이다

에러 처리기는 에러가 감지되었을 때 호출되는 루틴이다. 특정 부류의 에러를 처리하기 위해 어떤 루틴을 등록하게 된다. 해당하는 에러가 났을 때 그 처리기가 호출 될 것이다.

자바의 RMI 기능을 사용하는 클라이언트 서버 애플리케이션을 구현한다고 생각 해 보라. RMI가 구현 된 방식 때문에, 원격 루틴을 호출 할 때마다 RemoteException을 처리할 준비가 되어있어야 한다. 문제는 이런 예외를 처리하기 위해 코드를 추가하는 것은 지겨운 일이며, 로컬과 리모트 루틴 모두에서 작동하는 코드를 작성하기가 어렵다는 것이다. 한 가지 가능한 우회로는 원격이 아닌 클래스로 원격 객체를 wrapping 하는 것이다. 그러면 이 클래스는 에러 처리기 인터페이스를 구현하며, 원격 예외가 감지되었을 때 호출 될 루틴을 클라이언트 코드가 등록하도록 한다.
 

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

프로그래밍을 하다보면 '그런 일은 절대 일어날 리 없어'라는 사고에 빠지기 쉽다. 우리 중 대다수는 파일이 성공적으로 닫혔는지, 혹은 트레이스문이 우리가 예상한 대로 찍히는지 확인하지 않는 코드를 작성한 경험이 있다. 그리고 다른 모든 조건이 동일하다면, 그럴 필요가 없었을지도 모른다. 문제의 코드는 정상 조건 하에서는 실패하지 않았을 것이다. 하지만 우리는 지금 방어적으로 코딩하고 있다.

모든 에러는  정보를 준다. 여러분은 에러가 발생할 리 없다고 스스로를 설득하고선 그걸 무시하기로 할 수 있다. 반면에 실용주의 프로그래머는 만약 에러가 있다면 정말로 뭔가 나쁜 일이 생긴 것이라고 자신에게 이야기한다.

<실용주의 프로그래머 팁>
일찍 작동을 멈추게 하라

망치지 말고 멈추라

가능한 한 빨리 문제를 발견하게 되면, 좀 더 일찍 시스템을 멈출 수 있다는 이득이 있다. 게다가 프로그램을 멈추는 것이 할 수 있는 최선일 때가 많다.

자바 언어와 라이브러리는 이 철학을 포용했다. 런타임 시스템에서 뭔가 예상하지 못한 것이 발생하면 RuntimeException을 던진다. 만약 이 예외가 catch되지 않으면 프로그램의 최상위 수준까지 스며 나올 것이고, 결국 스택 트레이스를 출력하며 프로그램을 멈춰버릴 것이다.

다른 언어에서도 똑같이 할 수 있다. 예외 처리가 지원되지 않거나 라이브러리가 예외를 던지지 않으면, 여러분 자신이 직접 에러를 처리해야 한다. C에서는 매크로가 이 작업에 매우 유용할 것이다.

#define CHECK(LINE, EXPECTED) \
    { int rc = LINE; \
    if (rc != EXPECTED) \
        ut_abort(__FILE__, __LINE__, #LINE, rc, EXPECTED); }

void ut_abort(char* file, int ln, char* line, int rc, int exp) {
    fprintf(stderr, "%s line %d\n'%s': expected %d, got %d\n",
        file, ln, line, exp, rc);
    exit(1);
}

그러면 다음을 사용해서 결코 실패하면 안 되는 호출을 감쌀 수 있다.

check(stat("/tmp", &stat_buff), 0);

만약 실패한다면, stderr에 다음과 같은 메시지가 출력될 것이다.

source.c line 19
'stat("/tmp", &stat_buff)': expected 0, got -1

분명히 실행 중인 프로그램을 그냥 종료해 버리는 것은 때로 적절치 못하다. 해제되지 않은 자원이 남아 있을 수도 있고, 로그 메시지를 기록 할 필요가 있을 수도 있고, 열려있는 트랜잭션을 청소해야 하거나, 다른 프로세스들과 상호작용해야 할 필요가 있을지도 모른다. 그렇지만 기본 원칙은 똑같다. 방금 불가능한 뭔가가 발생했다는 것을 코드가 발견한다면, 프로그램은 더 이상 유효하지 않다고 할 수 있다. 이 시점 이후로 하는 일은 모두 수상쩍은 게 된다. 되도록 프로그램을 빨리 종료해야 할 일이다. 일반적으로, 죽은 프로그램이 입히는 피해는 절름발이 프로그램이 끼치는 것보다 훨씬 덜한 법이다.

 

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

비난 대신 문제를 해결하라

다른 사람의 버그를 발견한 후, 그 버그를 만들어 낸 부정한 범죄자를 비난하는 데에 시간과 노력을 들이는 수가 있다. 어떤 회사에서는 비난이 문화의 일부고 거기서 카타르시스를 얻을 수도 있다. 하지만 기술의 전당에서는 남을 비난하기보다 문제를 고치는 데에 집중하고 싶어 한다.

버그가 여러분의 잘못인지 다른 사람의 잘못인지는 그리 중요한 게 아니다. 어쨌거나 그 버그는 여러분의 문제로 남는다.
 

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

GUI 인터페이스는 훌륭한 것이고, 몇 가지 간단한 조작에는 그게 더 빠르고 편리 할 수도 있다. 파일을 이동하고, MIME 형식으로 인코딩 된 이메일을 읽고, 글자를 쳐 넣고 하는 것들은 모두 그래픽 환경에서 하는 게 좋을 수 있다. 하지만 모든 작업을 GUI로만 한다면, 여러분이 가진 환경의 전체 능력을 이용하지 못하게 된다. 일반적인 작업을 자동화 할 수 없고, 쓸 수 있는 도구의 풀파워를 사용 할 수 없다. 게다가 도구를 결합해서 자신에게 꼭 맞는 매크로 도구를 만들 수가 없다. GUI의 장점은 WYSIWYG (What You See Is What You Get) 이지만, 반면에 단점은 WYSIAYG (What You See Is All You Get)이다.

GUI의 환경의 기능은 일반적으로 설계자의 의도에 따른 제약을 받는다. 설계자가 제공하는 모델 이상을 필요로 하더라도 대개는 어쩔 수 없다. 그런데 여러분은 종종 그 모델 이상을 필요로 한다. 실용주의 프로그래머들은 단지 코드를 자르거나, 객체 모델을 개발하거나, 문서를 작성하거나, 빌드 과정을 자동화하거나 하지만은 않는다. 이 모든 일을 다 한다. 어떤 도구든지 사용 범위는 보통 그 도구가 사용되리라고 예상되는 작업에 한정된다.

실용주의 프로그래머로서 여러분은 늘 임시변통의 작업을 수행하길 원한다. 해당 GUI가 지원하지 않을 수도 있는 그런 작업 말이다. 명령줄은 쿼리나 기타 다른 작업을 수행하기 위해 몇 개의 명령어를 재빨리 결합하려 할 때 사용하기 좋다.

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

프로토타입은 나중에 버릴 수 있는 코드를 만든다.
예광탄 코드는 기능은 별로 없지만 완결 된 코드이며, 최종 시스템 골격의 일부를 이룬다.
프로토타입을 예광탄이 하나라도 발사되기 전에 먼저 일어나는 정찰과 정보 수집으로 생각하면 되겠다.

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

 

프로토타입은 세부사항을 생략하고 시스템의 특정 측면에 초점을 맞추기 때문에 프로젝트를 진행하는 언어보다 고수준 언어 (예를 들면 펄, 파이썬, 혹은 Tcl)을 이용하여 구현 할 수 있다. 고수준 스크립트 언어는 (데이터 타입을 지정하는 등의) 많은 세부사항을 피할 수 있게 해주면서도 (비록 불완전하거나 느릴지라도) 작동하는 코드를 생성하게 해준다.

만약 프로토타입 사용자 인터페이스가 필요하다면 Tcl/Tk, 비주얼베이직, 파워빌더, 델파이 등을 고려 해 보라.

스크립트 언어는 또한 저수준의 요소들을 새롱누 조합으로 엮어 내는 '접착제'로 좋다. MS 윈도우즈를 이용한다면 비주얼베이직을 사용해 COM 컨트롤들을 조합 할 수 있다. 좀 더 일반적으로는 펄이나 파이썬 같은 스크립트 언어를 사용해 저수준의 C 라이브러리들을 조합 할 수 있는데, 이때 손으로 할 수도 있지만 무료로 사용가능한 SWIG 같은 도구를 이용해 자동화 할 수도 있다. 이러한 접근 방식을 취한다면 기존의 컴포넌트들을 빠르게 조합해 이들이 어떻게 동작하는지 볼 수 있을 것이다.

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기

 

양자 역학 분야의 유명한 메타포인 슈뢰딩거의 고양이 이야기를 소개하려 한다. 어떤 고양이가 밀폐 된 상자에 갇혀있다. 상자 안에는 1시간에 1/2 확률로 알파 입자를 분해하는 알파 입자 가속기와 청산가리 통이 있다. 알파 입자가 분해되어 방출되면 청산가리 통의 센서에 감지되는데 이 경우 청산가리 통이 깨져 고양이는 죽게 된다. 1시간 후에 고양이는 살았을까, 죽었을까? 슈뢰딩거에 따르면 둘 다 옳은 답이다.

알파입자의 분해 주기마다 두 가지 가능한 결과가 있고, 이 때마다 우주는 복사 된다. 한 곳에서는 분해가 일어나고, 한 곳에서는 그렇지 않다. 그러므로 고양이는 한 우주에서는 살아있고, 다른 우주에서는 죽는다. 상자를 열어보았을 때 비로소 여러분이 어떤 우주에 속해 있는지를 알 수 있게 된다.

모든 상황을 대비한 코드를 작성하는 것은 어려운 일이다.

하지만 코드의 진화를 슈뢰딩거의 고양이로 가득 찬 상자로 생각하라. 각각의 결정은 다른 버전의 미래를 야기한다. 여러분의 코드는 몇 가지 가능한 미래를 지원 할 수 있는가? 어떤 미래가 일어날 가능성이 높을까? 그 미래가 닥쳤을 때, 이를 지원하는 것이 얼마나 어려울까?

상자를 열 용기가 있는가?

 

실용주의프로그래머 카테고리 컴퓨터/IT > 프로그래밍/언어 지은이 앤드류 헌트 (인사이트, 2007년) 상세보기