Typescript 전환 후기

기존에 JS로 개발된 페이지를 전환해본 경험 뿐이지만

• 리팩토링 도중 바로바로 알려주는 타입에러

• 불필요한 props 및 불필요한 인자 전달 제거

• API 문서화(Model)를 타입스크립트로 대체 가능

TS는 오히려 초보자들(는 나에게 하는말)이 사용해야한다고 생각한다.

• API 응답값 타입 정의하기

  • API가 어떤식으로 값으로 내려오는지, console.log 찍고 있음.

  • 내가 유지보수하려 어떤 서비스에 투입되었는데, API가 어케 내려오는지 네트워크탭 일일히 보고있기

  • 해결하기 : 초보자라면 서버 개발자분과 커뮤니케이션을 통해 API 데이터의 타입정의를 통해 안정성 높이기

• strictNullCheck로 런타임상에서 폭발할 잠재적 버그 제거하기

  • Array.find(), 객체가 null이 되어서 프로퍼티 접근 불가와 같은 버그..

처음엔 너무나 어렵고 이걸 왜하지 싶겠지만.. 하다보면.. 불필요한 코드, API에 대한 정확한 이해, 와 이걸 QA 때 안걸렸어? 등등 야근을 줄이거나 다른 팀원들에게 깨지는 일이 줄어들거라고 확신할 수 있다.

전환할거라면 allowJS 사용하여 점진적 전환하기

단점

1. 동적 타이핑 보다 정적 타이핑이 작성해야할 코드가 더 많아져서 개발 속도가 느려졌어요.

절반만 맞는 말 같다. 물론 코드 양은 정적 타이핑이 더 많다. 하지만, 장기적으로 유지보수해야 할 제품의 경우 정적 타이핑이 더 나은 선택이 될 수 있다고 생각한다. (반대의 경우, 간단한 정적 웹페이지거나 규모가 커지지 않을 페이지의 경우는 굳이 타입스크립트 전환할 이유가 없다.)

1. 버그가 줄었어요.

절반만 맞는말 같다. "버그를 줄여줘요"가 아닌 "런타임에서 에러 발생 확률을 줄여줘요"가 더 맞는 말이라 생각한다. 정말로 버그를 줄이고 싶으면 꼼꼼한 스펙 분석과 이를 테스트 코드로 작성하는 것이 아닐까라 생각한다.

그럼 TS 왜써요? 어떤 제품이든 버그가 발생할 수 있다.

정적 타이핑의 좋은 점은 런타임에서 에러 발견한 것보다 빠른 에러 발견과 빠른 해결에 있다. 같은 타입 에러인데 브라우저에서 발견한 경우 난독화 되어있고 어디서 잘못된건지 찾는데 오래걸린다.

또한, 리팩토링시 컴파일 타임에서 어떤 부분이 잘못되어있는지 바로 알려준다. 타입스크립트 없이 리팩토링할 경우, 런타임에서 에러를 일일히 확인하지 않으면 (일일히 확인해도) 불안하다. 왜냐면 영향도 파악이 어렵기 때문이다.

요약하자면 타입 에러를 런타임에서 발견했을 때 대비, 컴파일 타임에서 발견해서 얻는 이득은 빠른 발견, 빠른 해결에 있다.

1. d.ts

d.ts.. 어렵다.. 무슨 개념인지는 알겠지만, d.ts가 없는 라이브러리의 경우 내가 직접 만들어야한다. 만들 땐 재밌지만 이렇게 하는게 맞나? 싶을 떄가 많다. 아직 TS 경험이 부족해서 그런거 같다. (사실 noImplicitAny 옵션을 켜서 해결해도 되긴하다.)