개인프로젝트를 진행하면서 타입스크립트로 서버를 작성하고 있다.
그런데 지금 사용해본지 근 일주일 밖에 되지 않아 타입스크립트를 정확하게 이용하고 있거나, 이해하고 있다고 말하기는 어려워 보인다.
이번 기회에 '장점'이라도! 정확히 정리해두자.
생활 코딩이 많은 사람들에게 인기가 있는 것은 '처음부터 완벽하지 않아도 괜찮다'라는, 배우는 사람들에게 마음의 위안을 주고 앞으로 나아갈 힘을 주는 메시지가 기저에 깔려있기 때문이다.
마찬가지로 이 글도 '타입스크립트를 처음부터 완벽히 적용하지 않아도 점진적으로 배우면 돼!'라는 말을 해준다. (마음이,,,따,,,따땃해져....🔥)
타입스크립트를 프로젝트에 '도입할 것인가?'를 생각하고 있다면, 이 장점에 대해 인지하고 있을 것이다. 나 역시도 타입스크립트에 대해 처음들었을 때, 정적 타입을 지원하기 때문에 좋다~ 라는 이야기를 먼저 접했으니까.
타입스크립트는 프로그래밍 언어인 동시에 컴파일러이다. 이 말인 즉슨, 타입스크립트로 열심히 코드를 작성한 이후, 타입스크립트 -> 자바스크립트 변환 과정을 거쳐야 한다는 것이다.
타입스크립트에 좀 더 익숙해진다면 생각해 볼만한 주제가 있어서 가지고 와봤다.
The broken promise of static typing
이 글은 정적 타이핑이 그리 버그 감소에 도움이 되지 않는다 것을 자료와 함께 주장한다.
엄밀히 말하자면 아래의 장점들은 1번으로부터 기인한다.
개발 과정에서 FE-BE간 통신을 하다보면 데이터 포맷이 수없이 변경될 여지가 있다. 이때, 커뮤니케이션 로스가 발생하면 개발단계에서 문제를 발견하지 못하고 퍼블리시 되는 위험이 커진다.
타입스크립트를 사용하면
- 프론트엔드와 백엔드 간 공통적으로 데이터의 포맷과 타입을 정적으로 정의해 놓은 것을 양측에 동시에 참조할 수 있고,
- 타입이 변경될 때, 공통적으로 참조하는 타입의 정의를 변경시켜 강제로 에러를 발생 시킬 수 있다.
타입스크립트에 관한 대부분의 글에서 생상성이 비약적으로 상승하는 것처럼 이야기 되어있다.
사실 타입스크립트를 접한지 이제 막 '1주일👼' 정도 밖에 되지 않은 내가 함부로 판단할 부분은 아니지만, 이 글의 내용이 더 신뢰가 간다.
이 글의 결론은 프로젝트의 규모에 따라 도움이 될 수도, 그렇지 않을 수도 있다는 것이다.
간단한 프로젝트에서는 '더 많은' 코드를 작성해야하는 타입스크립트가 생상성면에서 불리한 점이 있지만, 유지보수가 장기적이고 지속적으로 필요한 대규모 프로젝트에 가까울 수록 타입스크립트가 유리하다.
코드가 매우 길어지는 문제가 있다.
Javascript
function jsFunc (name, callback = null) {
if(callback) {
return callback(name)
}
return name
}
Typescript
const tsFunc = (name: string, callback: () => string) : string => {
if (callback) {
return callback(name)
}
return name
}
위는 매우 간단한 예시지만, 복잡한 함수를 정의할 필요가 있을 때는 코드양이 확연하게 차이가 난다.
늘어나는 코드량에 의해 단기적으로, 혹은 규모가 작은 프로젝트에서는 생산성이 저하될 수 있다.
또한 대부분의 패키지들은 Type을 지원하지만, 만~약 지원하지 않는 패키지가 있다면 슬퍼지는 일이 발생할 수 있다.
예를 들어,
내 프로젝트만 해도
faker 라이브러리의 타입을 이런식으로 가져올 수 있었다.
"@types/faker": "^5.5.6",
이게 없다면,,,, 쬐~금 일이 많이지긴 했겠다.