LearningTS Chapter 1 - YDP-SPLOUNGE-CLUB/typescript-study GitHub Wiki

1.2 바닐라 자바스크립트의 함정

중요한 언어 확장이나 프레임워크 없이자바스크립트를 사용하는 것을 바닐라 라고 부른다. 순수한 자바스클비트를 의미한다. 타입스크립트가 자바스크립트에 있는 주요 함정을 극복하기 위해 적절한 기능을 추가한 이유를 이 책에서 설명한다.

이러한 모든 약점은 프로젝트 규모가 커지고 장기화될수록 더욱 드러난다.

1.2.1 값 비싼 자유

JS를 사용하는 개발자들의 큰 불만은 핵심 기능에 있다. JS는 사실상 코드를 구성하는 방법에 제한이 없다. 이러한 자유 덕분에 프로젝트를 자바스크립트로 시작하면 매우 재미있다.

그러나 파일이 늘어날수록 그 자유가 얼마나 훼손될 수 있는지 명확해진다. 가상의 페인팅 애플리케이션 코드의 일부분이다.

function paintPating(painter, painting) {
    return painter
        .prepare()
        .paint(painting, painter.ownMaterials)
        .finish();
}

아무런 맥락도 없이 코드를 읽게 되면 paintPainting 함수를 호출하는 방법에 대해 막연히 생각만 하게 될 것이다.

혹은 코드베이스와 관련된 작업을 한 적이 있다면 어떤 함수로 반환되어야 하는지 기억하고 있을지도 모른다.

그러나 앞선 가정이 정확하더라도 나중에 코드를 변경하면 이 가정은 무효가 될지도 모른다.

문자열이었던 painting이 다른 데이터 타입으로 변경되거나 하나 이상의 painter 메서드 이름이 변경되었을 수도 있다.

다른 언어는 컴파일러가 충돌할 수 있다고 판단하면 코드 실행을 거부할 수 있다.

자바스크립트는 충돌 가능성을 먼저 확인하지 않고 코드를 실행하는 동적 타입 언어는 그렇지 않다.

코드의 자유는 자바스크립트를 재미있게 만들기도 하지만 코드를 안전하게 실행하려고 할 떄는 상당한 고통을 안겨준다.

1.2.2 부족한 문서

자바스크립트 언어 사양에는 함수의 매개변수, 함수 반환, 변수 또는 다른 구성 요소의 의미를 설명하는 표준화된 내용이 없다.

개발자가 블록 주석으로 함수와 변수를 설명하는 JSDoc 표준을 채택한다.

/**
 * @param {Painting} painter
 * @param {string} painting
 */

JSDoc 에는 다음과 같은 주요 문제로 인해 규모가 있는 코드베이스에서 사용하기 불편하다.

• JSDoc 설명이 코드가 잘못되는 것을 막을 수 없다.
• 설명이 이전에는 정확했더라도 코드 리팩터링 중에 생긴 변경 사항과 관련된 현재 유효하지 않은 JSDoc 주석을 모두 찾기 어렵다.
• 복잡한 객체를 설명할 때는 다루기 어렵고 장황해서 다수의 주석이 필요하다.

수십 개의 파일에서 JSDoc 주석을 유지 관리는 많은 시간이 걸리지 않겠지만 수백 또는 수천 개의 파일을 꾸준히 업데이트 하려면 쉽지 않다.

1.2.3 부족한 개발자 도구

JS 타입을 식벽하는 내장된 방법을 사용하지 않고 코드가 JSDoc 주석에서 쉽게 분리되기 떄문에 코드베이스에 대한 대규모 변경을 자동화하거나 통찰력을얻기가 어렵다.

1.3 타입스크립트

타입스크립트는 2010년대 초에 마이크로소프트 내부에서 만들어진 후 2012년에 출시 및 오픈 소스화 되었다.

타입스크립트는 네 가지로 설명된다.

• 프로그래밍 언어: 자바스크립트의 모든 구문과 타입을 정의하고 사용하기 위한 새로운 타입스크립트 고유 구문이 포함된 언어
• 타입 검사기: JS, TS 로 작성된 일련의 파일에서 생성된 모든 구성 요소를 이해하고 잘못 구성된 부분을 알려주는 프로그램
• 컴파일러: 타입 검사기를 실행하고 문제를 보고한 후 이에 대응되는 자바스크립트 코드를 생성하는 프로그램
• 언어 서비스: 타입 검사기를 사용해 VS Code 와 같은 편집기에 개발자에게 유용한 유틸리티 제공법을 알려주는 프로그램

1.4 타입스크립트 플레이그라운드

생략

1.5 로컬에서 실행하기

생략

1.6 타입스크립트에 대한 오해

TS가 얼마나 훌륭한지는 알지만 제약이 있다.

1.6.1 잘못된 코드 해결책

TS는 JS코드를 구조화하는 데 도움이 되지만, 타입 안정성 강화를 제외하고는 해당 구조가 어떻게 보여야 하는지에 대해서는 어떤 것도 강요하지 않는다. 매우 좋은 특징이다.

모든 개발자가 사용할 수 있는 프로그래밍 언어이다. JS 의 아키텍처 패턴 중 ㅁ웟이든 사용 가능하다. 타입스크립트는 이를 지원한다.

1.6.2 자바스크립트로의 확장

TS 설계 목표는 이렇다.

• 현재와 미래의 ECMA 스크립트 제안에 맞춘다.
• 모든 자바스크립트 코드의 런타임 동작을 유지한다.

타입스크립트는 자바스크립트의 작동 방식을 전혀 변경하지 않는다.

1.6.3 자바스크립트보다 느림

떄로는 인터넷 속 익명의 개발자가 런타임에서 자바스크립트보다 느리다고 불평하는 걸 듣게 될지도 모른다. 이 주장은 부정확하고 오해의 소지가 있다.

타입스클비트가 코드에 적용하는 유일한 변경 사항은 인터넷 익스플로어 11과 같이 오래된 런타임 환경을 지원하기 위해 이전 버전의 자바스크립트로 코드를 컴파일하도록 요청하는 경우이다.

운영 프레임워크 대다수는 타입스크립트의 컴파일러를 전혀 사용하지 않는다. 대신 트랜스파일을 위한 별도의 도구를 사용하고 타입스크립트는 타입 검사용으로만 사용한다.

그러나 타입스크립트는 코드를 빌드하는 데 시간이 조금 더 걸린다. 타입스크립트 코드는 브라우저나 Node.js 와 같은 환경에서 실행되기 전에 자바스크립트로 컴파일되어야 한다.

빌드 파이프라인은 대부분 성능 저하를 무시하도록 설정된다. 코드에서 발생할 수 있는 오류를 분석하는 느린 타입스크립트 기능은 실행 가능한 애플리케이션 코드 파일을 생성하는 것과는 분리된 채로 수행된다.

1.6.4 진화가 끝남?

웹의 진환느 끝나지 않았고 타입스크립트도 마찬가지다. 타입스크립트 버그 수정과 기능 추가는 지속적으로 이루어진다.