타입스크립트를 실무에서 사용한다면? ‘이펙티브 타입스크립트’ 후기

작성 : 2024-06-06수정 : 2024-06-06

목차 펼치기

 출처 : yes24 - 이펙티브 ��타입스크립트

출처 : yes24 - 이펙티브 타입스크립트


머리말

타입스크립트 핸드북

이나

<러닝 타입스크립트 - 조시 골드버그 저 / 고승원 역>

을 읽고 나서 다음으로 읽어봐야지, 했던 책이었다. 러닝 타입스크립트가 전반적인 개념에 대해 설명해주는 책이라면, 여기서는 타입스크립트의 동작을 설명하고 실제로 사용하면서 유의하면 좋을 것들에 대해 알려준다.


후기

타입스크립트의 타입 시스템에서부터 타입 추론과 설계, 선언과 any 등에 대한 저자의 조언은 대부분 흥미로웠으며, 짧은 길이의 섹션들로 이루어져있어 읽는 동안 지루하지 않았다. 그 중 인상 깊은 몇 가지는 다음과 같았다.

  • enum 대신 리터럴 유니온을 사용한다.

  • 유니온 인터페이스보다는 인터페이스의 유니온을 사용한다.

    • 이를 이용한 태그된 유니온 패턴은 내가 타입스크립트에서 제일 좋아하는 패턴이다.

  • 타입 선언에는 유틸리티 타입을 활용해서 최대한 중복을 제거한다.

    • Pick, Omit, Partial, Required, Readonly, ReturnType, Record …

  • 타입 추론이 된다면 명시적 타입 구문은 필요하지 않다.

    • 이전에는 최대한 타입을 명시하는 것이 좋다고 생각했었는데, 타입 추론이 가능한 일부 상황에서는 굳이 명시하지 않는 것이 코드가 깔끔해질 수 있다고 생각되었다.

  • 함수 선언문보다는 표현식을 사용한다.

    • 함수 타입을 선언하고 재사용할 수 있기 때문이다.


특히 책의 전반부에서는 타입스크립트의 타입 오류는 실제 런타임 환경에 영향을 주지 않는다는 내용에 대해서 많이 다루는데, 타입 구문 오류와 런타임 오류가 구분되는 것을 명확히 알고 있어야 개발 과정에서 맞닥뜨릴 문제를 디버깅 할 때 유리하다고 생각한다.


타입을 선언하는 두 가지 방법인 type과 interface의 차이에 대해 설명해주며, 대부분의 경우 같이 사용될 수 있기 때문에 프로젝트에서 일관성을 유지해야하는 것을 강조한다. 책에서는 API에 대한 타입은 interface, 프로젝트 내부적으로 사용되는 타입은 type을 사용하는 것에 대해 설명하지만, 이는 프로젝트 컨벤션에 따라 많이 달라질 수 있는 내용이라 생각한다.


개인적으로 타입스크립트를 사용하면서 명시적 타입 선언만 사용해도 잠재적 오류를 줄이고 유지보수를 원활히 하는 데 도움이 된다고 생각한다. 하지만 타입스크립트를 활용한다는 것은 다른 문제다. 잘 만들어진 라이브러리들의 @types를 보면 아연할 때도 있다. 제너릭을 활용해 정적인 유연함을 구현하는 방법들도 여전히 신기하다. 마치 레고로 세상의 모든 것을 만들어내는 사람들을 보는 것만 같다.


타입 시스템을 잘 쓰는 것은 참 어렵다. 여기에는 경험이 매우 중요한 부분이라고 생각하며, 이런 책들을 통해 직접 실전에서 경험해보지 못했음에도 불구하고 경험치를 쌓을 수 있었다. 타입스크립트의 기초에 대해서도 다 읽었고, 직접 사용하기도 시작했다면 이 책을 추천드릴 것 같다.


Wanna get in touch?

All Icons byiconiFy