이펙티브 타입스크립트

이번 북클럽은 이펙티브 타입스크립트로 진행하였다.

각 챕터별로 정리하고 서로 의견을 나눴었다.

 

아이템1 타입스크립트와 자바스크립트의 관계 이해하기

• 타입스크립트는 자바스크립트의 상위객체이다.
• 타입스크립트는 자바스크립트의 런타임 동작을 하는 모델링하는 타입 시스템을 가지고 있으며 런타임 오류를 찾으려고한다
• 자바스크립트에 허용되지만 타입스크립트에 문제가 되는 코드가 있다.

아이템2 타입스크립트 설정 이해하기

• tsconfig를 통해 타입스크립트를 설정해놓는 것이 좋다.
• 아무런 타입을 설정하지않을때에는 “any” 타입으로 선언된다.
• 엄격히 타입을 체크하고 싶다면 strict 설정을 고려해야한다.

아이템3 코드 생성과 타입이 관계없음을 이해하기

• 코드의 오류가 있을때 컴파일에 문제가 있다는 것은 타입 체크에 문제가 있다는 말과 같다.
• 타입 오류가 있더라고 컴파일은 가능하다.

아이템4 구조적 타이핑에 익숙해지기

• 이 챕터를 읽으면서 덕 타이핑과 구조적 타이핑이라는 용어를 처음 알게 되었다.
• 덕 타이핑 :
  • "만약 어떤 새가 오리처럼 걷고, 오리처럼 헤엄치고, 오리처럼 꽥꽥거리면, 그 새를 오리라고 부를 것이다"라는 개념에서 유래했다.
  • 객체가 어떤 타입에 필요한 모든 속성을 가지고 있다면, 그 객체를 해당 타입으로 간주한다.
• 구조적 타이핑: 타입의 구조나 정의에 따라 타입 호환성을 검사하는 방식이다.
• 차이점
  • 구조적 타이핑은 컴파일 시점에 타입 검사를 수행
  • 덕 타이핑은 런타임에 객체의 메서드와 속성을 확인
  • TypeScript는 구조적 타이핑을 사용하지만, 이는 덕 타이핑의 원칙을 컴파일 시점에 적용하는 것으로 볼 수 있음

아이템5 any 타입 지양하기

• 다른 언어나 자료구조에서 any라는 타입은 아주 생소한 타입이다 그럼에도 왜 이런한 단점이 많은 타입이 타입스크립트에 있을까?
• 그건 자바스크립트에서 타입스크립트로 쉽게 넘어오게 하려는 발판같은 역활일것이다.
• 이제 타입스크립트에서 잘 넘어왔다면 발판을 빼고 정확한 타입을 이용해 작업할 필요성이 있다.

아이템 6 편집기를 사용하여 타입 시스템 탐색하기

• 기존에는 vscode편집기 익스텐션을 활용하여 타입 탐색하는 방법을 많이 활용하였고 지금은 cursor편집기를 활용하여 타입을 탐색하여 적용하는 방법을 적극적으로 사용하고 있습니다.
• 그 과정에서 다른 곳에서 쓰는 곳이 있다고 판단되면 파일로 빼서 정리하는 식으로 하고 있습니다

아이템 7 타입의 값들의 집합이라고 생각하기

• 해당 챕터를 통해 유니온 타입과 인터세션 타입이라는 용어를 알게되었다.
• 유니온 타입(Union Type)이란 자바스크립트의 OR 연산자(||)와 같이 'A' 이거나 'B'이다 라는 의미의 타입이다.
• 인터섹션 타입(Intersection Type)은 여러 타입을 모두 만족하는 하나의 타입을 의미한다.

아이템 8 타입 공간과 값 공간의 심벌 구분하기

• 모든 값은 타입을 가지지만 모든 타입은 값을 가지지않습니다.
• 타입 공간만 가지고 있는 타입이 있습니다.
• typeof, this 그리고 많은 다른 연산자들과 키워드들은 타입공간과 값 공간에서 다른 목적으로 사용될 수 있습니다.

