TypeScript(및 JSDoc)와 JavaScript

소개

TypeScript가 출시된 지 12년, JSDoc이 출시된 지 17년이 지난 2024년에도 많은 사람들은 정적 타이핑 도구가 JavaScript/ NodeJ 커뮤니티.

이 글에서는 TypeScript와 JSDoc이 무엇인지, 그리고 프로젝트에서 이들 중 하나를 사용해야 하는 이유에 대해 설명하겠습니다.

그들은 무엇입니까

TypeScript와 JSDoc은 JavaScript가 정적 타이핑을 수행할 수 있도록 하는 도구입니다. 두 가지 모두에 대한 예는 아래를 참조하세요.

보시다시피 TypeScript는 일반적으로 JSDoc보다 덜 장황하지만, JSDoc은 빌드 단계가 필요하지 않으며 JavaScript 코드의 주석과 직접 작동합니다.

타입스크립트

convert-string-to-int.ts(TYPESCRIPT 파일!)

JSDoc

convert-string-to-int.js(JAVASCRIPT 파일!)

장점

장단점에 대해 이야기하기 전에, 얼마나 많은 기사를 읽었는지, 이 기사가 얼마나 좋은지에 관계없이 정적 타이핑으로 작업할 때 개발자 경험이 얼마나 더 나은지 설명할 방법이 없다는 점을 말씀드리고 싶습니다.

아무도 유형이 지정되지 않은 코드베이스보다 정적 타이핑이 있는 코드베이스로 작업하는 것이 얼마나 좋은지 말이나 논쟁으로 설명할 수 없으며, 심지어 최고의 시인도 마찬가지입니다.

저도 다른 많은 사람들처럼 이 감정을 사실과 데이터로 전환하려고 노력하겠지만, 정확한 감정을 설명하는 것만으로는 충분하지 않을 것임을 확신합니다.

생산 오류 방지

이것이 의심할 여지없이 정적 타이핑의 가장 큰 장점입니다. 재작업 방지와 비용 절감 측면에서 얼마나 도움이 되는지 설명하기에는 부족합니다.

주로 핫픽스를 빠르게 출시하기 위해 단위 테스트를 작성하거나 솔루션의 가능한 모든 흐름을 테스트할 시간이 없습니다. 순수 JavaScript로 작업하는 경우 다음을 보장할 방법이 없습니다.

• 사용 중인 변수가 모두 존재합니다

• 사용중인 모든 변수가 선언되었습니다

• 해당 유형에 허용되는 메소드를 사용하고 있습니다. (예: 숫자 변수에 map을 사용할 수 있습니다.)

• 동등한 변수를 비교하는 경우(숫자와 배열을 비교하면 안 됩니다)

코드를 매우 잘 테스트하지 않으면 버그를 수정하기 위해 다시 작업해야 하며 이전에 기침했을 수도 있는 작업에 귀중한 시간을 소비해야 합니다. 이러한 것들로 인해 발생하는 버그는 어리석게 들릴 수도 있지만 가장 많이 발생하는 버그입니다.

정적 타이핑을 사용하면 보다 안전하고 빠른 개발이 보장되고, 프로덕션에서 버그의 양이 터무니없이 줄어들며, 개발자는 실제로 가치를 제공하는 비즈니스 로직에만 집중할 수 있습니다.

불필요한 테스트 없음

대부분의 레거시 프로젝트와 클라우드 집약적인 프로젝트(클라우드 전용 리소스가 많은 프로젝트)는 코드를 로컬에서 실행하는 어려운 프로세스를 가지고 있으며, 더 나쁜 경우에는 모의 작업 없이 실행할 수 있도록 코드를 배포해야 합니다.

로컬에서 작업을 실행하는 과정은 개발자에게 매우 시간이 많이 걸리고 지칠 수 있으며 이를 피할 수 있으면 많은 리소스(시간, 비용, 인내, 클라우드 리소스 등)가 절약됩니다.

정적 타이핑을 사용하면 코드가 매우 예측 가능하며 코드의 각 부분에서 무슨 일이 일어나고 있는지 알면서 모든 것을 개발할 수 있고 실행을 매우 쉽게 추적할 수 있으므로 코드를 실행하는 데 필요한 유일한 시간이 됩니다. 개발을 마친 후 모든 것이 예상대로 작동하는지 실제로 테스트하는 것입니다.

오래된 문서 없음

