아이템 36 해당 분야의 용어로 타입 이름 짓기

가독성을 높이고, 추상화 수준을 올리기 위해서 해당 분야의 용어를 사용해야 한다.

타입 이름 짓기 역시 타입 설계의 중요한 부분이다.

엄선된 타입, 속성, 변수의 이름은 의도를 명확히 하고 코드와 타입의 추상화 수준을 높여준다.

동물들의 데이터베이스를 구축한다고 가정

interface Animal {  
  name: string  
  endangered: boolean  
  habitat: string  
}  
  
const leopard: Animal = {  
  name: 'Snow Leopard',  
  endangered: false,  
  habitat: 'tundra',  
}

이 코드에는 4가지 문제가 있다.

• name 은 매우 일반적인 용어이다. 동물의 학명인지 일반적인 명칭인지 알 수 없다.
• endangered 속성이 멸종 위기를 표현하기 위해 boolean 타입을 사용한 것이 이상하다. 이미 멸종된 동물을 true로 해야 하는지 판단할 수 없다. 또 의도를 '멸종위기 또는 멸종'으로 생각한 것일지도 모른다.
• 서식지를 나타내는 habitat 속성은 너무 범위가 넓은 string타입 아이템 33 string 타입보다 더 구체적인 타입 사용하기일 뿐만 아니라 서식지라는 뜻 자체도 불분명하기 때문에 다른 속성들보다도 훨씬 모호하다.
• 객체의 변수명이 leopard 이지만 name 속성의 값은 'Snow Leopard' 이다. 객체의 이름과 속성의 name이 다른 의도로 사용된 것인지 불분명하다.

이 예제를 해결하려면 작성자를 찾아 의도를 물어야 한다. 그러나 작성자가 회사에 없거나 코드를 기억하지 못할 것이다. 또는 작성자가 본인이라는 것을 알게되는 최악의 상황이 올 수 있다....

다음 타입 선언은 의미가 분명하다.

interface Animal {  
    commonName: string  
    genus: string  
    species: string  
    status: ConservationStatus  
    climates: KoppenClimate[]  
}  
  
type ConservationStatus = 'EX' | 'EW' | 'CR' | 'EN' | 'VU' | 'NT' | 'LC'  
type KoppenClimate =  
    | 'Af'  | 'Am'  | 'As'  | 'Aw'  | 'BSh'  | 'BSk'  | 'BWh'  | 'BWk'  
    | 'Cfa' | 'Cfb' | 'Cfc' | 'Csa' | 'Csb'  | 'Csc'  | 'Cwa'  | 'Cwb'  
    | 'Cwc' | 'Dfa' | 'Dfb' | 'Dfc' | 'Dfd'  | 'Dsa'  | 'Dsb'  | 'Dsc'  
    | 'Dwa' | 'Dwb' | 'Dwc' | 'Dwd' | 'EF'   | 'ET'  

const snowLeopard: Animal = {  
    commonName: 'Snow Leopard',  
    genus: 'Panthera',  
    species: 'Uncia',  
    status: 'VU', // 취약종(vulnerable)
    climates: ['ET', 'EF', 'Dfd'], // 고산대(alpine) or 아고산대(subalpine)
}

다음 3가지를 개선했다.

• name은 commonName, genus, species 등 구체적인 용어로 대체했다.
• endangerd는 동물 보호 등급에 대한 IUCN의 표준 분류 체계인 ConservationStatus 타입의 status로 변경되었다.
• habitat은 기후를 뜻하는 climateds로 변경되었으며, 쾨펜 기후 분류를 사용한다.

변경된 코드는 데이터를 훨씬 명확하게 표현하고 있다. 그리고 정보를 찾기 위해 사람에 의존할 필요가 없다.

같은 의미에 다른 이름을 붙이면 안된다. 특별한 의미가 있을때만 용어를 구분해야 한다.

코드로 표현하고자 하는 모둔 뷴야에는 주제를 설명하기 위한 전문 용어들이 있다.

자체적으로 용어를 만들지말고 이미 존재하는 용어를 사용하자. 이런 용어들은 수년, 수십년, 수 세기에 걸쳐 다듬어져 왔으며 현장에서 실제로 사용되고 있을 것이다.

아이템 37 공식 명칭에는 상표를 붙이기

타입스크립트는 구조적 타이핑(덕 타이핑)을 사용하기 때문에, 값을 세밀하게 구분하지 못하는 경우가 있다. 값을 구분하기 위해 공식 명칭이 필요하다면 상표를 붙이는 것을 고려해야 한다.

