JavaScript 리팩토링: 모듈 분할 및 네임스페이스

일반적으로 우리 팀의 개발자는 상당한 기술 지식과 Java 언어에 대한 풍부한 경험을 보유하고 있으며 성숙하고 합리적인 프로토콜, 다양한 유형의 코드 위험 검사 도구, 심지어 팀 검토 및 예고 없는 검사 계획도 보유하고 있습니다. 그러나 프론트엔드 코드는 백엔드와는 달리 아무도 관심을 두지 않는 어린아이와도 같습니다. 과소평가되고 멸시되기 쉬울 뿐만 아니라 품질이 좋지 않고 유지보수성도 좋지 않습니다. 기술적인 면에서 뛰어난 프론트엔드 개발자가 부족합니다.
JavaScript는 프론트엔드 코드에서 중요한 부분입니다. 버전이 거듭될수록 제품은 점점 더 커지고, 프로세스 전반에 걸쳐 JavaScript 수준의 재구성이 점차 강화되어야 합니다.

코드의 양이 특정 수준에 도달하면 JavaScript를 페이지 모듈 구성 요소(예: 사용자 정의 FreeMarker 태그)와 함께 모듈화하는 것이 가장 좋습니다.
모듈성이 가져오는 가장 큰 이점은 독립성과 유지 관리 용이성입니다. 대규모 js에서 문제 위치를 찾을 필요가 없으며, 이해하고 수용하기가 더 쉽고 사용자 정의하기도 쉽습니다.
모듈 간의 종속성을 단순하게 유지하는 것이 가장 좋습니다. 예를 들어 common.js가 있으면 가장 일반적인 기능 코드가 되며 전역 변수의 통합 관리를 포함하지 않을 수 있어야 합니다. 독립적으로 게시되며 다른 구성 요소 j도 쉽게 사용할 수 있습니다. 예를 들어, 문자열에 트림 메소드를 구현해야 하는 경우가 많지만 js 자체에는 해당 메소드가 없습니다. 그런 다음 common.js에서 문자열 프로토타입을 확장하여 이를 구현할 수 있으며 이는 외부 사용자에게 투명합니다.

네임스페이스를 사용하는 것은 js가 객체 지향일 때 캡슐화, 상속 및 다형성의 원칙을 따라야 합니다.
Java import 사용법을 언급하면서 가장 간단한 예를 살펴보겠습니다.
webOnlinePlay 메소드가 포함된 play 모듈이 있습니다. import, 언제, js 실행이 잘못되었으면 좋겠습니다:
Java 코드
webOnlinePlay() //Error! Unable to find method

그러나 이 모듈을 소개하면:
Java 코드
import("play");

webOnlinePlay(); //맞습니다.

사실 이러한 효과를 얻는 방법은 매우 간단합니다. webOnlinePlay() 메소드는 기본적으로 호출되기 때문에 기본적으로는 window.webOnlinePlay()입니다. 그렇죠?
따라서 import("play") 시 내부 구현 메커니즘은 다음과 같습니다.
Java 코드
var module = new playModule()

이 모듈의 각 메소드에 대해 All 직접 사용하기 위해 창 개체로 가져옵니다.
Java 코드
window[methodName] = module[methodName]

사실 여기에는 미스터리가 없지만 이런 종류의 주문형 하지만 이 아이디어는 프런트 엔드 재구성에 대한 아이디어, 캡슐화를 통해 유지 관리 가능성이 향상되는 아이디어를 가져오는 것 아닌가요?

똑똑하다면 다음과 같은 질문을 할 수도 있습니다.
play 모듈을 가져오지 않고 이 페이지에 필요하지 않으면 play.js도 로드할 수 없나요?
물론 다음 분해, 즉 js의 동적 로딩에 관한 부분에 주목하시기 바랍니다.