대부분의 경우(모두는 아니더라도) 함수에 대한 문서를 작성하고 입력/출력 예제를 추가하려고 하면 눈 깜짝할 사이에 낡아지게 됩니다. 개발자는 문서 업데이트를 기억하지 않으며 스크럼 마스터는 이를 수행하는 데 충분한 시간을 할당하고 싶어하지 않습니다.

정적 타이핑을 사용하면 코드가 라이브 문서가 됩니다. 개발자가 코드를 업데이트하면 문서도 업데이트되기 때문에 결코 시대에 뒤떨어지지 않습니다.

CommonJs/ES 모듈 관련 문제 방지

NodeJ에서 ES 모듈을 구현한 후 많은 라이브러리가 이 새로운 코드 작성 방식으로 마이그레이션하기 시작했습니다. 따라서 새 버전(보다 안전하고 안정적이며 성능이 뛰어나고 더 많은 기능을 포함)은 이전 버전의 JavaScript와 호환되지 않습니다. 안전하지 않은 오래된 버전을 사용하게 됩니다.

코드에서 아무것도 변경하지 않고(구성에서 단 몇 줄만) CommonJs 및 ES 모듈과 호환되는 것이 무엇인지 추측해 보세요. 바로 TypeScript입니다(아쉽게도 JSDoc에는 이런 장점이 없는 것 같습니다).

자동 완성 및 오타 방지

무엇이 가지고 있는 모든 속성과 메서드를 기억할 필요 없이 정적 타이핑과 즐겨 사용하는 IDE를 사용하세요!

다음과 같은 이유로 개발 시간이 단축됩니다.

• 물건의 속성을 상담하기 위해 앞뒤로 왔다 갔다 할 필요가 없습니다

• 속성/메서드의 첫 글자만 입력하고 Enter를 누르면(또는 올바른 제안을 선택한 다음 Enter를 누르면) 자동 완성됩니다

또한 단어를 잘못 쓰는 것을 방지하며, 이는 프로덕션에서 예상보다 더 많은 버그를 유발합니다.

지식 손실 감소 및 시간 낭비 없음

프로젝트에서는 서로 다른 개발자가 코드의 특정 부분을 작성하는 것이 일반적이며, 코드를 작성하는 사람에게는 매우 명백해 보이는 내용이 모든 사람에게는 직관적이지 않을 수도 있습니다.

다른 개발자가 다른 사람이 작성한 새로운 작업을 수행하는 경우 변경 사항을 적용하기 전에 해당 내용을 이해하는 데 시간을 투자해야 합니다. 정적 타이핑을 사용하면 개발자가 변수 값과 실행 흐름을 이해하는 데 많은 시간을 단축할 수 있습니다.

해당 코드를 작성한 개발자가 회사/팀을 떠나더라도 이 모든 문서가 코드에 직접적으로 작성되기 때문에 생각보다 큰 영향을 미치지는 않습니다. 찾기 쉽고 이해하기 쉽습니다.

또한 개발자는 프로젝트 작업을 위해 페어 프로그래밍에 덜 의존해야 합니다. 만약 형식이 잘 작성되고 충분히 간단하다면 프로젝트에 참여하는 사람과 대화하지 않고도 개선/변경을 수행할 수 있을 수도 있으며 터무니없이 증가할 수도 있습니다. 효율성이 뛰어납니다.

현대적이고 개발자에게 매력적

TypeScript는 스택 오버플로 개발자 설문조사에 따르면 가장 사랑받는 언어 중 하나입니다. 4년 연속 결과는 다음과 같습니다.

2020년:

2021년:

2022년:

2023년:

JSDoc은 설문조사에 없어서 좋은 선택이라고 말할 수 있는 데이터가 없습니다. 제가 말할 수 있는 유일한 것은 HTMX가 그것을 사용하고 있다는 것입니다. 그러나 그것은 매우 간단한 라이브러리입니다.

반면, 이번 설문조사에 따르면 개발자들은 최근 몇 년간 JavaScript보다 TypeScript를 선호했다고 말할 수 있습니다.

유연한

모든 것을 입력할 필요는 없습니다. TypeScript와 JSDoc은 대부분의 항목 유형을 추측할 수 있으므로 Java나 C와 같은 다른 언어보다 훨씬 쉽고 장황하지 않습니다.

TypeScript의 경우 최악의 경우에는 아무거나 사용하세요. any는 조커 유형으로 무엇이든을 의미하므로 무슨 일이 있어도 피해야 합니다. 하지만 시간이 부족하거나 부족함으로 인해 방해받고 싶지 않은 경우 유형에 따라 이 옵션이 제공됩니다.

