Week 2: TypeScript & Clean Code

with 코멘토

1. JS to TS

1.1 JS의 짧은 역사

• 브라우저를 위한 스크립팅 언어로 탄생: 웹 페이지 속 짧은 코드들로 사용할 것이기 때문에
• 그런데, JS가 발전하면서 웹이 아닌 다른 용도에서도 사용되기 시작
• 자바스크립트의 장점이었던 '동적타입'이 오히려 의도치 않은 버그를 발생키는 현상이 생김

1.2 타입스크립트 장점

• 프로그램 실행(런타임) 전에 type chekcing을 통해 프로그램의 오류를 찾아준다.
• 자바스크립트 오류를 잡아줄 뿐만 아니라, 사용자의 일부 실수(오타)를 잡아주는 역할도 해준다
• 타입 오류가 컴파일시 발견되고, 코드의 양이 많을 때 비교적 생산성이 높다.
• 코드들이 타입으로 연결되어 있어서 연관된 코드간의 이동이 쉽다.
• 변수명/함수명을 리팩토링도 용이하고, 함수의 parameter, return value 타입을 확인할 수 있다.
• MS 개발해서 꾸준한 업데이트 버전이 등장하고, Vscode에서 지원이 좋다
• 튜토리얼이 잘 되어있다(문서 한들화, 기본기부터 고급 기능까지)

2. 기본문법

2.1 any

• 학습 초반에는 오히려 타입을 지정해서 수월하게 개발을 진행하고, 차츰 개선해 나가는 방법도 좋다
• 알지못하는 타입을 표현할 때
• 사용자로부터 받은 데이터
• 서드 파티 라이브러리 같은 동적인 컨텐츠

2.2 null and undefined

• null ,undefined는 모든 타입의 하위 타입
• 다른 타입과 함께 유니온 타입으로 정의할 때 많이 쓰인다.
• stirctNullChecks를 사용하면 null/undefined는 오직 any와 각자 자신들 타입에만 할당 가능

2.3 함수

• 파라미터에 타입, 리턴값에 타입이 추가된다

2.4 interface

• 타입체크를 위해 사용되며 변수, 함수, 클래스에 사영된다
• 여러가지 타입을 갖는 property로 이루어진 새로운 타입을 정의하는 것과 유사하다
• optional properties, readonly properties, union type 적용 가능

2.5 interface vs type

1. interface는 property 확장/추가가 가능하고 type은 안된다.
2. interface는 하나의 형태로만 사용 가능하다. 타입은 unioi or tuple로 사용 가능하다

2.6 enum vs union

• enum은 타입스크립트에서 자체적으로 구현하는 기능이다
• enum같은 경우는 트랜스파일링 될 경우 JS Object로 변환된다.

2.7 mini practice

• 서버에서 받는 데이터의 경우 조금 더 범용적으로 작성하는게 좋다
• 대부분의 경우 데이터의 깊이가 깊은편은 아니다.
• 또한 데이터의 구조가 바뀔 가능성도 크기 때문에 보다 General하게 작성해서 변화에 대응하는게 좋다

// Me
export type ClassStatus = "모집전" | "모집중" | "모집완료";

export interface CommonCamp {
  title: string;
  startDate: Date; //string?
}

export interface HotCamp extends CommonCamp {
  status: ClassStatus;
}

export interface SaleCamp extends CommonCamp {
  job: string;
  field: string;
}
  

// Mentor
// TODO: 실제 프로젝트보고 수정할수도 있음
export interface Camp {
  id: number;
  type: "popular" | "discount";
  status: ClassStatus;
  category?: string;
  skill?: string;
  campName: string;
  thumbnail: string;
  dateStart: string;
}

3. Think about Type

• 프론트입장에서는 Backend에서는 데이터를 받기 때문에 깊이 있는 데이터가 넘어오지는 않는다.
• 오히려 범용적인 타입을 지정해서 변화에 잘 대응하는 타입을 설정하는게 좋다

4. 코드를 잘 짠다는 것 + 협업하기 좋은 코드

4.1 기본

1. 클래스명은 명사로 사용하며, 의미가 드러나는 이름을 짓는다.
2. 변수는 의도가 드러나게 작성한다
3. 함수는 객체의 동작을 의미하므로 (현재형)동사를 사용하여 이름을 짓는다.
4. 멤버 변수, 인자명, 로컬 변수명은 LowerCamelCase 방식을 따른다.
5. 상수명은 CONTANT_CASE 방식을 이용한다

4.2 주석

1. 불필요한 주석을 제거하고 의도를 명확하게 관리한다
2. 중복되는 주석을 제거한다

• 의도를 직관적으로 파악할 수 있다면, 주석을 남기지 않아도 된다.

3. 정보 제공 주석

• 코드에서 강조할 부분이 있거나, 직관적으로 파악할 수 없다면 정보제공 주석을 남겨야 한다

4. 할일 주석

• 추후에 추가 구현이 필요할 때 유용하게 사용가능하다.

4.3 코드 복잡도 관리

1. 좋은 개발자는 사람이 이해하기 쉬운 코드를 작성한다

• 주기적인 리팩토링으로 점진적으로 개선
• 낮은 복잡도의 코드가 되도록 한다

2. 역할이 분명한 코드

• 클래스는 한가지 역할만 수행하도록 한다

3. 형식을 갖춘 코드

• 한줄당 80 ~ 120자 정도의 길이를 제한하고 적잘한 들여쓰기를 고려
• 서로 밀접한 개념은 한 파일에 세로로 가까이 둔다
• 변수는 사용하는 위치에서 가장 근접한 위치에 선언

4.4 코드품질 관리

1. 예외관리
2. 테스트 관리
3. 경계 조건 테스트

4.5 보이스카우트 규칙

• 시간이 지날 수록 코드가 지저분해진다면, 보이스카우트 규칙을 도입할 수 있다.
• 야영지는 그곳을 발견했을 때보다 떠날 때 더 나은 곳이어야 한다는 규칙
• Leave the campground cleaner than you found it