코드 한 줄 없는
Typescript 사용기
텀블벅의 두번째 서비스
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' })
// undefinedtype 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 undefinedXXX 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 빌드
세팅: 빌드 프로세스 수립과정이 복잡
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
- type 업데이트가 코드를 따라가지 못하는 경우
- 코드의 일부분만 type이 선언된 경우
- 심지어 코드와 type이 다른 경우
커뮤니티: 코드와 타입이 불일치
문서
에디터
팀
1명
n명
Steadio의 개발팀 n명 추가요..
신뢰해야 하는 사람의 수도
늘어난다는 것!
사람의 수가 늘어난다는 것은?
제품 개발은 신뢰를 기반으로
협업하는 과정
잘 만드려면, 팀원들끼리
서로 신뢰해야한다.
팀원간의 신뢰는 어떻게 쌓이나?
팀원에 대해
신뢰가 생길 때
- 문서대로 사용했더니 잘 작동함
- 코드 리뷰시 품질 높은 코드를 생산하는 것을 확인
- 스펙과 동일하게 동작하도록 구현함
3가지가 잘되려면
시간이 필요하다!
TS가 팀원간의 신뢰를 쌓기 위한
시간을 단축해줌
오호!
왜?
팀원이 미리 합의한 인터페이스에 맞춰서 개발했다는 것을 타입 시스템이 보장해 주기 때문에.
Steadio 팀의 작업방식
React 사용
React의 핵심은 Props와 State
병렬 작업
이것을 가능하게 해주는 ts 타입정의
Container
View
통신 및 데이터 담당
액션과 비주얼 담당
Components
Container
View
통신 및 데이터 담당
액션과 비주얼 담당
이벤트
데이터
Components
이렇게 미리 약속해놓고
서로 맞닿는 부분을 먼저 써주면
다른 한 쪽이 구현되어있지 않아도 사용하는 코드를 만들 수 있다.
(세부적인 구현은 서로 병렬로 진행)
프로덕트 만드는 시간 단축
그래서 좋은 것
container
view
2 + 2 = 4일
container
view
2일
한없이 기다림...
팀의 만족도 상승
그래서 좋은 것
😦
👯
서로 신뢰하는 분위기 형성
그래서 좋은 것
마무리
Typescript 써보세요
일하는 방식까지
바뀔 수도 있어요
단순히 기술스택만 바뀌는게 아니라
좋... 좋은 쪽으로
감사합니다
TS
By pueue