코드 한 줄 없는 

Typescript 사용기

김상원

      vichyssoise

http://vichyssoise.io

텀블벅의 두번째 서비스

Typescript를

사용하게 된 계기

01.  팀 초기엔 엔지니어가 나 혼자...

01.  팀 초기엔 엔지니어가 나 혼자...

02.  API와 Web-client를 만들어야 한다...

01.  팀 초기엔 엔지니어가 나 혼자...

02.  API와 Web-client를 만들어야 한다...

03.  주어진 시간이 2개월...

um...

shi..t

처음 나의 생각

그래서

{API}

{Web-client}

Javascript

바꾼 나의 생각

그런데

Typescript





function getName(person) {
  return person.name
}

getName({ nam: 'typo key' })
// undefined
type Person = {
    name: string
}

function getName(person: Person) {
  return person.name
}

getName({ nam: 'typo key' })
Argument of type '{ nam: string; }' is not assignable to parameter of type 'Person'.
Object literal may only specify known properties, but 'nam' does not exist in type 'Person'. Did you mean to write 'name'?

Javascript

Typescript

Typescript 에게

기대했던 것?

개발 속도

 Learning

Curve

왜?

Type system이

주는 시간적 절약

<

하지만

​그는 더 큰 것을 주었다

신뢰

코드 한 줄 없는 Typescript 사용기

Typescript는 어떻게

우리에게 신뢰를 주었나?

개인

혼자 다뤄야 하는 코드가 많아서 생기는 일

나: "처음 뵙겠습니다"

코드: "세번째 뵙는뎁쇼..."

Typescript를 써보니까

과거의 내가 쓴 코드를 믿을 수 있게 됨

01. 빠른 디버깅

02. 적지만 믿을 수 있는 코드

03. 마음 편한 refactoring

04. 코드 == 문서

왜?

빠른 디버깅

혹은                                          의 원인을 매번 찾아헤메지 않아도 됨

XXX of undefined
XXX is not a function

적지만 믿을 수 있는 코드

코드 내부에서 입력값을 받는 코드라면 '런타임에서 타입을 검사하는 코드' 혹은 

'타입관련 테스트'를 작성할 필요가 없음

적지만 믿을 수 있는 코드

코드 내부에서 입력값을 받는 코드라면 '런타임에서 타입을 검사하는 코드' 혹은 

'타입관련 테스트'를 작성할 필요가 없음

파라미터 타입 검사 코드

그리고 그 테스트

적지만 믿을 수 있는 코드

코드 내부에서 입력값을 받는 코드라면 '런타임에서 타입을 검사하는 코드' 혹은 

'타입관련 테스트'를 작성할 필요가 없음

이게 끝? 개이득..😎

파라미터 타입 검사 코드

그리고 그 테스트

마음 편한 refactoring

refactoring 전

refactoring 후

함수의 input output 타입이 변하지 않음을 확인할 수 있기 때문에

리팩토링 전과 동작이 동일함을 믿을 수 있음.

코드 == 문서

문서를 보지 않아도 사용하는 프로퍼티의 타입과, 함수의 파라미터 타입을 알 수 있음.

한번에 많은 코드를 동시에 볼 수 있어서 컨텍스트 파악이 용이함.

문서

에디터

에디터

Javascript

Typescript

그러나

​모든 것이 완벽하진 않다!

실망편

약간..

세팅: 빌드 프로세스 수립과정이 복잡

인프라로 사용하는 framework나 library가 Typescript를 지원하지 않으면 세팅이 불편함.

문서

에디터

세팅: 빌드 프로세스 수립과정이 복잡

문서

에디터

React server-side-rendering 프레임워크

세팅: 빌드 프로세스 수립과정이 복잡

next.js의 내장된 webpack에서 타입스크립트 로더를 지원하지 않음.
그래서 컴파일된 javascript를 다시 webpack으로 빌드하도록 함.

Typescript 컴파일

Typescript 컴파일

Typescript 컴파일

Webpack 빌드

Webpack 빌드

Webpack 빌드

세팅: 빌드 프로세스 수립과정이 복잡

https://github.com/vichyssoise/nextjs-typescript-boilerplate

XXX as any

해당 변수의 type을 무시.

type system의 장점을 희석해서 안쓰는게 좋지만 어쩔 수 없이 사용해야할 때가 있다.

(ex. 외부 라이브러리에서 private 프로퍼티에 접근하는 경우)

문서

에디터

import * as moment from 'moment'

const time = moment()

// Property '_data' does not exist on type 'Moment'
console.log(time._data)

console.log((time as any)._data)

커뮤니티: 코드와 타입이 불일치

문서

에디터

DefinitelyTyped

DefinitelyTyped​

문서

에디터

Javascript 패키지의 type이 정의된 패키지

npm install lodash
npm install -D @types/lodash

커뮤니티: 코드와 타입이 불일치

문서

에디터

DefinitelyTyped

  1. type 업데이트가 코드를 따라가지 못하는 경우
  2. 코드의 일부분만 type이 선언된 경우
  3. 심지어 코드와 type이 다른 경우

커뮤니티: 코드와 타입이 불일치

문서

에디터

팀

1명

n명

Steadio의 개발팀 n명 추가요..

신뢰해야 하는 사람의 수도

늘어난다는 것!

사람의 수가 늘어난다는 것은?

제품 개발은 신뢰를 기반으로

협업하는 과정

잘 만드려면, 팀원들끼리

서로 신뢰해야한다.

팀원간의 신뢰는 어떻게 쌓이나?

팀원에 대해

신뢰가 생길 때

  1. 문서대로 사용했더니 잘 작동함
  2. 코드 리뷰시 품질 높은 코드를 생산하는 것을 확인
  3. 스펙과 동일하게 동작하도록 구현함

3가지가 잘되려면

시간이 필요하다!

TS가 팀원간의 신뢰를 쌓기 위한

시간을 단축해줌

오호!

왜?

팀원이 미리 합의한 인터페이스에 맞춰서 개발했다는 것을 타입 시스템이 보장해 주기 때문에.

Steadio 팀의 작업방식

React 사용

React의 핵심은 Props와 State

병렬 작업

이것을 가능하게 해주는 ts 타입정의

Container

View

통신 및 데이터 담당

액션과 비주얼 담당

Components

Container

View

통신 및 데이터 담당

액션과 비주얼 담당

이벤트

데이터

Components

이렇게 미리 약속해놓고

서로 맞닿는 부분을 먼저 써주면

다른 한 쪽이 구현되어있지 않아도 사용하는 코드를 만들 수 있다.

(세부적인 구현은 서로 병렬로 진행)

프로덕트 만드는 시간 단축

그래서 좋은 것

container

view

2 + 2 = 4일

container

view

2일

한없이 기다림...

팀의 만족도 상승

그래서 좋은 것

😦

👯

서로 신뢰하는 분위기 형성

그래서 좋은 것

마무리

Typescript 써보세요

일하는 방식까지

바뀔 수도 있어요

단순히 기술스택만 바뀌는게 아니라

좋... 좋은 쪽으로

김상원

      vichyssoise

http://vichyssoise.io

감사합니다

Made with Slides.com