JSDoc의 경우 순수한 JavaScript이므로 아무 것도 언급하지 마세요!

더 이상 불필요한 리팩터링이 필요하지 않습니다.

그 이유에 대해서는 학습 곡선이 높다 섹션에서 자세히 설명하겠지만 여기서는 스포일러를 좀 하겠습니다.

이해할 수 없는 코드가 포함된 코드베이스는 리팩토링해야 하며, 적절한 문서가 없는 코드베이스(코드와 분리된 경우 유지 관리가 불가능하다는 점에 동의함)에는 문서 없이는 이해하기 불가능한 섹션이 더 많습니다. 파고들고 분석하는데 시간이 많이 걸렸습니다.

리팩터링은 코드를 이해할 수 없기 때문에 발생하는 것이 아니라 성능 문제 또는 비즈니스 로직 변경으로 인해 발생해야 합니다. 같은 일을 두 번 해야 하는 것은 개발자, 사용자, 투자자 모두에게 좋지 않습니다.

개발자의 독립성 향상

장기 프로젝트에서는 여러 사람이 작업하는 것이 일반적이며, 신규 사용자가 해당 코드베이스에 능숙해지도록 하려면 (신입 개발자와 경험이 많은 개발자 모두) 항상 시간이 걸립니다.

정적 유형을 사용하면 개발자가 최소한 코드의 기본 사항만 이해할 수 있고 더 복잡한 비즈니스 논리를 이해하기 위해서만 다른 개발자의 도움이 필요하기 때문에 필요한 시간을 많이 줄일 수 있습니다(문서에 문서화되지 않은 경우). 코드이지만 이는 다른 기사의 주제입니다.

이를 통해 프로젝트에 신규 참여자가 참여하기가 더 쉬워지고, 학습 곡선이 크게 줄어들며, 무언가가 망가질 위험이 줄어들어 프로젝트에 참여할 수 있어 팀 전체의 효율성이 높아집니다.

단점

더욱 복잡한 빌드 단계

TypeScirpt의 유일한 단점은 빌드 단계가 더 복잡하다는 것입니다(현실적으로 말하면 요즘 모든 JavaScript 프로젝트에는 이미 빌드 단계가 있으므로 조금 더 복잡해질 뿐입니다).

빌드 프로세스를 TypeScript와 통합하려면 적절한 플러그인이나 어댑터가 필요할 수 있지만 요즘에는 성숙하고 바로 제작 가능한 라이브러리, 플러그인, 도구 및 이를 작동시키는 데 필요한 모든 것이 있습니다.

거짓말이 아닙니다. JavaScript 생태계의 대부분의 다른 도구와 마찬가지로 처음에는 문제가 발생할 수 있지만 전문가를 따라잡을 만큼 충분하지는 않습니다.

TypeScript 대신 JSDoc을 사용하기로 선택하면 TypeScript의 유일한 단점은 사라지지만 새로운 단점이 나타납니다. JSDoc은 클래스를 사용하여 표현하지 않으면 더 복잡한 유형에서는 잘 작동하지 않습니다.

주장을 폭로하다

학습 곡선이 높습니다.

정적 타이핑을 하려면 몇 가지 항목을 더 작성해야 하지만 학습 곡선은 작성해야 하는 추가 : 문자열과 관련이 없지만 작업하기가 얼마나 어려운지와 관련이 있습니다. 그 코드베이스.

정적 타이핑이 없으면 코드에서 무슨 일이 일어나고 있는지, 변수에 어떤 값이 있는지, 어떤 비즈니스 로직이 적용되는지 이해하려면 훨씬 더 많은 컨텍스트가 필요합니다.

예를 살펴보겠습니다.

function processOrders(orders) {
 // Logic here
}

이 정보만으로 주문에 어떤 가치가 있는지 알 수 있나요? 배열이에요!라고 말할 수도 있겠지만, 어떨까요? 당신은 틀렸다. 주문은 객체입니다. 어떤 속성을 갖고 있나요? 코드를 살펴보는 데 최소한 1분의 시간을 투자하여 알아내시기 바랍니다.

속성은 선택사항인가요? 그들은 항상 존재합니까? 객체인가요, 배열인가요, 아니면 문자열인가요? 팀의 다른 구성원이 이 지식을 갖고 있습니까, 아니면 이 코드를 작성한 사람이 오래 전에 사라졌습니까?

