[TS] any 타입의 위험성

본 포스트는 이펙티브 타입스크립트를 보며 정리한 내용입니다.

any 타입의 위험성

• as any로 타입 단언을 하면서 대부분의 타입 에러는 해결할 수 있다.
• 다만, 이런 경우 타입스크립트의 수많은 장점을 누릴 수 없다.
• 부득이하게 사용하더라도 위험성은 알고 있어야 한다.
• 위험성에 대해 알아보자.

1. 타입 안정성이 없다.

   let age: number;
   age = '12';
// ~~~ '"12"' 형식은 'number' 형식에 할당할 수 없습니다.
   age = '12' as any; // OK

• 위의 경우 처음에 선언됐던 number 타입을 무시하고 string 타입을 할당할 수 있다.
• 타입체커는 선언에 따라 number 타입으로 판단할 것이다.

2. 함수 시그니처(contract)를 무시한다.

• // contract: 계약, 약속
• 함수를 호출하는 쪽은 약속된 타입의 입력을 제공하고, 함수는 약속된 타입의 출력을 반환해야 한다.
• any 타입을 사용하면 이를 무시할 수 있다.

function calculateAge(birthDate: Date): number {
  ...
  return 0;
  // END
}

let birthDate: any = '1990-01-19';
calculateAge(birthDate);  // 정상

• 위의 경우 birthDate는 any 타입이므로 Date 타입이 아닌 string 타입을 할당할 수 있다.
• JS에서는 타입이 암시적으로 변환되는 일이 잦다. 그래서 string 타입이 number 타입이 필요한 곳에서 문제 없이 실행되기도 한다. 이는 더 큰 문제를 야기한다.

3. 언어 서비스가 적용되지 않는다.

• 자동완성 기능 또는 적절한 도움말을 제공받지 못한다.
• rename symbol 등 symbol을 통한 기능들을 사용할 수 없다.

4. 코드 리팩토링 때 버그를 감춘다.

type checker의 도움을 받지 못하므로 코드 리팩토링 시 버그를 확인할 수 없다.

5. 타입 설계를 감춘다.

복잡한 객체를 any 타입으로 선언하면 해당 객체의 타입을 알 수 없다. 따라서 동료 검토에서 어려움이 있을 수 있다.

6. 타입 시스템의 신뢰도를 떨어뜨린다.

• human error를 type checker가 잡아주지 못하게 된다.
• 런타임에서 타입 에러를 발견하게 된다면 type checker를 신뢰할 수 없게 된다.
• any는 결국 타입 내의 타입 정보를 기억하게 한다.

References

• any 타입의 위험성 [27p]