아이템 9 타입 단언보다는 타입 선언을 산용하기

• 타입 단언 const alice: Person = { name: "Alice" };
• 타입 선언 const bob = { name: "Bob" } as Person;
• 타입 선언을 이용하면 할당되는 값이 선언된 타입을 맞는지 확인하지만타입 단언은 강제로 타입을 지정하는 것이기 때문에 타입체커는 할당되는 값이 타입을 만족하지 않더라도 오류를 무시한다.

아이템 10 객체 래퍼타입 피하기

• 이 챕터를 읽을때 습관적으로 string을 String으로 선언하던 상황이 종종 떠올랐다 아직 예전에 자바를 할때에 습관이 남아있는거 같았다.

아이템 11 잉여 속성 체크의 한계 인지하기

• 잉여 속성 체크는 오류를 찾는 효과적인 방법이지만 타입스크립트 타입 체커가 수행하는 일반적인 구조적 할당 가능성 체크와 역활이 다르다. 할당의 개념을 정확하게 알아야 잉여 속성 체크와 일반적인 구조적 할당 가능성 체크를 구분할 수 있습니다.

아이템 12 함수 표현식에 타입 적용하기

• 지금도 화살표 함수인줄 알고 있는 함수표현식을 주로 활용하고 사용했었다.
• 함수표현식의 장점
  • 인자전달 : 함수 표현식은 중간 임시 변수에 할당 할 필요없이 함수에 직접 전달할 수 있다.
  • 클로저: 함수가 종료돼도, 렉시컬 스코프의 index와 같은 정보를 유지한다.
  • IIFE :함수와 변수가 전역 스코프에 영향을 미치지 않도록 방지하는 데 사용된다.

아이템 13 타입과 인터페이스의 차이점 알기

• 타입과 인터페이스의 가장 큰 차이점은 병합 가능 여부입니다

interface User {
    name: string;
}

interface User {
    age: number;
}

const user: User = {
    name: 'John',
    age: 30
};
// 인터페이스는 동일한 이름으로 여러 번 선언할 수 있으며, 이 선언들은 자동으로 병합됩니다. 
type User = {
    name: string;
};

type User = {
    age: number;
}; // 오류 발생

// 타입은 동일한 이름으로 여러 번 선언할 수 없으며, 병합되지 않습니다.

아이템 14 타입 연산과 제너릭 사용으로 반복 줄이기