interface Vector2D {  
  x: number  
  y: number  
}  
function calculateNorm(p: Vector2D) {  
  return Math.sqrt(p.x * p.x + p.y * p.y)  
}  
  
calculateNorm({ x: 3, y: 4 }) // OK, result is 5  
const vec3D = { x: 3, y: 4, z: 1 }  
calculateNorm(vec3D) // OK! result is also 5

이 코드는 구조적 타이핑 관점에서는 문제가 없다. 하지만 수학적으로 따지면 2차원 벡터를 사용해야 이치에 맞다.

함수가 3차원 벡터를 허용하지 않게 하려면 공식 명칭을 사용하면 된다.

공식 명칭 개념을 타입스크립트에서 흉내 내려면 '상표(brand)'를 붙이면 된다.

interface Vector2D {  
  _brand: '2d'  
  x: number  
  y: number  
}  
function vec2D(x: number, y: number): Vector2D {  
  return { x, y, _brand: '2d' }  
}  
function calculateNorm(p: Vector2D) {  
  return Math.sqrt(p.x * p.x + p.y * p.y) // Same as before  
}  
  
calculateNorm(vec2D(3, 4)) // OK, returns 5  
const vec3D = { x: 3, y: 4, z: 1 }  
calculateNorm(vec3D)  
// ~~~~~ Property '_brand' is missing in type...

상표 기법은 타입시스템에서 동작하지만 런타임에 상표를 검사하는 것과 동일한 효과를 얻을 수 있다.

예를 들어, 절대 경로를 사용해 파일 시스템에 접근하는 함수를 가정해보자. 런타임에는 절대 경로('/')로 시작하는지 체크하기 쉽지만, 타입시스템에서는 절대 경로를 판단하기 어렵기 때문에 상표 기법을 사용한다.

type AbsolutePath = string & { _brand: 'abs' }  
function listAbsolutePath(path: AbsolutePath) {  
  // ...  
}  
function isAbsolutePath(path: string): path is AbsolutePath {  
  return path.startsWith('/')  
}

string 타입이면서 _brand 속성을 가지는 객체를 만들 수는 없다. AbsolutePath는 온전히 타입 시스템의 영역이다.

만약 path 값이 절대 경로와 상대 경로 둘 다 될 수 있다면, 타입을 정제해 주는 타입 가드를 사용해서 오류를 방지할 수 있다.

