[이펙티브 타입스크립트+5] any 타입 지양하기

https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html#any

1장 타입스크립트 알아보기
아이템 5 | any 타입 지양하기

3줄 요약
1. any 타입 지양하기
2. any 타입 지양하기
3. any 타입 지양하기

참고) 이펙티브 타입스크립트는 타입스크립트의 기본 그 이상을 다룹니다.

---

타입스크립트를 사용하면서 any 타입을 사용하지 말라는 말을 여럿 듣습니다.
이제는 상식이 되어버린 any 타입 지양하기입니다.
그러면 any 타입이 어떤 문제가 있기 때문에 사용을 지양해야 할까요?

먼저 그전에 언제 any를 사용해야 할까요?
바로 자바스크립트 프로젝트에서 타입스크립트로 마이그레이션할 때 사용하면 됩니다.
타입스크립트 타입 시스템은 점진적이고 선택적이라고 합니다.
따라서, 조금씩 자바스크립트 프로젝트에서 타입을 점진적으로 추가할 때 이 any 타입이 큰 도움이 될 수 있습니다.
(그러나 타입스크립트 프로젝트로 마이그레이션한다면 새롭게 프로젝트를 만드는 것이 정신 건강에 더 좋을 수도 있습니다..)

any는 타입스크립트 타입 체커에게 "타입 체킹을 하지 마!"라고 말하는 것과 같습니다.
따라서, 타입 안정성을 보장받을 수 없습니다.

any 타입으로 단언함으로써 타입 체킹을 무시

또한, 함수 시그니처를 무시합니다.
함수에는 어떤 인풋과 아웃풋의 타입이 명시되어 있습니다.
그러나 any 타입을 이용하면 인풋에 어떠한 값이든 들어갈 수 있습니다.

any를 이용하여 함수 시그니처 무시

타입스크립트의 강력한 장점인 언어 서비스, 자동완성을 이용할 수 없습니다.

고마운 자동완성

사라진 자동완성

any 타입으로 할당된 변수에 대해서는 해당 타입을 추론할 수 없기 때문에 잠재 버그가 있어서 런타임에 에러를 발생시킬 수도 있습니다.
다시 타입이 없는 자바스크립트로 돌아가는 것과 같습니다.
타입 체커의 이점을 활용하지 못하면서 더불어 타입 시스템의 신뢰를 떨어뜨립니다.

개발을 진행하다 보면 외부 REST API, GRAPHQL, gRPC 등과 같이 외부로부터 데이터를 받아오는 경우가 있습니다.
이런 경우 외부의 데이터 타입을 어떻게 가지고 와야 하나 고민하게 됩니다.
손수 직접 받아올 데이터들의 타입들을 직접 정의해주는 것이 가장 좋습니다.
그러나 비용이 많이 들어 any로 처리하고 싶은 마음이 들 때도 있을 겁니다.

그럴 때에는 type generation 같은 서비스나 라이브러리들을 찾아볼 것을 추천합니다.
개인적으로는 quicktype을 이용했습니다.

https://quicktype.io/

Convert JSON to Swift, C#, TypeScript, Objective-C, Go, Java, C++ and more • quicktype

서버로부터 받은 데이터들을 웹사이트에 카피 앤 페이스트 하여 타입을 생성할 수도 있고 npm 패키지를 내려받아 cli를 통해서 서버 주소를 입력하여 타입을 생성할 수도 있습니다.
자동으로 타입이 생성된 것이라 의도와는 다르게 타입이 생성될 가능성이 있습니다.
그런 경우에는 직접 해당 부분을 수정해주어야 합니다.
이외에도 많은 타입 생성 라이브러리들이 있으니 직접 찾아보시고 괜찮은 라이브러리를 선택하시면 됩니다.
물론, 직접 타입을 생성하는 것이 가장 안전하고 의도한 바대로 타입 체킹을 할 수 있습니다.

 

Materials From
1. <이펙티브 타입스크립트>(댄 밴더캄 지음, 장원호 옮김, 인사이트 2021)
2. 타입스크립트 공식 홈페이지 | https://www.typescriptlang.org/

Typed JavaScript at Any Scale.