• 같은 코드를 반복하지 말라 (DRY : Don't repeat yourself) 원칙을 타입에도 적용해야 한다
• 타입 인덱싱, extends를 통해 인터페이스 필드의 반복 줄일 수 있음
• 추가로 keyof, typeof, 매핑된 타입을 활용
• 제네릭 타입은 타입을 위한 함수이며 제네릭 매개변수를 제한하기 위해 extends 활용 가능
• Pick, Partial, ReturnType 같은 유틸리티 타입에 익숙해야 함

아이템 15 동적 데이터에 인덱스 시그니처 사용하기

• 가능하다면 인덱스 시그니처 사용을 피하자.
• keys를 알고 있다면 Record 타입 혹은 매핑된 타입 사용을 고려해보자.
• 외부에서 받아오는 것과 같이 keys가 변동될 수 있다면 인덱스 시그니처 사용을 고려해보자.

아이템 16 number 인덱스 시그니처보다는 Array, 튜플, ArrayLike를 사용하기

• 배열은 객체이므로 키(배열에서는 인덱스)는 숫자가 아닌 문자열이다
• 인덱스 시그니처로 사용되는 number 타입은 버그를 잡기 위한 타입스크립트 코드이다
• 인덱스 시그니처에 number를 사용하기보다 Array나 튜플, ArrayLike 타입을 사용하는 것이 좋다

아이템 17 변경 관련된 오류 방지를 위해 readonly 사용하기

• readonly를 사용하면 의도치 않은 변경으로 인한 에러를 방지하고, 런타임 이전에 확인할 수 있다
• readonly와 const는 차이가 있다
• readonly를 써본적이 없는데 나중에 기회가 될때 써보면 좋을거같아요

const test: readonly number[] = [1, 2, 3, 4, 5];
test[0] = 15 // 에러 : 요소를 읽기만 가능

아이템 18 매핑된 타입을 사용하여 값을 동기화하기

• 매핑된 타입을 사용하여 새로운 프로퍼티가 있을 때 인터페이스에 추가를 강제하게 할 수 있다

아이템 19 추론 가능한 타입을 사용해 장황한 코드 방지하기

• 타입 추론이 가능하다면, 타입 구문을 명시하지 않는게 좋다
• 가능한 함수 시그니처에는 타입을 명시하고, 실제 함수의 지역 변수에는 타입 구문을 명시하지 않는다
• 타입 추론이 가능한 경우에도 객체 리터럴과 함수 반환값에는 타입 명시를 고려할 필요가 있다

아이템 20 다른 타입에는 다른 변수 사용하기

• 타입스크립트에서는 변수에 값을 재할당할 때, 변수를 초기화할 때 지정한 타입과 다른 타입의 값을 할당하면 오류가 발생합니다.
• 변수의 값은 바뀔 수 있지만 그 타입은 바뀌지 않아야 한다.

아이템 21 타입 넓히기

• 타입스크립트가 넓히기(type widening)를 통해 상수의 타입을 추론하는 법을 이해해야 한다 (const, as const 등)
• 상수를 사용해서 변수를 초기화할 때, 타입을 명시하지 않으면 타입 체커는 타입을 추론/결정해야 한다.

아이템 22 타입 좁히기

• 타입 좁히기는 타입스크립트가 넓은 타입으로 부터 좁은 타입으로 진행하는 과정을 말한다.
  • dom 요소를 가져와 null 체크
  • instanceof
  • 속성 체크
  • Array.isArray와 같은 내장 함수

아이템 23 한꺼번에 객체 생성하기

• 객체 생성할 때에는 속성을 하나씩 추가해 완성시키지 말자.
• 객체 생성할 때에는 여러 속성을 포함해 한꺼번에 생성하자.
• 객체를 조립할 때에는 스프레드 연산자를 이용하자.

아이템 24 일관성 별칭 사용하기

• 일관성 있는 변수 식별자 사용하기.
• 새로운 변수 별칭보다는 객체 비구조화 고려하기.

아이템 25 비동기 코드에는 콜 백 대신 async 함수 사용하기

• 콜백보다는 프로미스가 코드를 작성하기도 타입을 추론하기 쉽다.
• async 함수는 항상 프로미스를 반환하도록 강제한다.
• async 함수에서 프로미스를 반환하면 또 다른 프로미스로 래핑되지 않는다.

아이템 26 타입 추론에는 문맥이 어떻게 사용되는지 이해하기

• 타입스크립트는 문맥에 따라 타입 추론을 다르게 한다.
• let / const 키워드의 타입 추론은 다르다. const 키워드 사용 시에 더 좁은 타입으로 추론한다.
• const 키워드는 얕은 상수 선언이고 as const 키워드는 깊은 상수 선언이다.

아이템 27 함수형 기법과 라이브러리로 타입 흐름 유지하기

• 타입스크립트에서는 절차형 프로그래밍보다는 함수형 프로그래밍 방식이 더 좋다.
• 타입스크립트의 타입을 잘 추론하기 위해 'Lodash'와 같은 라이브러리를 이용하는 것이 좋다.
• 함수 체이닝을 이용하면 코드의 가독성 또한 좋고 타입의 흐름을 잘 유지할 수 있다.

아이템 28 유효한 상태만 표현하는 타입 지향하기

• 효과적으로 타입을 설계하려면, 유효한 상태만 표현할 수 있는 타입을 만들어 내는 것이 중요하다 느껴졌다.
• 나도 예시코드처럼 state처럼 타입을 선언할경우가 많은데 예시로 준 문제점이 확 와닿았다.
• 유니언형식의 타입 선언을 지향해야겠다고 생각했다.
• 비행기의 기장과 부기장의 예시의 경 이해가 잘되지않았다.

아이템 29 사용할때는 너그럽게, 생성할 때는 엄격하게

• 해당 챕터를 읽어보니 타입 좁히기와 넓히기가 생각났다. 사용할때는 타입 넓히기 형태로 사용하지만 타입을 선언할때는 좁히기로 사용하것이 좋다.
• 유니온 타입은 탑환 타입보다 매개변수 타입에 더 적합하다.
• 타입의 재사용을 위해 느슨한 형태를 도입하는것이 좋다.

아이템30 문서에 타입 정보 쓰지않기

• 주석을 달때 타입적는 것을 피하자 타입정보의 모순이 발생할 수 있다.
• 코드와 주석이 맞지않다면, 둘 다 잘못된 것이다.

아이템 31 타입 주변에 null 값 배치하기

• 한 값의 null 여부가 다른 값의 null 여부에 암시적으로 관련되도록 설계하면 안 된다.
• API 작성 시에는 반환 타입을 큰 객체로 만들고, 반환 타입 전체가 null이거나 null이 아니게 만들어야 합니다.
• 클래스를 만들 때는 필요한 모든 값이 준비되었을 때 생성하여 null이 존재하지 않도록 하는 것이 좋습니다.
• null인 경우가 필요한 속성은 프로미스로 바꾸면 안됩니다. 왜냐하면모든 메서드를 비동기로 바꿔야 하기 때문입니다.

아이템 32 유니온의 인터페이스보다는 인터페이스의 유니온 사용하기

• 인터페이스 구현 시 속성간의 관계를 분명, 세부화하게 나타내야합니다.
• 태그된 유니온은 런타임 타입 체커와 잘 맞기 때문에 필요 시 사용해야합니다.
• 각 타입의 속성들 간 관계를 제대로 모델링하면 코드의 정확성 업, 오류 다운

아이템 33 string 타입보다 더 구체적인 타입을 사용하기

• 문자열을 남발하여 선언된 코드를 피해야 합니다. string 타입보단 구체화된 타입을 사용하는 것이 좋습니다.
• 문자열 리터럴 타입의 유니온을 사용해 타입 체크를 엄격히 하도록 해야합니다
• 객체의 속성 이름을 매개변수로 받을 때는 keyof 를 사용하는 것이 좋습니다.

아이템 34 부정확한 타입보다는 미완성 타입을 사용하기

• 타입 선언을 작성하다 보면 코드의 동작을 좀 더 구체적으로 또는 덜 구체적으로 모델링하게 되는 상황을 맞닥뜨리게 됩니다. 일반적으로 타입이 구체적일수록 버그를 더 많이 잡아내고 타입스크립드 언어 지원을 더욱 많이 받습니다.
• 타입을 정확하게 모델링 하지 못하면, 부정확하게 모델링 하지 말아야합니다.
• any와 unknown을 구별할 줄 알아야합니다.

아이템 35 데이터가 아닌, API와 명세를 보고 타입 만들기

• 잘 설계된 타입은 타입 스크립트 사용을 즐겁게 해주는 반면, 잘 못 설계한 타입은 비극을 불러온다.
  • 이번 SCM QA를 하면서 타입에러로 인한 이슈가 2개 정도 있더라구요. 타입을 잘 설계해야된다는걸 한번 더 느꼈습니다.
• 코드의 구석 구석까지 타입 안전성을 얻기 위해 API 또는 데이터 형식에 대한 타입 생성을 고려해야 한다.
• 데이터에 드러나지 않는 예외적인 경우들이 문제가 될 수 있기 때문에 데이터보다는 명세로부터 코드를 생성하는 것이 좋다.

아이템 36 해당 분야의 용어로 타입이름 짓기

• 모호하고 의미 없는 이름은 피하고 의미적으로 구분이 되는 이름으로 타입이름을 짓는것이 좋다.
• 가독성을 높이는 방법을 사용하고 추상화 수준을 높이기 위해 해당 분야의 용어를 사용해야한다.
  • 저도 추상화등을 통해 타입명을 지정할때 name, label, content등을 자주 사용했는데 이부분은 배워야 할거 같습니다.

아이템37 공식 명칭에는 상표 붙이기

• 공식 명칭에 상표를 붙이는 건 특이한거 같다. string등 타입을 선언한 곳에서 ‘2D’라는 브랜드 타입을 선언해 사용하는 방식은 처음 보는거 같다.
• number등에 상표 타입도 신기한 기능인거 같지만 사용도는 떨어져 보인다.
• 타입스크립트는 값을 세밀하게 구분하지 못하는 경우가 있으므로 공식 명칭이 필요하다면 상표를 붙여보자.
• 상표 기법은 타입 시스템에서 동작하지만 런타임에 상표를 검사하는 것과 동일한 효과를 얻을 수 있다.

아이템 38 any 타입은 가능한 한 좁은 범위에서만 사용하기

• as string은 종종 사용하던 단언문이였는데 as any에 대해서는 상황에 맞게 쓸지 잘 고려해야 한다는 것을 알았다.

const config: Cofig = {
a:1,
b:2,
c: { 
	key:valve
	}
} as any // Bad

----------------------------------------------------

function f2(){
const x = expressinRerueningFoo();
processBar(x as any) // Good

아이템 39 any를 구체적으로 변형해서 사용하기

• any는 자바스크립트에서 표현할 수 있는 모든 값을 아우르는 매우 큰 범위의 타입
• any 타입은 모든 숫자, 문자열, 배열, 객체, 정규식, 함수, 클래스, DOM 엘리먼트, null과 undefined까지 포함
• 하지만 any를 활용해 정규식이나 함수를 넣는건 권장하지않는다.
• any를 쓰더라도 any[] / () ⇒ any / [{id:string}:any] 형식등 구체적인 형태로 사용해야한다.

아이템 40 함수 안으로 타입 단언문 감추기

• 불필요한 예외 상황까지 고려해 가며 타입 정보를 구성하기보다, 타입 단언을 사용해서 외부로 드러나는 타입 정의를 간단하게 유지하자
• 프로젝트 전반에 타입 단언을 사용하지 말고 정확한 타입을 가진 함수 안에서 타입 단언을 감추자

아이템 41 any의 진화를 이해하기

• 다음 챕터중 제일 흥미로웠던 구간이였다. 지금까지 처음 any를 선언한 타입에 대해서 특정 값을 집어 넣어도 any을 유지하고 있는줄 알았다.
• 하지만 any타입은 변수에 특정 값을 넣으면 값에 따라 타입을 변하는 것을 이번 챕터를 통해 확인했다. 왜 any타입을 지양하는지 이 챕터를 통해 좀 더 명확하게 알게 되었다.
• any를 사용하면 변수 값에 따라 진화하기 때문에 타입의 명확한 추론이 불가능하고 null등을 값을 넣어도 이 변수는 any타입이 아니기 때문이다.
• any대신 명시적 타입을 넣어서 타입을 선언해 개발하자

아이템 42 모르는 타입의 값에는 any 대신 unknown을 사용하기

• 어떠한 타입이든 any 타입에 할당 가능하다. any타입은 어떤한 타입으로도 할당 가능하다.
• 어떠한 값이 있지만 그 타입을 알지 못하는 경우라면 unknown을 사용하면 된다.
• unknown 타입엔 모든 자료 다 집어넣을 수 있지만 그 값을 맞지 않게 활용하면 타입 에러가 발생한다.
  • 진화하지 않은 any 라고 생각하면 편할거 같다.
• 반대 값인 never도 있다.Never 타입은 모든 타입의 하위 타입이며 어떤값도 never에 할당할수 없다.
• never 타입이 사용되는 경우
  • 함수가 아무것도 반환하지 않을 때 -> never 를 반환타입으로 지정하여 타입추론 예외를 제거한다.
  • 특정 타입 값을 할당받지 못하게 할 때 사용한다.

아이템 43 몽키 패치보다는 안전한 타입을 사용하기

• 전역 변수 사용을 지양하고, DOM에 데이터를 저장하면 안된다
• 내장 타입에 데이터를 저장해야 하는 경우, 안전한 타입 접근법 중 하나를 사용한다
  • interface의 특수 기능을 활용하여 타입 보강
  • 확장하는 인터페이스를 만들고 구체적인 타입 단언문 사용

아이템 44 타입 커버리지를 추적하여 타입 안전성 유지하기

• noImplicitAny를 설정하고 모든 암시적 any 대신 명시적 타입 구문을 추가해도 any 타입이 여전히 프로그램 내에 존재할 수 있다.
• any 타입은 타입 안정성과 생산성에 부정적 영향을 미칠 수 있으므로 프로젝트에서 any의 개수를 추적하는 것이 좋다

아이템45 devDependencies에 typescript와 @types 추가하기

• dependencies: 현재 프로젝트를 실행하는 데 필수적인 라이브러리
  • npm에 공개하여 다른 사람들이 설치한다면 라이브러리가 함께 설치됨 → 전이 의존성
• devDependencies: 현재 프로젝트를 개발하고 테스트하는 데 사용되지만, 런타임에는 필요 없는 라이브러리
  • npm에 공개하여 다른 사람들이 설치한다면 라이브러리 설치가 제외됨
• peerDependencies: 런타임에 필요하긴 하지만, 의존성을 직접 관리하지 않는 라이브러리들이 포함된다.

타입스크립트를 프로젝트의 devDependencies에 포함시키고 팀원 모두가 동일한 버전을 사용하도록 해야합니다.

@type 의존성은 dependencies 이 아니라 devDependencies에 포함시켜야 합니다. 런타임에 @type가 필요한 경우라면 별도의 작업이 필요할 수 있습니다.

아이템46 타입 선언과 관련된 세 가지 버전 이해하기

• 타입선언 관련 3가지 버전
  • 라이브러리의 버전
  • 타입 선언(@types)의 버전
  • 타입스크립트의 버전

라이브러리를 업데이트하는 경우, 해당 @types 역시 업데이트해야 한다.

TS로 작성된 라이브러리 : 타입 선언을 자체적으로 포함

JS로 작성된 라이브러리 : DefinitelyTyped에 타입 선언을 공개하여 커뮤니티 차원에서 유지 보수

아이템47 공개 API에 등장하는 모든 타입을 익스포트하기

퍼블릭 API에 코드가 노출되면 타입을 추출하는 방법은 무궁무진하다

따라서 사용 편의성을 위해 가능한 모든 타입을 export 해주는 것이 좋다

아이템48 API 주석에 TSDoc 사용하기

JSDoc / TSDoc 형태의 주석을 작성하면 에디터에서 주석 정보를 제공해준다

대부분의 에디터에서 함수에 붙은 JSDoc 스타일의 주석을 툴팁으로 표시해 준다

@params, @returns 구문과 문서 서식을 위해 마크다운을 사용할 수 있다

아이템49 콜백에서 this에 대한 타입 제공하기

콜백 함수에서 this를 사용해야 한다면, 타입 정보를 명시해야 한다. this는 동적 스코프(호출된 방식에 따라 값이 달라진다)라 예상하기 어렵기 때문이다.

아이템50 오버로딩 타입보다는 조건부 타입 사용하기

오버로딩 타입보다 조건부 타입을 사용하는 것이 좋다. 조건부 타입은 추가적인 오버로딩 없이 유니온 타입을 지원할 수 있기 때문이다.

아이템 51 의존성 분리를 위해 미러 타입을 사용하기

미러링이란, 필요한 선언부만 추출하여 작성 중인 라이브러리에 넣는 것을 말한다. 구조적 타이핑을 응용한 것이다.

즉, 필수가 아닌 의존성을 분리할 때는 구조적 타이핑을 사용하면 된다.

미러 타입으로 작성해줘야할 부분이 많다면 그냥 의존성(@types)을 추가해주는 게 낫다.

아이템 52 테스팅 타입의 함정에 주의하기

타입을 테스트할 때는 특히 함수 타입의 동일성과 할당 가능성의 차이점을 알고 있어야 한다. (구조적 타이핑)

 

아이템53 타입스크립트 기능보다는 ECMAScript 기능을 사용하기

자바스크립트의 기능만을 이용하는 것이 아니라 타입스크립트 팀 내에서 독립적으로 개발했던 내장 기능들이 있었다고 한다. 하지만, 자바스크립트의 발전에 따라 신규 기능이 나오게 되면서, 타입스크립트 내에서 사용하는 기능과 호환성에 문제가 생기게 된 것이다.

이에 따라 타입스크립트 개발 팀은, 타입 기능만 발전시키는 것과, 런타임 기능을 발전시키는 것에 집중하여 일하고 있다고 한다. 하지만 이러한 원칙을 세워서 개발하기 전에 이미 사용되고 있던 자바스크립트와 혼동할 수 있는 기능들이 있어서, 이들의 사용을 지양하기 위하여 몇가지 정리해 둔 것이 있다

• 열거형
  • 단순히 값을 나열하는 것보다 실수가 적고 명확하기 때문에 일반적으로 열거형을 사용하는 것이 좋다.
• 매개변수 속성
  • 일반적으로 클래스를 초기화할 때, 속성을 할당하기 위하여 생성자의 매개변수를 사용해야 한다.
• 네임스페이스, 트리플 슬래시 임포트 지양
  • ESMAScript 2015 이후, 모듈이 새로 도입되었다
  • 트리플 슬래시와 네임스페이스 키워드는 사용하는 것을 지양한다.
• 데코레이터
  • 앵귤러 프레임워크를 지원하기 위해서 만들어진 것인데, 현재까지도 표준화 상태가 들쭉날쭉하다. 그래서 호환성이 깨질 가능성이 있으므로 타입스크립트에서 이는 되도록 사용하지 말자.

아이템54 객체를 순회하는 노하우

• 타입 안정성
  • Object.keys, entries, values는 기본적으로 타입 안정성이 부족
  • 적절한 타입 단언이나 유틸리티 함수 사용 필요
• for-in 루프 사용시 주의사항
  • 프로토타입 체인의 속성도 포함될 수 있음
  • hasOwnProperty 체크 필요

아이템55 DOM 계층 구조 이해하기

EventTarget → Node → Element → HTMLElement로 이어지는 계층 구조 파악하고 각 계층이 제공하는 기능과 특성 이해하면 좋다. 타입스크립트의 DOM 타입 시스템 활용

아이템56 정보를 감추는 목적으로 private 사용하지 않기

• TypeScript의 private은 정보 은닉을 위한 완벽한 해결책이 아닙니다 private이 필요한 경우 JavaScript의 private 필드(#) 또는 클로저 사용하는 하는 것이 좋습니다.
• private은 캡슐화와 코드 구조화를 위한 도구로 활용합니다.
• 보안이 필요한 정보는 반드시 서버 측에서 관리합니다.

아이템57 소스맵을 사용하여 타입스크립트 디버깅하기

소스맵은 TypeScript 디버깅의 필수 도구입니다. 개발 환경에서는 반드시 활성화하여 사용하는 것이 좋습니다. 다만 프로덕션 환경에서는 보안을 고려하여 설정 합니다. 적절한 도구와 설정으로 효율적인 디버깅 가능하며 빌드 프로세스와의 통합 고려가 필요합니다.

 

아이템58 모던 자바스크립트로 작성하기

모던 자바스크립트는 const/let 키워드, 화살표 함수, 구조 분해 할당, 전개 연산자, 옵셔널 체이닝, async/await 등의 새로운 문법을 제공한다. → 예전에 자바스크립트 ES6 프론트 면접볼때 해당 키워드들 장담점등을 공부할때가 생각나네요

아이템59 타입스크립트 도입 전에 @ts-check와 JSDoc으로 시험해 보기

타입스크립트 도입 전에 @ts-check와 JSDoc을 활용하면 기존 자바스크립트 코드에 점진적으로 타입 체크를 도입할 수 있다. 이는 코드베이스를 직접 수정하지 않고도 타입 안정성을 확보할 수 있게 해주며, VSCode와 같은 에디터에서 즉각적인 타입 체크 피드백을 받을 수 있다.

아이템60 allowJS로 타입스크립트와 자바스크립트 같이 사용하기

allowJS 컴파일러 옵션을 활성화하면 타입스크립트 프로젝트 내에서 자바스크립트 파일을 함께 사용할 수 있으며, 이는 점진적인 마이그레이션을 가능하게 한다.

이 옵션은 checkJS와 함께 사용하면 자바스크립트 파일에 대한 타입 체크도 수행할 수 있어, 기존 자바스크립트 코드의 타입 안정성도 확보할 수 있다.

따라서 대규모 자바스크립트 프로젝트를 타입스크립트로 전환할 때, 파일 단위로 점진적 마이그레이션이 가능하며 이는 실무에서 매우 실용적인 접근 방식이다.

아이템61 의존성 관계에 따라 모듈 단위로 전환하기

타입스크립트로의 전환은 의존성이 가장 적은 최하위 모듈부터 시작하여 점진적으로 상위 모듈로 진행하는 것이 효과적이다.

이러한 상향식(bottom-up) 접근 방식은 의존성 그래프의 말단부터 변환을 시작함으로써, 각 단계에서 발생할 수 있는 문제를 최소화하고 안정적인 마이그레이션을 가능하게 한다.

또한 의존성 관계를 고려한 전환은 테스트와 검증이 용이하며, 프로젝트의 위험을 분산시키면서 점진적으로 타입 안정성을 확보할 수 있다.

아이템62 마이그레이션의 완성을 위해 noImplicitAny 설정하기

noImplicitAny 설정은 타입스크립트 마이그레이션의 최종 단계로, 모든 타입을 명시적으로 선언하도록 강제하여 타입 안정성을 최대화한다.

초기 마이그레이션 단계에서는 이 설정을 비활성화하여 점진적 전환을 용이하게 하고, 기본적인 마이그레이션이 완료된 후 활성화하는 것이 권장된다.

이 설정을 활성화함으로써 암시적 any 타입을 방지하고, 타입스크립트의 강력한 타입 체크 기능을 완전히 활용할 수 있으며, 이는 코드의 안정성과 유지보수성을 크게 향상시킨다.

 

마무리

이런 개발서적은 처음부터 끝까지 정독해본건 처음이였던거 같다. 보통 필요한 부분만 읽고 적용해보거나 테스트 해보는게 다인데 저번에 북클럽을 진행하면서 읽었던 애자일책과는 또 다른 느낌이였다

책을 읽으면서 부족했던 타입에 대해 자세히 알게 되고 실제 코드에 적용해봐서 좋았던거 같다.