TypeScript의 승리. 그 결과 우리는 무엇을 얻었는가.
논쟁은 끝났습니다. TypeScript가 승리했습니다. 새로운 프로젝트들은 기본적으로 TypeScript를 사용합니다.
원래의 목적은 코드가 망가지기 전에 오타를 잡아내는 것이었습니다. 하지만 진짜 가치는 그보다 훨씬 더 큽니다.
타입은 결코 낡지 않는 문서 역할을 합니다. 함수 시그니처는 무엇을 전달해야 하고 무엇을 돌려받는지 정확히 알려줍니다. 리스트에 새로운 옵션을 추가하면, 컴파일러는 코드의 모든 부분을 업데이트하도록 강제합니다. 주석은 그냥 그 자리에 남아 당신에게 거짓말을 할 뿐입니다.
리팩터링이 안전해집니다. 예전의 JavaScript 코드에서 필드 이름을 바꾸는 것은 도박처럼 느껴졌습니다. 문자열을 검색하고 운에 맡겨야 했죠. TypeScript에서는 타입을 변경하기만 하면 컴파일러가 깨진 모든 줄을 할 일 목록(to-do list)으로 제공합니다. 리팩터링은 더 이상 두려운 일이 아닙니다. 그저 하나의 작업일 뿐입니다.
타입은 AI 어시스턴트의 성능도 향상시킵니다.
AI에게 타입이 지정되지 않은 JavaScript를 수정해 달라고 요청하면, AI는 구조를 추측해야 합니다. 하지만 TypeScript를 사용하면 타입이 곧 명세(specification)가 됩니다. AI는 무엇이 허용되는지 알게 됩니다. AI가 실수를 하더라도 컴파일러가 즉시 잡아냅니다. 새벽 2시에 운영 환경(production)에서 장애가 발생하는 대신, 에디터에 빨간 줄이 뜨는 것을 보게 될 것입니다.
타입은 당신의 속도를 늦추지 않습니다. AI 시대에 타입은 오히려 속도를 높여줍니다. 타입은 가드레일 역할을 하여 생성된 코드를 신뢰할 수 있게 해줍니다.
의도를 가지고 타입을 작성하세요:
• 여러 개의 boolean 대신 union을 사용하세요. 서로 모순될 수 있는 세 개의 플래그보다는 "loading" | "error" | "ready"와 같은 상태값이 더 좋습니다.
• 도메인 타입을 명명하세요. 의도를 보여주기 위해 "type Cents = number"와 같이 사용하세요.
• "any"를 피하세요. 대신 "unknown"을 사용하고 타입을 좁혀나가세요(narrow down). "any"는 안전망에 구멍을 만듭니다.
• 타입 추론(inference)을 활용하세요. 모든 것에 타입을 붙일 필요는 없습니다. 함수 시그니처와 같은 경계 부분에만 타입을 지정하고 나머지는 자연스럽게 흐르도록 두세요.
TypeScript는 단순히 오타를 잡아내는 것 이상의 일을 해냈습니다. 강제된 계약(enforced contracts)을 만들어냈습니다. 이 계약 덕분에 두려움 없는 리팩터링과 신뢰할 수 있는 AI 도구가 가능해졌습니다.
우리는 버그를 막기 위해 타입을 사용하기 시작했습니다. 그리고 다른 모든 것의 토대가 되기 때문에 계속해서 타입을 사용합니다.
Source: https://dev.to/parsajiravand/typescript-won-heres-what-that-actually-bought-us-12m8