정적 타이핑 자체가 학습 곡선을엄청나게줄여줍니다.

순수한 JavaScript를 사용하면 프로세서 주문과 관련된 작업을 수행하는 각 사람은 동일한 프로세스를 거쳐야 합니다.

• 주문이 무엇인지 스스로에게 물어보세요

• 이를 파악하기 위해 프로세스 내부에서 많은 시간을 소비함

• processOrders의 특정 동작이 필요한 경우 다른 팀원에게 자세한 내용을 문의하고 시간을 투자할 수도 있습니다

더 재미있게 만들기 위해 숫자로 표현해 보겠습니다.

• 5명으로 구성된 팀, 각자 연간 10만 달러 벌기

• 6개월에 한 번, 특정 세부 사항을 잊어버릴 만큼 충분한 시간으로 processOrders 작업을 해야 한다고 가정해 보겠습니다.

• 그들은 필요한 모든 것을 파악하는 데 5분을 소비합니다(예, 저는 여기서 매우 낙관적입니다)

• 프로젝트에는 일반적으로 수천 또는 최소한 수백 개의 기능이 있으며 모두 processOrders와 유사하지만 여기서는 10개의 기능만 있는 작은 프로젝트만 고려해 보겠습니다.

• 개발자 5명 * 연간 10분 * 기능 10개 = 연간 500분

각 개발자가 분당 88센트를 벌면 10가지 기능이 무엇을 받고 반환하는지 알아내는 데에만 440달러가 소요됩니다. 마법의 프로젝트에 수천개의 기능이 있는 실제 세계가 아닌 마법의 프로젝트에 10개의 기능만 있는 가상 시나리오의 가장 좋은 사례에서는 이는 어떤 가치도 생성하지 않는 비생산적인 시간입니다.

이제 TypeScript로:

interface Orders {
 ids: Array<number>
 skipTypes?: Array<string> // Skip orders if they have specific types
}

interface ProcessedOrders {
 total: number
 success: number // Amount of orders that were succesfully
 processed skipped: number // Amount of skipped orders based on input filters
}

function processOrders(orders: Orders): Promise<ProcessedOrders> {
  // Logic here
}

이것이 끔찍하고 비직관적인 함수라는 것을 알고 있지만 코드에서 이런 일이 발생합니다. 그러면 안 됩니다 하지만 그렇게 되므로 최소한 문서화하는 것이 좋습니다.

순수한 JavaScript 버전과 달리 여기에는 선택 사항인지 여부에 관계없이 함수가 수신하고 반환하는 모든 것을 이해하는 데 필요한 모든 컨텍스트와 함수가 수행하는 기본 원리가 있습니다. .

그래도 자바스크립트 문제가 아니라 클린 코드 문제입니다! 또는 문서 부족 문제가 아니라 자바스크립트 문제와 같은 많은 논쟁을 벌일 수 있습니다. 문제! 하지만 이 모든 문제는 다양한 문제이며 코드에서 발생하며 다른 기사에서 다룰 수도 있지만 이 기사의 초점은 아닙니다.

일부 라이브러리는 TypeScript를 지원하지 않습니다.

TypeScript의 마법은 TypeScript를 지원하기 위해 라이브러리가 필요하지 않다는 것입니다.

타이핑 없이 라이브러리를 사용할 수 있으며 동일하게 작동하지만 순수 JavaScript 라이브러리로 작업하기가 더 어렵기 때문에(이 기사에서 언급한 이점이 없기 때문에) 아마도 고려해야 할 것입니다. 다른 것을 사용하세요.

뭔가 새로운 걸 배워야겠어

그렇습니다. 우리 개발자는 매일 새로운 것을 배워야 합니다. 그것은 우리 일의 일부입니다. 우리는 문제에 대한 기술적 솔루션을 만들고, 참고가 되고, 우리가 직면한 문제를 해결하는 방법을 찾기 위해 여기에 있습니다.

많은 이점이 있는 새로운 것을 배우는 것은 시간을 가치 있게 만드는 노력입니다.

결론

정적 타이핑 도구가 개발에 얼마나 큰 도움이 되는지 알게 되면 상당한 반대의견 없이도 이 도구가 개발자, 사용자, 회사 재정 등 모든 사람에게 얼마나 유익한지 부인할 수 없습니다.

이 기사가 귀하가 이를 이해하고 쌍을 설득하여 개발 경험을 향상시키는 데 도움이 되기를 바랍니다.

위 내용은 TypeScript(및 JSDoc)와 JavaScript의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!