1. 타입 안정성이 없다.
let age: number;
age = '10'; // "12" 형식은 number 형식에 할당될 수 없습니다.
age = '10' as any // OK
age는 number 타입으로 선언되어 있기에 타입 체커를 통해 위의 코드에서는 오류를 찾아냈지만,
타입 단언문인 as any를 사용하게 되면 오류가 없어진다.
2. 함수 시그니처를 무시한다.
function calc(date: Date): number {
// 내용..
}
let date: any = '1994-01-28';
calc(date); // OK
calc()의 date 매개변수는 Date 타입이어야 한다.
그러나 any 타입을 사용하게 되면 calc()의 시그니처를 무시하게 된다.
3. 언어 서비스가 적용되지 않는다.
타입스크립트는 자동완성 기능 및 적절한 도움말을 제공하지만, any 타입을 사용하게 되면 아무 도움을 받을 수 없다.
4. 리팩토링 때 버그를 감춘다.
interface ComponentProps {
onSelectItem: (item: any) => void
}
function renderSelector(props: ComponentProps) {
// 내용..
}
let selectedId: number = 0;
function handleSelectItem(item: any) {
selectedId = item.id;
}
renderSelector({onSelectItem: handleSelectItem});
onSelectItem에 아이템 객체를 id만 전달하도록 개선해보자
interface ComponentProps {
onSelectItem: (id: number) => void;
}
위와 같이 수정했을 때 handleSelectItem은 any 매개변수를 받고 있기 때문에 타입 체크를 모두 통과한 뒤 런타임 오류가 발생하게 된다.
5. 타입 시스템의 신뢰도를 떨어뜨린다.
사람은 항상 실수를 하기 때문에 타입 체커가 실수를 잡아주고 코드의 신뢰도가 올라간다.
any 타입을 쓰지 않으면 런타임 오류를 미리 잡을 수 있고 신뢰도를 높일 수 있다.
참고
- 이펙티브 타입스크립트
'JavaScript&TypeScript' 카테고리의 다른 글
JavaScript - 연락처에 하이픈 추가 (0) | 2024.03.28 |
---|---|
JavaScript - 한글 조사 처리 (0) | 2024.03.15 |
NestJS - class-validator 데코레이터 (0) | 2023.09.07 |
NestJS - 네이밍 규칙 (0) | 2023.09.03 |
JavaScript - 구조 분해 할당 (0) | 2023.08.24 |