일상적인 것을 구체적으로 인지할 수 있다는 것과 그것을 어떤 형태로든 표현할 수 있다는 것은 많은 사람들이 갖지 못한 매우 탁월한 능력이라 생각합니다. 뛰어난 작가들은 주변에 존재하는 일상의 아름다움을 글로 표현합니다. 이러한 일상의 아름다움은 아무나 발견하지 못하고 또한 아무나 표현하지 못합니다. 그렇기에 이러한 점이야말로 작가들의 탁월함을 빛나게 해주는 하나의 요소라 생각합니다.

켄트벡이 쓴 "구현 패턴"에서는 여러 개발 패턴에 대한 소개를 하고 있습니다. 사실 소개된 패턴 각각이 참신하다기보다는 오히려 경험 많은 개발자라면 개발을 하면서 한번쯤 부딪쳐보았던 부분들이 많은 듯 합니다. 이러한 이유로 이 책을 읽은 사람들은 "이 책은 별다른 내용을 가지고 있지 않다"라고 비판하기도 합니다.

그렇지만 우리는 책을 읽는 독자의 입장에서 생각해 볼 필요가 있다고 생각합니다. 켄트벡이 다룬 내용들은 인지하기 힘든 문제들도 많았고, 인지하더라도 다른 사람에게 설명해 주기 어려운 내용였다고 생각합니다. 만약 이 책이 없었더라면 독자가 누군가에게 이러한 내용에 대한 설명을 듣는 것이 쉬운일만은 아니였을 것입니다.

저자 켄트벡이 누구도 생각치 못했던 것을 생각해내지 않았다 하더라도 일상적인 문제를 인지하고 그것을 글로 표현했습니다. 이것은 서두에서 얘기한 작가의 경우와 같이 볼 수 있으며, 부인할 수 없는 그만의 탁월함이라 생각합니다.

예전에 쓴 들여쓰기 최소화라는 글에 많은 분들이 다양한 의견을 주셨습니다. 주신 의견들을 유심히 읽다 보니 해당 글에 대해 깊히 생각하는 기회를 가질 수 있었고, 자연스레 아래와 같은 세 가지 논제를 머리속에 떠올렸습니다.

첫 번째, 들여쓰기 최소화가 정말 가치있는 것인가? 만약 가치 있다면 논리적인 근거를 제시할 수 있는가?
두 번째, 진입점과 종료점을 각 하나씩만 유지해야 하는 것은 의미 있는 일인가?
세 번째, 긍정 조건과 부정 조건 중 어떤 것이 더 이해하기 좋은가? 만약 상황에 따라 적절히 사용해야 한다면 긍정 조건과 부정 조건을 선택하기 위해 사용하는 기준을 도출할 수 있을까?

최근 읽고 있는 켄트벡의 Implementation Patterns에는 위 논제에 대한 답변을 얻는 데 도움이 될만한 내용이 많이 담겨있었습니다. 저는 그동안의 저의 생각과, 최근 해당 책에서 얻은 지식들을 이용하여 위 세 가지 논제 중 첫번째 논제에 대한 저의 생각을 얘기해보고자 합니다.(참고로 Implementation Patterns의 Guard Clause와는 조금 다른 시점의 글입니다. 이 글은 이전 글에서 얘기했던 들여쓰기 최소화 자체에 집중한 글임을 밝힙니다)

들여쓰기를 한다는 것은 현재 들여쓰기 되고 있는 단락 위에 진입 조건이 존재한다는 것을 의미합니다. 조건문, 반복문, 메서드 등이 이러한 진입 조건이 될 수 있습니다.

만약 어떤 사람이 조건문에 속해 있는 하위 단락을 읽는다면, 하위 단락이 어떤 경우에 실행되는지를 '전제'로 인식하고 있어야 합니다. 그런데 이러한 전제가 많아지고 단락이 깊어지면 문제가 생깁니다. 아래 예제 코드는 이러한 문제를 잘 드러내고 있습니다.

void compute() {
    Server server = getServer();
    if (server != null) {
        Client client = server.getClient();
        if (client != null) {
            Request current = client.getRequest();
            if (current != null) {
                 processRequest(current);
            }
        }
    }
}

void compute() {
    Server server = getServer();
   if (server == null)
        return;
    Client client = server.getClient();
   if (client == null)
       return;
    Request current = client.getRequest();
   if (current == null)
       return;
   processRequest(current);
}

Implementation Patterns P71에서 인용

첫 번째 코드를 보면 읽는 사람이 전제로 유지해야 할 조건이 많다는 것을 볼 수 있습니다. 'server가 null이 아니고, client도 null이 아니며, current도 null이 아니면' 이라는 전제 조건이 processRequest에 이르기 전까지 단계적으로 머리속에 유지 되어야 합니다. 켄트백은 이러한 형태의 전제 조건들에 대해 '집중해야 할 것에 집중하지 못하게 방해하는 것들'이라고 얘기합니다. 실제로 위와 같은 코드는 집중해야 할 것에 집중하기 어렵게 하며 만약 else까지 존재한다면 더욱더 어려운 상황이 만들어집니다. 결국 코드를 이해하기가 어려워지는 것입니다.

반면 두 번째 코드는 동일한 일을 하면서도 보다 이해하기 쉬운 코드입니다. 코드에 윗 부분에 조건에 안 맞으면 바로 종료하는 코드가 있음을 볼 수 있습니다. processRequest에 이르렀을 때 첫번째 코드와는 달리 머리속에 전제 조건으로 유지해야 할 것이 없어집니다. 왜냐하면 'server가 null이면 종료','client가 null이면 종료','current가 null이면 종료' 이렇게 세 가지 조건 단락이 독립적으로 분리되어 이미 실행되었기에 더 이상 앞에 코드에 대해서 신경쓰지 않아도 되기 때문입니다.

만약 사람의 두뇌가 스택(Stack) 형태의 기억을 잘 할 수 있다면 첫번째 코드도 큰 문제는 아닐 것입니다. 하지만 저의 경우 스택 형태로 무엇인가를 기억하는 것은 쉽지 않았습니다. 따라서 몇단계의 전제 조건을 가지는 코드를 보면 한 세번째 전제 조건을 보는 중, 첫번째로 보았던 전제 조건을 잊어버려 허둥되곤 했습니다. 사실 이 문제는 저만의 문제는 아닌 것 같습니다. ANT의 depends 기능을 지나치게 활용하여 만들어진 빌드 스크립트를 분석하는 일은 저뿐만 아니라 다른 사람들도 무척 어려워 하더군요.

저는 첫 번째 논제인 '들여쓰기 최소화가 정말 가치있는 것인가?'라는 부분에 대해 '들여쓰기 최소화는 충분한 가치를 가지고 있다'고 주장하고 싶습니다. 왜냐하면 많은 경우 들여쓰기 최소화를 통해 더 이해하기 쉬운 코드를 만들 수 있기 때문입니다.

2008/01/15 ~ 2008/01/17