프로젝트에 타입스크립트를 적용해서 사용하고 있는데 쓰다 보니 결코 유쾌한 경험은 아니었습니다.
- 타입 체크를 하면서 타입에 맞춰서 코드를 바꾸는 게 아니라 어떻게든 만들어진 코드에 맞춰서 타입을 수정하는 것 같은 느낌이 강하게 듭니다. 특히 맞다고 생각한 것이 타입을 잘못 써서 틀렸다고 판단할 때…
- 외부 라이브러리를 사용해야 할 때 외부 라이브러리에 정의된 타입을 굳이 임포트해야 해서 코드가 난잡해지며, 라이브러리의 명세서에서 타입을 명시하지 않았을 경우 굳이 해당 라이브러리 내부 코드를 뜯어야 해서 번거롭습니다.
- 분명 자스에서는 잘 동작한다고 생각했던 코드가 타입을 붙였더니 해당 기능이 동작이 안되며, 경직된 느낌으로 코드를 작성해야 한다는 부담감이 있습니다.(매우 이상한 문장) 자유도가 떨어집니다.
→ 사이드이펙트가 있는 코드
number로 쓰여야 하는데, 실제로는 string으로 온다. → string으로 와도 동작은 해 → 자연스럽게 인자가 number라고 생각해서 쓰는 함수였는데 → 실제로는 string으로 오고 있네? → 실행해보니까 다른 데서 문제가 있네?
그나마 장점은 임포트 안 하거나 없는 변수 썼을 때 잘 잡아준다는 게 장점이지만…
→ 저는 interface나 enum 등을 잘 활용할 수 있어서 좋았던 것 같습니다.
→ 저는 예상치 못한 에러들을 잡아준다는 장점이 있었습니다. 자바스크립트의 ‘너무’ 유연하다는 부분을 잡아주기에 불편도 하지만 이후 생길 수 있는 여러 오류를 잡아준다고 생각합니다. 정적 테스트라고도 하던데, 테스트 코드처럼 오류가 터질만한 부분을 빠르게 잡아주어서 좋았습니다.
→ 코드에 맞춰서 타입을 수정하는 문제는 데이터를 설계하고 타입을 먼저 짜둔 뒤 로직 구성을 시작하면 그런 느낌을 (?) 좀 피할 수 있더라구요
그리고 타입만으로도 팀원들이 이 변수를 왜 썼는지, 이 로직은 무엇을 위한 로직인지 알기가 쉬워서 저는 만족스럽습니다ㅋㅋㅋㅋ
JSDOCS 따로 안 만들어도 돼서 좋아요
→ 저같은 경우에는 타입스크립트를 사용할 때, 자바스크립트 인데 타입 기능을 추가해서 써야지~ 같은 느낌으로 사용하면 매우 불편했습니다. 타입스크립트를 쓴다고 생각하면서 타입도 많이 만들고, 타입 연산자도 쓰고, 인터페이스도 빡세게 작성하다보니까 오히려 편해질 때가 많더라구요. (Partial, Omit, Exclude 등등 여러 Util Type 연산자를 활용하다보면 조금 편해집니다)
→자동완성 기능을 이용하려면 울며 겨자먹기로 써야죠..
→ 그거슨 vscode 사용자에게나 해당되는 것이라고 생각합니다
→ 당신 Jetbrain 사람이지! (아는 만큼 보였던 것으로 판명되었습니다… 사이좋게 지내요)
→ VIM으로 오세요 ^^
→ 혼자 코딩할 땐 조금 불편할 수는 있어도 협업할 때에는 소통하기 훨씬 편해지는 것 같아요!
→ 어플리케이션이 실행되기 이전에 오류를 잡아준다 ( 개발 과정에서 오류를 잡아준다 )
→ 특히 오타 잡아주는 기능은 매우 좋았습니다
→ 서브 문서
→ 프로젝트에 대한 히스토리를 모르더라도, 타입이 있기 때문에 어느정도의 프로젝트에 대한 명세 파악을 할 수 있다.
→ 외부 라이브러리 쓸 때 타입 스크립트 없었으면 화가 많이 났을 것 같아요
→ 디자인 시스템 같은거 가져다 쓸 때 공식 문서 없으면 개발 불가능해지는..
→ 자스나 타스나 공식문서 없으면 코드를 일일이 뜯어봐야 해서 불편했습니다
→ 뭐야 이거 타입 어디 선언되어 있어 살려줘 → 이상한 라이브러리를 쓰는게 아닌가…
→ 인정합니다 zustand 네이놈
JS 버리고 C# Blazor로…
→ 코틀린
→ rescript