이 게시물은 SW 마에스트로 연수생 간 진행한 Effective Typescript 스터디의 개인 정리 내용입니다
Typescript 타입계층도
[ Item 01 ] TS 와 JS 의 관계 이해하기
“타입스크립트는 자바스크립트의 상위 집합이다”
모든 자바스크립트 프로그램은 타입스크립트 라는 명제는 항상 성립하지만
그 반대의 경우인 모든 타입스크립트 프로그램은 자바스크립트 프로그램 이라는 명제는 성립하지 않습니다.
이와 같은 문제가 발생하는 이유는 타입스크립트의 가장 큰 특징인 타입 명시 문법 때문입니다.
초기의 JavaScript 는 간단한 기능을 구현하기 위해 만들어진 언어였습니다.
그렇기에 느슨한 타입 관계가 간단한 기능 구현에 들어가는 공수를 크게 줄여 주었죠.
하지만 현재의 JavaScript는 초기의 의도와 다르게 복잡한 기능들을 수행하면서 간단한 기능을 구현할 때 강점이었을 느슨한 타입 관계가 복잡한 기능을 구현해야 하면서 반대로 단점으로 작용하게 되었습니다.
따라서 타입스크립트는 정적 타입 시스템을 통해 코드 작성 과정에서 코드들을 의도한 대로 동작하도록 돕고 런타임에서 발생 할 수 있는 오류를 미리 찾아 가이드 해주어 작업을 도와줍니다.
결론
구구절절 얘기하긴 했으나, 해당 Item 의 골자는 TS가 JS보다 더욱 큰 범위에 존재하는 집합이라는 점입니다.
추후에 다시 나올 개념이겠지만 타입을 집합이라고 생각하고 타입계층도를 보시면 조금 더 이해가 쉽습니다!
[ Item 02 ] TS 설정 이해하기
“협업을 위해서라면 컴파일러 설정을 동료와 통일하라”
프로젝트에 TS 를 도입 할 예정이라면, 컴파일러 설정을 동료 개발자들과 통일해야만 합니다.
본문에서는 noImplicitAny, strictNullChecks 와 같은 설정만큼은 체크하고 넘어가길 추천합니다.
결론
사실 이 아이템은 대단한 내용이 아닌 TS 로 협업을 할 것이라면 거의 필수적이라 볼 수 있는 두가지 옵션에 대해서 설명하는 느낌이 강한 아이템이었습니다.
추후 프로젝트에 들어가도 해당 설정들만큼은 체크하고 넘어갈만한 가치가 있다고 생각합니다.
[ Item 03 ] 코드생성과 타입이 관계없음을 이해하기
타입스크립트 컴파일러는 다음과 같은 기능을 수행합니다
- 최신 ts, js 프로그램을 브라우저에서 동작할 수 있도록 구버전 js 로 transpile해주기
- 코드의 타입 오류 체크
여기서 이 두 기능은 완벽히 독립적이어서 다음 두가지 항목으로 대치됩니다.
- 타입 오류가 있더라도 컴파일이 가능하며
- 분명 타입 추론을 통해 string type 이 설정되었을 x 변수에 1234 가 할당되며 타입 에러를 반환하지만, 컴파일이 가능하며 컴파일을 통해 나온 js 코드가 정상적으로 작동합니다.
- 사실 C나 Java 에 비해서는 엉성? 하다고 느낄 수 있지만, 오류를 수정하지 않더라도 다른 부분들을 테스트해볼 수 있는 등 실제로 도움이 되는 부분이 있다고 합니다.
- 근데 개인적인 느낌으로는 변명같….기도 합니다 오류가 발생한 부분을 수정하지 않고 다른 부분들을 테스트해보는게 의미가 있을까요?
- 런타임에서의 타입 체크는 불가능합니다
- 함수 안에서의 instanceof 체크는 런타임에서 일어나지만 타입이기 때문에 런타임 시점에는 제거되며 컴파일 하더라도 빈칸으로 남게 된다.
여기서 타입 오류가 있음에도 컴파일이 가능한 문제를 우회하기 위해 두 가지 방법을 제안합니다.
- 타입 정보를 명시적으로 저장하는 태그 기법
- 타입을 클래스로 만드는 방법
결론
논지는 타입 체크와 트랜스파일링이 분리되어 진행된다는 점입니다.
따라서 타입시스템은 스크립트 동작이나 성능에는 영향을 주지 않습니다.
[ Item 04 ] 구조적 타이핑에 익숙해지기
JS 는 기본적으로 추론을 통한 객체를 해석하는 덕타이핑 기반입니다.
이런 저런 예제들을 통해서 이러한 덕타이핑 기반의 위험성을 설명합니다.
특히 calculateLength 함수 예제에서 함수를 작성할 때 호출에 사용되는 매개변수의 속성들이 매개변수의 타입에 선언된 속성만을 가질 것이라 기대하기 쉽지만,
이것을 우리는 ‘봉인된’, ‘정확한’ 타입이라고 칭하며 타입스크립트 시스템은 아쉽게도 Open 타입을 가지고 있어서 타입 확장에 제한을 두지 않습니다.
[ Item 05 ] Any 타입 지양하기
ANY 사.용.하.지.마
any 를 사용했을 때 발생 할 수 있는 문제는 다음과 같습니다.
- 타입 안전성을 보장하지 못하며
- 함수 시그니처를 무시해버린다
- 언어서비스를 제공받지 못해 생산성의 저하로 이어진다
- 리팩터링 때 버그를 감춰버린다
- any 타입을 설정한다면 분명 많은 부분에서 타입체크를 통과 할 수 있을 것이다. 하지만 런타임에서는 오류가 발생할 것
- 타입 설계를 감춰버린다
- 타입시스템의 신뢰도를 떨어뜨린다
결론
여기서 모든 문제를 관통하는 문제는 타입시스템의 신뢰도를 떨어뜨린다는 점인 것 같습니다.
타입시스템은 분명 JS만을 사용할 때 보다 단순 코드 작성에는 조금 더 품이 들어가는게 사실이지만, 코드를 의도에 맞게 동작하도록 하여 타입 체크 과정에서 빠르게 오류를 확인해 볼 수 있는데에서 의의를 갖습니다.
하지만 any 타입을 사용한다면 런타임 과정에서 발생하는 오류에 대처하기 어려워지고, 따라서 다른 올바르게 사용한 타입들에 대한 신뢰도마저도 떨어져 코드품질의 저하로 이어진다.
그때 그때 쌓이는 설거지를 처리하는 마음으로 타입 할당을 신경써서 해주자.