
"왜 타입스크립트로 개발했는데도 런타임 에러(undefined is not a function)는 끊이지 않을까?"
혹시 컴파일 에러만 피하기 위해 any, as, @ts-ignore를 남발하고 계시진 않나요? 타입이 안정성을 주는 도구가 아니라, 오히려 관리가 버거운 짐이 되고
있지는 않은지 점검이 필요한 시점입니다.
단순한 '자동완성용' 타입을 넘어, 서버 API부터 도메인, UI 컴포넌트까지 데이터의 흐름을 실핏줄처럼 연결하는 견고한 타입 설계 전략을 공유합니다.
디버깅 시간을 획기적으로 줄이고 리팩토링 자신감을 채워줄 Type-Driven Design의 핵심 노하우를 확인해 보세요.
👉 글 보러가기: https://blog.sangwook.dev/posts/typescript-project-design
🔗 관련 시리즈 (전체 보기)
좋은 글 읽고 갑니다~!
확실히 그때그때 타입을 선언해서 사용하는 것보다, 타입 중심으로 설계하고 시작하면 안정성도 높이고, 불필요한 문제를 겪을 일도 훨씬 줄어들 것 같네요!
타입 정의를 제대로 하지 않고 넘어가면 아슬아슬한 부채가 늘어나는 것 같아요 이렇게 설계부터 다져나가면 견고하게 타입을 관리할 수 있을 것 같네요 ㅎㅎ 잘 읽었습니다
오. 타입스크립트를 코드를 작성하기 전의 설계 도구로 접근하라는 도입부의 말이 와닿네요.
js->ts 넘어갈 때, ts에 대한 지식이 부족한 파트원들과 "우선 개발먼저하고 타입 적용해요!" 하는 의견들로 반영 이후, 굉장히 쓸데없는(?) 후처리과정이 생겼었는지 회상하게 됐어요 .
어디가서 타입스크립트 왜 썼냐고 하면 여기서 읽었던 내용을 좀 인용해봐야겠습니다 ㅎㅎ 사실 서버의 타입과 클라이언트 타입을 분리하고 서버 타입을 가공해서 클라이언트 타입을 사용함에 있어서 같은 타입을 사용해야할지 다른 타입을 생성할지 그리고 다른 타입을 생성한다면 어떻게 관리를 해야할지 고민되는데... 적어주신대로 관리하게 되면 좀 더 관리하기 쉬워지지 않을까 싶습니다 ㅎㅎ 글 잘 읽었습니다!!
글을 읽으면서 많은 공감과 제 자신이 했던 부끄러운 행동들이 생각났습니다
"일단 돌아가게 만들고 나중에 타입 붙이지 뭐" 했다가 나중에 이런 저런 핑계를 대며 그냥 방치했던 기억이 났어요. 특히 API 응답마다 그때그때 타입 만드는 부분이 너무 와닿습니다. 타입을 설계 도구로 접근한다. 배워갑니다. 감사합니다 :)
좋은글 잘 읽었습니다:) 말씀하신대로 타입 시스템을 후처리 과정으로 생각하는 분들이 많은거 같아요...ㅠ 남발되는 any를 보며 한숨 쉬고있는 요즘 팀원들에게 공유 하고싶은 글이네요:)