프로그래밍 언어 생산성

얼마 전 페이스북에서 대화하던 중 프로그래밍 생산성에 있어서 누가 개발하느냐가 중요하지 어떤 언어를 사용하느냐는 중요하지 않다는 의견을 들었는데 저는 강하게 반대하는 입장이지만 여건 상 길지 않게 의견을 전달했습니다. 아마 잘 설득하진 못했을 겁니다. 그런데 오늘 Java 언어에서 속성의 읽기 접근자(getter)와 쓰기 접근자(setter) 작성에 대한 괴로움이 주제인 논의를 발견했습니다. 이 문제에 대해 역시 페이스북에서 얘기를 하던 중 프로그래밍 언어가 가지는 생산성에 대한 영향력의 한 예가 떠올라 적어봅니다.

Stone and metal knives

Stone and metal knives

이 글이 작성되는 시점의 최신 Java 언어 스펙(8)에 따르면 속성은 다음과 같이 작성됩니다.

private String myProperty;

public String getMyProperty() {
    return myProperty;
}

public void setMyProperty(String value) {
    myProperty = value;
}

이것이 너무 장황해서 짜증나니 무결성 확보 등을 위해 접근자 논리를 제공해야할 높지 않은 경우의 수는 닥치게 되면 그 때 가서 고민하고 일단 그냥 공용(public) 필드를 사용하는 것이 어떻겠느냐 하는 것이 발의자의 의견입니다. 본 게시글은 이 문제제기의 정당성이나 해답보다는 왜 이런 고민이 생겨났는지에 대해 얘기합니다.

위에서 본 코드를 공용 필드로 작성하면 이렇습니다.

public String myProperty;

간결하네요. 그런데 만약 myPropertynull 상태를 허용하지 않는다던가 하는 규칙이 추가되면 쓰기 접근자가 필요해지고 처음에 봤던 코드와 유사한 형태로 코드를 변경해야합니다.

private String myProperty;

public String getMyProperty() {
    return myProperty;
}

public void setMyProperty(String value) {
    // Validation logic
    myProperty = value;
}

다시 길어졌습니다. 이번엔 필요한 코드가 들어갔기 때문에 장황하다고 말하기는 어렵습니다. 문제는 다른 곳에 있습니다. 인터페이스에 큰 변화(breaking change)가 생겼기 때문에 모든 클라이언트 코드가 동작하지 않게됩니다. 그나마 같은 프로젝트의 클라이언트라면 어떤 도구가 도움을 줄 수도 있지만 그렇지 않은 경우라면 문제가 심각합니다. 공용 필드를 사용하면 당장 약간의 수고는 줄어들지만 디자인의 유연함은 크게 잃어버립니다.

자, 그런데 만약 애초에 프로그래밍 언어가 속성 접근자 작성에 피로도를 주지 않는다면 어떨까요? 필드를 공용으로 노출할 생각은 들지 않을겁니다. Java와 비교해 속성 지원 문법을 풍부하게 제공하는 C#의 경우 별다른 제어 논리를 가지지 않는 속성은 다음과 같이 작성할 수 있습니다.

public string MyProperty { get; set; }

Java에서 공용 필드를 작성하는 것과 비교해 괴로움을 느낄 정도로 장황하지 않습니다. 여기서 쓰기 접근자에 검증 논리를 추가하면 이렇습니다.

private string _myProperty;

public string MyProperty
{
    get { return _myProperty; }
    set
    {
        // Validation logic
        _myProperty = value;
    }
}

중요한 것은 구현부가 달라졌을 뿐 인터페이스는 변경되지 않았다는 것입니다. 클라이언트 코드는 변경될 필요가 전혀 없습니다.

정리해보죠. Java 언어를 사용할 경우 개체가 속성을 제공하기 위해 접근자를 작성하는데 특별한 논리의 필요성이 없다면 접근자 작성이 요구하는 노동력은 합리적이지 않다는 주장이 있습니다. 생산성이 낮아서 괴롭다는 것이죠. 그렇다고 공용 필드로 시작하자니 접근 논리를 추가해야 할 때 훨씬 큰 자원을 필요로 할 수 있습니다. 여기서도 낮은 생산성으로 고통받습니다. 이래저래 기대 생산성은 낮습니다.

반면 속성 지원을 풍부하게 해주는 C#을 사용하면 두 가지 경우 모두 고민거리가 아닙니다. 고민을 위한 비용도 불합리한 코딩 비용도 들어가지 않습니다. 이 예시에 대해서는 C#이 Java보다 생산성이 높습니다.

모든 프로그래밍 언어들은 생산성에 영향을 주는 다양한 요소들을 가지고 있습니다. 각 요소들은 특정 상황에서 생산성을 높이거나 낮춥니다. 생산성에 영향을 주는 정도 역시 다양합니다. 어떤 언어들은 요즘 자주 발생하는 문제들을 해결할 때 생산성을 높일 수 있는 기능을 많이 제공하고 다른 언어들은 그렇지 못합니다. 동일한 문제를 풀기 위해 누가 코딩을 하느냐도 중요하지만 어떤 언어를 사용하느냐도 문제해결 생산성에 영향을 많이 미칩니다. 생산성 높은 언어를 사용해 절약한 자원은 다른 곳(예를 들면 느리고 지루한 TDD 따위)에 사용할 수 있습니다.

Advertisements

프로그래밍 언어 생산성”에 대한 6개의 생각

  1. 신입사원

    이클립스에서 자동 생성 해주지 않나요?
    게터세터 자동 생성하는 것이 생산성에 영향을 미칠 정도라면,
    정말이지 개발 프레임웍과 빙법론은 극한의 생산성을 내도록 튜닝되어 있다는 얘기 깉네요

    응답
    1. Gyuwon 글의 글쓴이

      IDE는 논의 대상에 포함시키지 않았습니다. 하지만 IDE의 기능까지 고려해 Eclipse+Java와 Visual Studio+C#의 생산성을 비교한다면 Java는 더 처참하겠죠.

      응답
  2. Justin Song

    개인적으로 자바와 C#을 동시에 개발하고 있습니다. 게터세터가 정말 C#의 {get;set;} 보다 생산성이 떨어진다고 생각하지는 않는데요, 이런것들은 보통 기계적으로 작성하거나.. IDE의 코드 생성을 통해서 해결해서 현실적으로는 동일한 수고가 들지 않을까 합니다. 하지만 스레드나 델리게이트등의 다른 이슈로 가면 확실히 C#의 생산성이 앞서 있는건 자명하네요..

    응답
    1. Gyuwon 글의 글쓴이

      public async Task WritePageAsync(string url) =>
        Console.WriteLine(await new HttpClient().GetStringAsync(url));

      C#으로 작성된 콘솔에 웹 페이지를 출력하는 비동기 메서드입니다. 이 코드를 Java로 작성해 보시면 도움이 될까요?

      예 하나를 더 들까 했는데 너무 인위적인 것 같아서 제거했습니다.

      응답

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중