function f(path: string) {  
  if (isAbsolutePath(path)) {  
    listAbsolutePath(path)  
  }  listAbsolutePath(path)  
  // ~~~~ Argument of type 'string' is not assignable  
  //      to parameter of type 'AbsolutePath'}

아이템 38 any 타입은 가능한 한 좁은 범위에서만 사용하기

의도치 않은 타입 안전성의 손실을 피하기 위해서 any의 사용 범위를 최소한으로 좁혀야 한다.

function f1() {  
  const x: any = expressionReturningFoo() // 이렇게 하지 말자.
  processBar(x)  
}  
  
function f2() {  
  const x = expressionReturningFoo()  
  processBar(x as any) // 이게 낫다.
}

f2 함수의 형태가 권장되는 이유는 processBar 함수의 매개변수에만 사용된 표현식이므로 다른 코드에는 영향을 미치지 않기 때문이다

함수의 반환 타입이 any인 경우 타입 안정성이 나빠진다. 따라서 any타입을 반환하면 절대 안된다.

function f1() {  
  const x: any = expressionReturningFoo()  
  processBar(x)  
  return x  
}  
  
function g() {  
  const foo = f1() // Type is any  
  foo.fooMethod() // 이 함수 호출은 체크되지 않습니다
}

반환타입을 any로 반환하면 그 영향력은 프로젝트 전반에 전염병처럼 퍼지게된다.

강제로 타입 오류를 제거하려면 any 대신 @ts-ignore 사용하는 것이 좋다.

function f1() {  
  const x = expressionReturningFoo()  
  // @ts-ignore  
  processBar(x)  
  return x  
}

@ts-ignore를 사용한 다음 줄의 오류가 무시된다. 하지만 근본적인 원인을 해결한 것이 아니기 때문에 다른 곳에서 더 큰 문제가 발생할 수 있다.

아이템 39 any를 구체적으로 변형해서 사용하기

any를 사용할 때는 정말로 모든 값이 허용되어야만 하는지 면밀히 검토해야 한다.

예를 들어 any 타입의 값을 그대로 정규식이나 함수에 넣는 것은 권장되지 않는다.

function getLengthBad(array: any) {  
  // 이렇게 하지 맙시다!
  return array.length  
}  
  
function getLength(array: any[]) {  
  return array.length  
}

앞의 예제에서 any를 사용하는 getLengthBad보다는 any[]를 사용하는 getLength가 더 좋은 함수이다

이유는 세가지다.

• 함수 내의 array.length 타입이 체크된다.
• 함수의 반환 타입이 any 대신 number로 추론된다.
• 함수 호출될 때 매개변수가 배열인지 체크된다.

인수를 넣어 실행해보면 차이점을 알 수 있다.

any보다 더 정확하게 모델링할 수 있도록 any[] 또는 {[id: string]: any} 또는 () => any 처럼 구체적인 형태를 사용해야 한다.

함수의 매개변수가 객체이긴 하지만 값을 알 수 없다면 {[key: string]: any} 처럼 선언하면 된다.

function hasTwelveLetterKey(o: { [key: string]: any }) {  
  for (const key in o) {  
    if (key.length === 12) {  
      return true  
    }  
  }  
  return false  
}

위 예제처럼 매개변수가 객체지만 값을 알 수 없다면 ${[key: string]: any} 대신 모든 비기본형 타입을 포함하는 object 타입을 사용할 수도 있다.

함수의 타입에도 단순히 any를 사용해서는 안된다. 최소한으로나마 구체화할 수 있는 세 가지 방법이 있다.

type Fn0 = () => any // 매개변수 없이 호출 가능한 모든 함수
type Fn1 = (arg: any) => any // 매개변수 한개
type FnN = (...args: any[]) => any // 모든 개수의 매개변수 "Function" 타입과 동일

앞의 예제에 등장한 세 가지 함수 타입은 모두 any 보다는 구체적이다. 마지막 줄을 잘 살펴보면 ...args의 타입을 any[]로 선언했다. any 로 선언해도 동작하지만 any[]로 선언하면 배열 형태라는 것을 알 수 있어 더 구체적이다.

아이템 40 함수 안으로 타입 단언문 감추기

타입 선언문은 일반적으로 타입을 위험하게 만들지만 상황에 따라 필요하기도 하고 현실적인 해결책이 되기도 한다. 불가피하게 사용해야 한다면, 정확한 정의를 가지는 함수 안으로 숨기도록 하자.

함수를 작성하다 보면, 외부로 드러난 타입 정의는 간단하지만 내부 로직이 복잡해서 안전한 타입으로 구현하기 어려운 경우가 많다.

함수의 모둔 부분을 안전한 타입으로 구현하는 것이 이상적이지만, 불필요한 예외 상황까지 고려해 가며 타입 정보를 힘들게 구성할 필요는 없다.

함수 내부에는 타입 단언을 사용하고 함수 외부로 드러나는 타입 정의를 정확히 명시하는 정도로 끝내는 것이 낫다.

프로젝트 전반에 위험한 타입 단언문이 드러나있는 것보다, 제대로 타입이 정의된 함수 안으로 타입 단언문을 감추는 것이 더 좋은 설계이다.

declare function shallowEqual(a: any, b: any): boolean  
function shallowObjectEqual<T extends object>(a: T, b: T): boolean {  
  for (const [k, aVal] of Object.entries(a)) {  
    if (!(k in b) || aVal !== b[k]) {  
      // ~~~~ Element implicitly has an 'any' type  
      //      because type '{}' has no index signature      return false  
    }  
  }  
  return Object.keys(a).length === Object.keys(b).length  
}

in 구문의 k in b 체크로 b 객체에 k 속성이 있다는 것을 확인했지만 b[k] 부분에서 오류가 발생하는 것이 이상하다.

어쨋든 실제 오류가 아니라는 것을 알고 있기 때문에 any로 단언하는 수 밖에 없다.

declare function shallowEqual(a: any, b: any): boolean  
function shallowObjectEqual<T extends object>(a: T, b: T): boolean {  
  for (const [k, aVal] of Object.entries(a)) {  
    if (!(k in b) || aVal !== (b as any)[k]) {  
      return false  
    }  
  }  
  return Object.keys(a).length === Object.keys(b).length  
}

b as any 타입 단언문은 안전하며 (k in b 체크를 했으므로), 결국 정확한 타입으로 정의되고 제대로 구현된 함수가 된다. 객체가 같은지 체크하기 위해 객체 순회와 단언문이 코드에 직접 들어가는 것보다, 앞의 코드처럼 별도의 함수로 분리해 내는 것이 훨씬 좋은 설계이다.