Chapter02- 모듈 시스템

모듈의 필요성

좋은 모듈 시스템은 소프트웨어 엔지니어링의 몇 가지 기본적인 필요성을 마주할 때

도움을 준다.

• 코드베이스를 나누어 여러 파일로 분할하는 방법을 제시한다. 이것은 코드를 좀 더 구조적으로 관리할 수 있게 해주고 각각으로부터 독립적인 기능의 조각들을 개발 및 테스트하는 데에 도움을 주며 이해하기 쉽게 한다.
• 다른 프로젝트에 코드를 재사용할 수 있게 해준다. 실제로 모듈은 다른 프로젝트에도 유용하고 일반적인 특성을 구현할 수 있다. 모듈로서 기능을 구조화하는 것이 그 기능들이 필요한 다른 프로젝트로 좀 더 쉽게 이동시킬 수 있다.
• 은닉성을 제공한다. 일반적으로 복잡한 구현을 숨긴 채 명료한 책임을 가진 간단한 인터페이스만 노출시키는 것이 좋은 방식이다. 대부분의 모듈 시스템은 함수와 클래스 또는 객체와 같이 모듈 사용자가 이용하도록 공개 인터페이스를 노출시키는 반면, 공개하지 않으려는 코드를 선택적으로 공개되지 않도록 해준다.
• 종속성을 관리한다. 좋은 모듈 시스템은 서드파티(third-party)를 포함하여 모듈 개발자로 하여금 기존에 있는 모듈에 의존하여 수비게 빌드할 수 있게 해준다. 또한 모듈 시스템은 모듈 사용자가 주어진 모듈의 실행에 있어 필요한(일시적 종속성들) 일련의 종속성들을 쉽게 임포트할 수 있게 해준다.안에서 모듈을 정의하고 사용할 수 있게 해주는 도구인 반면,
• 모듈은 소프트웨어의 실제 유닛으로 정의할 수 있다.
• 모듈과 모듈 시스템을 구별하는 것은 중요하다. 모듈 시스템이 문법이며 우리의 모든 프로젝트

JavaScript와 Node.js 에서의 모듈 시스템

 모든 프로그래밍 언어가 내장 모듈 시스템을 가지고 있는 것은 아니며 JavaScript는 오랫동안

 이 요소가 결핍되어 왔다. 브라우저 관점에서 코드베이스는 여러 파일로 분할될 수 있으며

 다른 태그를 사용하여 임포트 될 수 있다.
 몇 년간은 이러한 접근이 간단하게 상호작용하는 웹사이트를 위한 빌드에는 충분했고

 JavaScript 개발자들은 모든 것을 갖추고 있는 모듈 시스템없이도 관리상에 별 문제가 없었다.

 JavaScript 브라우저 애플리케이션이 점점 복잡해지고  jQuery, Backbone, Angular와

 같은 프레임워크가 생태계를 점유해나가면서 JavaScript 커뮤니티에는

 JavaScript 프로젝 트에 효율적으로 사용될 모듈 시스템을 정의하기 위한 여러 시도가 나타나기 시작했다.

 가장 성공적인 것이 AMD(Asynchronous Module Dfinition)이다.

 AMD는 RequireJS에 의해서 대중화되었고 후에는 UMD(Universal Module Definition)이 나오게 된다.

 Node.js가 처음 만들어졌을 때, Node.js는 운영체제의 파일시스템에

 직접적으로 접근하는 JavaScript를 위한 서버 런타임으로서 구상되었다.
 그래서 모듈 관리에 있어서 다른 방법을 도입할 수 있는 특별한 기회가 있었고

 이때 도입된 방법이란 HTML 과 URL을 통한 리소스 접근에의존하지 않고

 오직 로컬 파일시스템의 JavaScript 파일들에만 의존하는 것이었다.

 이 모듈 시스템을 도입하기 위해 Node.js 는 브라우저가 아닌 환경에서

 JavaScirpt 모듈 시스템을 제공할 수 있도록 고안된 CommonJS의 명세를 구현하게 되었다.

모듈 시스템과 패턴

 모듈은 주요 애플리케이션의 구조화를 위한 부품인 동시에 명시적으로 노출 시키지않은

 모든 함수들과 변수들을 비공개로 유 지하여 정보에 대한 은닉성을 강화시켜주는 주된 장치이다.

 CommonJS를 구체적으로 알아보기 전에 우리가 간단한 모듈 시스템으로 만들어보기 위해

 사용할 패턴이자 정보를 감추는 데에 동무을 주는 노출식 모듈 패턴을 이야기해보자.

 노출식 모듈 패턴JavaScript의 주요 문제점 중 하나는 네임스페이드가 없다는 것이다.

 모든 스크립트는 전역 범위에서 실행된다. 따라서 내부 애플리케이션 코드나

 종속성 라이브러리가 그들의기능을 노출시키는 동시에 스코프를 오염시킬 수 있다.

 이는 매우 위험한 일이다. 예를 들어 종속성 라이브러리가 전역 변수를 utils를 선언했다고 생각해보자.

 만약 다른 라이브러리나 애플리케이션 코드가 의도치 않게 utils를 덮어쓰거나 대체해버린다면

 그것에 의존하던 코드는 예측 불가능한 상황 속에서 충돌이 일어날 것이다.

 다른 라이브러리나 애플리케이션 코드가 내부적으로 사용할 의도를 갖고 함수를 호출할 때에도

 예측 불가능한 부작용이 발생할 수 있다. 다시 말해서, 저역 범위에 의존하는 것은 매우 위험한 작업이다.

 게다가, 애플리케이션이 확장됨에 따라 더욱 개별적인 기능 구현에 의존해야 하는 상황이 발생한다.

 이러한 문제를 해결하기위한 보편적인 기법을 노출식 모듈 패턴(revealing moudule pattern)이라 한다.

 CommonJS 모듈CommonJS는 Node.js의 첫 번째 내장 모듈 시스템이다.

 Node.js의 CommonJS는<CommonJS 명세를 고려하여 추가적인 자체 확장 기능과 함께 구현되었다.

 CommonJS 명세의 두 가지 주요 개념을 요약하면 다음과 같다.

 require는 로컬 파일 시스템으로부터 모듈을 임포트하게 해준다.

 export와 module.exports는 특별한 변수로서 현재 모듈에서 공개될 기능들을 내보내기 위해서 사용된다.

 직접 만드는 모듈 로더 Node.js에서 CommonJS가 어덯게 작동하는지

 이해하기 위해서 비슷한 시스템을 만들어 본다.

 자세한 내용은 책을 참고.

 

위 내용은 Node.js 디자인 패턴 바이블 책을 보고 내용을 정리한 것 입니다.

더 자세한 내용은 책을 구매하셔서 보는것이 좋을 것 같으며<제 발생시 삭제하겠습니다.