JSDoc을 작성하든 안 작성하든 JS의 인터페이스는 매우 역동적입니다. 이 함수는 arguments 和 call와 같은 동적 메서드를 사용하여 다양한 매개변수 형식을 전달할 수도 있으며, 수신자의 매개변수 목록과 일치하지 않을 수도 있습니다.

문서 생성 측면에서 JSDoc은 실제로 빠른 문서 생성을 달성할 수 있습니다. 그러나 이는 코드 모듈의 구성 모드, 주석 길이 및 개발자 수준에 대한 더 높은 요구 사항을 가지며 자동 생성된 문서는 일반적으로 직접 유지 관리되는 문서만큼 읽기 쉽지 않습니다(예: Yeoman, 대부분의 자동 생성 문서를 처리할 때) 설명할 수 없는 상속 관계가 있는 경우)

개발 경험 향상 측면에서 JSDoc을 작성하면 실제로 코드 프롬프트에서 IDE의 지능이 향상될 수 있으며, eslint와 협력하여 개발/컴파일(패키징) 단계에서 잠재적인 문제를 발견할 수도 있습니다.

그리고 코드를 리팩토링할 때 자주 접하게 되는 질문은 [여기서 실행할 때, 이 변수는 어떤 타입이어야 하고, 이 상태에서는 어떤 값을 취해야 할까요?] 입니다. 】프런트엔드와 백엔드 모두 실제로 데이터를 중심으로 프로그래밍하기 때문에 매우 동적인 데이터 유형을 사용하고 문서가 부족하면 코드를 유지 관리하거나 리팩토링할 때 이해하기 어려운 경우가 많습니다. [함수는 무엇을 입력하고 반환합니까? What], 그리고 JSDoc은 이를 효과적으로 개선할 수 있습니다.

그러나 질문자가 정말로 묻고 싶은 것은 다음과 같습니다. [JSDoc에는 많은 이점이 있으므로 이 기능을 내 비즈니스 코드에 사용해야 할까요? 】

이 질문과 [단위 테스트를 작성해야 할까요]는 사실 같은 유형의 질문입니다. 단위 테스트와 JSDoc을 작성하면 많은 이점이 있다는 것은 누구나 알고 있지만 문제도 매우 분명합니다. 코드 양이 늘어나고 개발 주기가 길어진다는 것입니다. 별도의 테스트 디렉터리에 있는 단위 테스트 코드와 달리 JSDoc은 비즈니스 코드의 길이를 직접 늘립니다(TypeScript 사양과 같은 새로운 Doc 메서드를 사용하지 않는 한). 따라서 실무상 재사용성이 높지 않은 비즈니스 코드에 대해서는 JSDoc이나 단위 테스트를 작성하지 않고도 전혀 문제가 되지 않습니다. 기능 구현을 기반으로 함) 우선, 누들 코드를 작성하지 않으면 좋을 것입니다. 물론, 기본적으로 백엔드 위치에 대해 장황한 문서를 추가할 시간을 어떻게 가질 수 있습니까? 테이블 조회 및 데이터 반환을 기반으로 각 사양을 작성하는 것이 더 쉽습니다. 휠을 재창조하고 일부 재사용 가능한 코드 모듈을 릴리스할 때 완전한 JSDoc 및 단위 테스트는 모듈의 유지 관리에 도움이 되며 사용자가 "코드 품질이 정말 좋다"는 느낌을 갖게 할 수도 있습니다.

간단히 말하면, JSDoc을 최대한 빨리 시작하세요. 가장 중요한 것은 비즈니스 코드를 일찍 끝내고 야근을 하지 않는 것입니다.