Today
-
Yesterday
-
Total
-
  • 기본 값(default value)을 언제 사용할까?
    Programmer/Programming 2018. 1. 2. 18:57

    매번 값을 특정하는 것은 꽤 귀찮은 일이다.
    가령, ssh 접속할 때 포트 번호 22를 항상 입력하는 것은 불편하다.
    기본 값[각주:1]은 이런 불편함을 덜어준다.
    이는 곧 개발의 생산성과 사용의 편의성으로 이어진다.


    반면, 사용의 편의성은 대게 위험성을 불러들인다.
    임의로 기본값을 남발하면 낭패를 볼 수 있다.
    컴파일이나 실행 직후 문제없이 돌아가는 코드가 기본값 때문에 문제를 일으키곤 한다.


    기본 값에는 명백하고 합리적인 이유가 반드시 있어야 한다.


    예를 들면, HTTP 클라이언트를 개발한다면,
    HTTP 프로토콜의 기본 포트인 80을 기본 값으로 사용할 수 있다.
    여기서는 스펙이 합리적인 이유가 된다.


    그런데, HTTP 프로토콜의 기본 포트인 80이 아닐 수도 있다.
    사내 HTTP API 서버들의 포트가 다양할 수 있다.,
    개발 서버와 테스트 서버, 실 서버 간의 포트가 다를 수도 있다.
    이런 경우, 섣불리 특정 포트를 기본값으로 정했다가 장애 크리를 맞을 수 있다.


    다른 기본값 사용의 예로는
    데이터베이스 테이블과 클래스 이름 간에 생성 규칙[각주:2]이 있다면,
    테이블의 이름을 생략할 수 있다.
    멤버 변수나 함수의 인자의 기본 값으로 클래스 명에서 도출된 테이블 이름을 사용한다.
    위 규칙이 기본값의 명백한 이유가 된다.


    명백한 이유가 없이 기본값을 사용하는 경우를 조심한다.
    이유는 모르지만 특정 값만 사용했기 때문에 채택하는 경우나,
    개발 과정에서 편의상 사용하는 경우가 대표적이다.


    예를 들면, 어떤 함수를 호출할 때 늘 같은 값을 사용하는 것을 발견했다.
    특정 값이 될 수밖에 없는 이유를 찾으면 기본값이 될 수 있다.
    반면, 이유는 모르지만 현상이 그러하니 기본값이라고 정하는 것은 옳지 않다.
    추후에 다른 값이 사용될 수 있는데, 이런 버그는 놓치기 쉽다.


    개발 과정에서 귀찮아서 기본값을 지정하는 경우도 있다.
    예를 들면, 테스트 환경을 기본값으로 코딩했다.
    개발을 편하게 했을지 몰라도, 나중에 실서비스에 배포될 때 장애로 이어질 수 있다.


    '일단 이 값을 기본으로 하자.'와 같은 위험천만한 기본 값은 조심해야 한다.[각주:3]
    당장은 개발의 생산성으로는 이어진다.
    하지만, 이것은 기술 부채가 되어 자신의 발목을 잡을 것이다.
    기본 값은 명백하고 합리적인 접근으로 판단해야 한다.

    1. 하드 코딩, 기본 매개변수 등 [본문으로]
    2. Convention over Configuration [본문으로]
    3. 문제 탐색 과정에서 탐색만 하고 버릴 코드는 예외이다. 빨리 작성하고 파악하는데 주력해야 하기 때문이다. 대신에, "XXX"나 "HARD CODE"와 같은 주석을 꼭 남긴다. 탐색 이후에 재사용하기로 마음을 먹었다면, 이런 주석을 찾아서 모두 고친다. [본문으로]

    댓글

Designed by Tistory.