JavaScript에서 내가 가장 좋아하는 9가지 디자인 패턴

Unsplash 의 Nick Seagrave 사진

디자인 패턴은 소프트웨어 개발 중에 발생하는 일반적인 문제에 대한 재사용 가능한 솔루션입니다. 모든 JavaScript 프로그래머는 동일한 문제에 직면했으며 동일한 솔루션이 계속해서 사용되었습니다. 이러한 솔루션이 디자인 패턴입니다.

모든 프로그래밍 언어에는 커뮤니티에서 만든 많은 솔루션이 있습니다. 여러 개발자의 이러한 결합된 경험은 디자인 패턴을 매우 유용하게 만듭니다. 그들은 최적화되고 문제를 해결하는 코드를 작성하는 데 도움이 됩니다. 또 다른 큰 장점은 너무 일반적이어서 다른 개발자가 서로의 코드를 쉽게 이해할 수 있다는 것입니다.

디자인 패턴의 가장 큰 이점은 다음과 같습니다.

• 작동하는 솔루션: 많은 개발자가 사용하기 때문에 작동하는지 확인할 수 있습니다. 뿐만 아니라 패턴이 많이 사용되면서 여러 최적화가 이루어졌습니다.
• 쉽게 재사용 가능: 디자인 패턴은 정의에 따라 재사용이 가능하며 매우 일반적이지만 특정 문제에 쉽게 적용할 수 있습니다.
• 표현력이 뛰어납니다. 디자인 패턴은 복잡한 솔루션을 우아한 형식으로 설명할 수 있습니다.
• 리팩토링의 필요성 감소: 디자인 패턴을 염두에 두고 애플리케이션을 작성할 때 깨끗한 코드에 더 빨리 도달하는 것이 더 쉽습니다. 이렇게 하면 리팩터링을 줄일 수 있습니다. 특히 JavaScript에서는 같은 것을 작성할 수 있는 다양한 방법을 허용하는 언어입니다.
• 코드를 더 작게 만듭니다. 디자인 패턴은 일반적으로 최적화되므로 구현해야 할 코드가 적고 코드가 적으면 버그가 적습니다.

이 모든 것을 감안할 때 이미 프로젝트에서 디자인 패턴을 사용할 준비가 되어 있어야 합니다. JavaScript의 역사에 대한 간략한 개요를 제공하고 몇 가지 중요한 기능을 살펴본 다음 디자인 패턴에 대해 더 깊이 파고들 것입니다.

JavaScript의 간략한 역사

오늘날 JavaScript는 웹 개발에 가장 널리 사용되는 언어이지만 처음에는 HTML 요소 사이의 "접착제"에 불과했습니다. JavaScript는 Netscape 브라우저용 스크립팅 언어로 고안되었습니다. 그때까지 브라우저가 할 수 있는 일은 정적 HTML 페이지를 렌더링하는 것뿐이었습니다. JavaScript의 등장으로 인해 Netscape와 Microsoft 간의 전쟁이 일어났습니다.

90년대 초반의 대기업들은 자체 스크립트 언어인 Netscape with JavaScript(Brendan Eich가 1995년에 작성)와 Microsoft를 JScript로 사용하기를 원했습니다.

상상할 수 있듯이, 그때와 각 웹사이트는 특정 브라우저에 대해 수행해야 하는 많은 차이점이 있었고 항상 "...에서 가장 잘 볼 수 있음" 신호가 있었습니다. 곧 웹 페이지 생성을 단순화하고 개발 프로세스를 통합하기 위해 표준, 크로스 브라우저 언어가 필요하다는 것이 분명해졌습니다. 결과는 ECMAScript 입니다.

ECMAScript는 모든 브라우저가 지원하려고 하는 스크립트 언어에 대한 사양입니다. 여러 ECMAScript 구현이 있지만 가장 널리 사용되는 것은 JavaScript입니다. ECMAScript는 출시 이후로 많은 중요한 사항을 표준화했습니다 . Wikipedia 에 목록이 있습니다. 따라서 사람들이 ES6과 같은 것을 말할 때 ECMAScript 사양 버전 6의 JavaScript 구현을 참조하는 것입니다.

JavaScript의 몇 가지 중요한 기능

우리는 디자인 패턴을 구현하는 데 도움이 되는 언어의 일부 측면을 자세히 살펴볼 필요가 있습니다. 다음과 같이 JavaScript를 정의할 수 있습니다.

JavaScript는 대부분 웹 페이지용 언어로 알려진 1급 시민으로서의 기능을 가진 가벼운 언어로 해석되고 객체 지향됩니다.

그 정의는 JavaScript가 시스템 메모리에 작은 공간을 차지하고 사용하기 쉽고 배우기 쉬우며 다른 인기 있는 언어와 유사한 구문을 가지고 있다는 것입니다. 원래 JavaScript는 인터프리터 언어였지만 지금은 JIT(Just in Time) 컴파일러를 사용합니다. 절차적 프로그래밍, 객체 지향 프로그래밍 및 함수형 프로그래밍을 지원하므로 매우 유연하며 많은 문제가 발생합니다.

이제 JavaScript가 무엇이고 주요 특징을 알았으므로 몇 가지 기능을 살펴보겠습니다.

JavaScript는 일급 기능을 지원합니다

C 또는 C++와 같은 언어를 사용하는 경우 이해하기 어려울 수 있습니다. JavaScript가 함수를 일급 시민으로 취급한다는 것은 함수를 매개변수로 다른 함수에 공통 인수로 전달할 수 있다는 의미입니다. 마치 그것들이 물건인 것처럼.

 

JavaScript는 프로토타입을 기반으로 합니다.

다른 객체 지향 언어와 마찬가지로 JavaScript는 객체를 지원하며 객체라고 하면 즉시 클래스와 상속을 생각합니다. 여기서 상황이 이상해집니다. 원래 JavaScript는 클래스를 지원하지 않았으며 여전히 프로토타입을 기반으로 하는 상속을 사용합니다.

프로토타입 기반 프로그래밍은 확장되고 구현되지 않은 이미 존재하는 객체를 재사용하여 기능(상속)의 재사용을 구축하는 스타일입니다. 우리는 디자인 패턴 예제에서 이것을 더 잘 볼 것입니다. 이 특성은 많은 패턴에서 정말 중요합니다.

JavaScript의 이벤트 루프

JavaScript로 프로그래밍한 적이 있다면 callback 이라는 용어에 익숙할 것입니다 . 그렇지 않은 경우 콜백은 이벤트가 발생할 때 실행될 매개변수로 전달되는 함수입니다. 일반적으로 마우스 클릭이나 버튼 누름과 같은 이벤트를 수신하는 데 사용됩니다.

리스너가 있는 이벤트가 발생할 때마다 메시지는 FIFO(선입 선출) 방식으로 동기적으로 처리되는 대기열로 전송됩니다. 이것을 이벤트 루프라고 합니다.

대기열의 각 메시지에는 관련된 기능이 있습니다. 메시지가 대기열을 떠날 때마다 다른 메시지가 처리되기 전에 함수가 완전히 실행됩니다. 즉, 함수에 다른 함수에 대한 다른 호출이 포함되어 있으면 대기열의 새 메시지가 처리되기 전에 모두 수행됩니다. 이것을 완료까지 실행이라고 합니다.

 

queue.processNextMessage()동기식으로 새 메시지를 기다립니다 . 처리 중인 각 메시지에는 자체 스택이 있으며 스택이 비워질 때까지 처리됩니다. 모든 프로세스가 완료되면 큐에서 새 메시지를 읽습니다. 큐에 메시지가 있는 동안 계속 진행됩니다.

JavaScript는 차단되지 않는다는 말을 들어보셨을 것입니다. 비동기 작업이 처리 중일 때 프로그램은 기본 스레드를 차단하지 않고 새 입력과 같은 다른 작업을 계속 처리할 수 있습니다. 이 JavaScript 속성은 실제로 매우 유용합니다. 많은 사람들이 브라우저 외부에서 언어를 선택하는 이유입니다. 이것은 매우 흥미로운 주제이며 자신을 위한 게시물을 올릴 가치가 있습니다.

디자인 패턴이란?

디자인 패턴은 일반적인 소프트웨어 개발 문제에 대해 일반적으로 사용되는 솔루션입니다.

프로토 패턴

패턴은 어떻게 만들어지는가? 되풀이되는 문제를 인식하고 이 문제에 대한 고유한 솔루션이 있다고 가정해 보겠습니다. 스택 오버플로에서도 아직 문서화되지 않은 솔루션입니다. 이 문제를 발견할 때마다 이 솔루션을 사용하고 재사용할 수 있으며 모든 개발 커뮤니티가 이 솔루션을 통해 혜택을 받을 수 있다고 생각합니다.

솔루션이 즉시 패턴이 됩니까? 다행히도. 좋은 개발 관행을 가진 사람이 패턴처럼 보이는 것을 실제로는 패턴으로 착각하는 것은 정상입니다.

당신이 찾은 것이 정말 디자인 패턴인지 어떻게 알 수 있습니까?

다른 개발자와 공유함으로써 프로그래밍은 대규모 커뮤니티에서 하는 팀 스포츠입니다. 모든 패턴이 디자인 패턴, 프로토 패턴으로 알려지기 전에 통과해야 하는 페이즈 트로프가 있습니다.

프로토 패턴은 실제 패턴이 되기 전에 여러 개발자가 사용하고 테스트해야 합니다. 커뮤니티에서 패턴을 인식하고 사용할 수 있도록 문서화해야 할 작업이 많습니다.

안티 패턴

디자인 패턴이 좋은 습관을 나타내는 것처럼 안티 패턴은 나쁜 습관을 나타냅니다.

JavaScript에서 안티 패턴의 좋은 예는 Object프로토타입을 변경하는 것입니다. 실제로 JavaScript의 모든 객체는 다음에서 상속 Object하므로(JavaScript는 프로토타입 기반 상속을 사용함을 기억하십시오) 이 프로토타입을 변경했다고 상상해 보십시오. 에 대한 변경 사항 Object은 해당 객체에서 상속되는 모든 객체에서 볼 수 있습니다 . 이는 JavaScript의 거의 모든 객체일 것 입니다. 재앙이 일어나기를 기다리고 있습니다!

또 다른 예는 모르는 개체를 변경하는 것입니다. 응용 프로그램 전체에서 사용되는 개체에서 메서드를 약간 수정하면 큰 혼란을 초래할 수 있습니다. 팀이 커질수록 혼란이 커질 수 있습니다. 명명 충돌, 호환되지 않는 구현 및 유지 관리에 대한 악몽이 있을 것입니다. 운이 좋으면 테스트를 통해 어떤 일이 일어나기 전에 구할 수 있습니다.

좋은 습관을 아는 것이 중요한 것과 마찬가지로 나쁜 습관을 아는 것도 좋은 생각입니다. 이것은 오류를 깨닫고 너무 늦기 전에 방지하는 좋은 방법입니다.

디자인 패턴 카테고리

디자인 패턴은 여러 가지 방법으로 분류할 수 있으며 가장 많이 사용되는 방법은 다음과 같습니다.

• 창조적인 디자인 패턴
• 구조적 디자인 패턴
• 행동 디자인 패턴
• 동시성 디자인 패턴
• 건축 디자인 패턴

창조적인 디자인 패턴

이 패턴은 기본 객체 생성보다 최적화된 방식으로 객체 생성을 처리합니다. 일반적인 객체 생성 방식이 코드를 더 복잡하게 만들거나 코드에 문제를 일으킬 경우 생성 패턴으로 문제를 해결할 수 있습니다.

구조적 디자인 패턴

이러한 패턴은 개체 간의 관계와 함께 작동합니다. 시스템의 일부가 변경되더라도 다른 변경 사항이 없음을 보장합니다.

행동 디자인 패턴

이러한 종류의 패턴은 시스템 개체 간의 통신을 확인, 구현 및 개선합니다. 애플리케이션의 관련 없는 부분이 동기화된 정보를 갖도록 보장하는 데 도움이 됩니다.

동시성 디자인 패턴

멀티 스레딩 프로그래밍을 다룰 때 사용하고 싶은 패턴은 다음과 같습니다.

건축 디자인 패턴

MVC 또는 MVVM과 같은 시스템 아키텍처에서 사용되는 디자인 패턴입니다.

다음 섹션에서는 더 나은 이해를 위한 예제와 함께 이러한 패턴 중 일부를 살펴보겠습니다.

내가 좋아하는 9가지 디자인 패턴의 예

각 디자인 패턴은 주어진 문제에 대한 솔루션을 나타냅니다. 직면하게 될 모든 문제를 해결할 보편적인 패턴 세트는 없습니다. 주어진 패턴이 언제 유용하고 실제로 어떻게 가치를 제공하는지 이해해야 합니다. 디자인 패턴과 해당 패턴에 익숙해지면 사용할 수 있는 패턴과 당면한 문제를 해결할 수 있는 패턴을 결정할 수 있습니다.

잘못된 패턴을 사용하면 원치 않는 효과, 불필요한 복잡성 및 성능 손실이 발생할 수 있습니다.

이것은 우리가 코드에 디자인 패턴을 적용할 때 고려해야 할 중요한 사항입니다. JavaScript에서 더 유용하고 모든 선임 JavaScript 개발자가 알아야 하는 몇 가지 패턴을 살펴보겠습니다.

1. 생성자 패턴

객체 지향 언어의 고전적인 구현을 생각할 때 생성자는 기본 또는 호출자의 입력으로 클래스 값을 초기화하는 특수 함수입니다.

JavaScript에서 객체를 생성하는 세 가지 일반적인 방법은 다음과 같습니다.

 

객체가 생성된 후 속성을 추가하는 네 가지 방법이 있습니다. 그들은:

 

객체 생성을 위한 가장 일반적인 방법 {}은 점 표기법 또는 를 사용하여 속성을 추가하는 것 []입니다. 그렇기 때문에 이 방법을 사용하는 것이 좋습니다. 다른 프로그래머가 코드와 미래의 자신을 훨씬 더 쉽게 이해할 수 있습니다.

앞서 JavaScript는 기본 클래스를 지원하지 않지만 new함수 호출에 접두어가 붙은 키워드를 통해 생성자를 지원한다고 언급했습니다. 이렇게 하면 함수를 생성자로 사용하고 보다 전통적인 언어에서와 동일한 방식으로 속성을 초기화할 수 있습니다.

 

우리는 여전히 이 코드를 개선할 수 있습니다. 문제는 writesCode 메서드가 Person 의 모든 인스턴스에 대해 재정의 된다는 것입니다 . JavaScript는 프로토타입 기반이기 때문에 프로토타입에 메서드를 추가하여 이를 방지할 수 있습니다.

 

이제 Person 의 두 인스턴스 모두 의 동일한 공유 인스턴스에 액세스할 수 있습니다 writesCode().

마치 첫 번째 예 에서 type 의 각 객체에 대해 서로 다른 메서드Person 가 있는 것과 같습니다 . 각각 Person은 고유한 함수 정의를 가리킵니다. 두 번째 예에서 모든 Persons는 동일한 기능, 동일한 코드를 가리킵니다.

2. 모듈 패턴

객체 지향임에도 불구하고 JavaScript는 고유한 방식으로 이를 수행합니다. 적절한 클래스가 없기 때문에 클래스의 구성 요소에 대한 액세스를 제한할 수도 없습니다. Java 또는 C++와 같은 언어에서는 클래스의 멤버(private, protected, public 등)에 대한 액세스 권한을 정의할 수 있지만, 아주 영리한 일인 만큼 JavaScript에는 이 동작을 에뮬레이트하는 방법이 있습니다.

모듈 패턴에 대해 자세히 알아보기 전에 클로저 에 대해 더 자세히 살펴보겠습니다 . 클로저는 부모가 완료된 후에도 부모의 범위에 액세스할 수 있는 함수입니다. 그것들은 우리가 접근 제한자의 행동을 모방하는 데 도움이 될 것입니다. 예를 들어 보겠습니다.

 

보시다시피, 우리는 변수 counter 를 호출되고 닫힌 함수에 연결했지만 여전히 counter를 증가시키는 자식 함수를 통해 액세스할 수 있습니다. 내부 함수는 에서 반환됩니다 counterIncrementer(). 우리는 함수 외부에서 카운터에 액세스할 수 없습니다. 본질적으로 우리는 바닐라 JavaScript 트로프 범위 조작에서 개인 변수를 생성했습니다.

클로저를 사용하여 공개 및 비공개 부분이 있는 객체를 만들 수도 있습니다. 이것은 객체의 일부를 숨기고 모듈 사용자를 위한 멋진 인터페이스만 제공하고자 할 때 매우 유용합니다. 예:

 

이 패턴의 가장 큰 유용성은 객체의 공개 부분과 비공개 부분을 명확하게 구분하는 것입니다.

모든 것이 행복은 아닙니다. 이 패턴에는 몇 가지 문제가 있습니다. 멤버의 가시성을 변경하려면 공개 부분과 비공개 부분에 대한 액세스가 다르기 때문에 모든 호출자에 대해서도 변경해야 합니다. 또 다른 문제는 객체가 생성된 후에 추가된 메서드가 private 메서드에 액세스할 수 없다는 것입니다(하지만 우리는 어쨌든 새 메서드를 추가하고 싶지 않습니다).

3. 모듈 패턴 공개

이것은 위에서 설명한 모듈 패턴의 진화입니다. 주요 차이점은 모든 개체의 논리를 개인 범위에 작성한 다음 익명 개체를 통해 원하는 것을 노출한다는 것입니다. 공개 멤버에 매핑할 때 비공개 멤버의 이름을 변경할 수도 있습니다.

 

공개 모듈 패턴은 모듈 패턴을 구현할 수 있는 방법 중 하나입니다. 공개 모듈 패턴과 다른 변형 간의 차이점은 주로 공개 모듈을 참조하는 방식입니다. 결과적으로 노출 모듈 패턴은 사용 및 변경이 훨씬 쉽습니다. 예를 들어 상속 체인에서 개체를 사용할 때 특정 시나리오에서는 여전히 취약한 것으로 판명될 수 있습니다. 가장 문제가 되는 상황은 다음과 같습니다.

1. 공개 함수를 참조하는 비공개 함수가 있는 경우 공개 함수를 덮어쓸 수 없습니다. private 함수는 계속 private 구현을 가리키며 버그가 발생합니다.
2. private 멤버를 가리키는 public 멤버가 있고 모듈 외부에서 public 멤버를 덮어쓰려고 할 때 다른 모든 함수는 여전히 private 값을 참조하여 버그가 발생합니다.

4. 싱글톤 패턴

클래스의 단일 인스턴스를 허용하려면 싱글톤 패턴을 사용합니다. 예를 들어 구성 개체가 있는 경우 호출할 때마다 새 개체를 만들고 싶지는 않습니다. 항상 동일해야 합니다. 그렇지 않으면 매번 다른 설정을 가질 수 있습니다.

 

생성된 난수는 항상 config의 값과 동일합니다.

5. 관찰자 패턴

The observer pattern is very useful when we want to optimize the communication between separated parts of the system. It promotes an integration of the parts without making then too coupled.

you will find several different ways to implement this pattern, but the simpler case is when we have one emitter and lots of observers.

The emitter will execute all the operations to which the observers are subscribed. Those operations can be, subscribe to a topic, unsubscribe from a topic and notify subscribers every time something is published to a topic.

One variant to this pattern is the publisher/subscriber pattern, which is the one we will see on this text.

관찰자 패턴에서 이미터는 관찰자에 대한 모든 참조를 유지하고 이러한 개체에서 직접 메서드를 호출합니다. 반면 게시자/구독자 패턴에는 게시자와 구독자 간의 통신 계층 역할을 하는 채널이 있습니다. 게시자는 이벤트를 발생시키고 이 이벤트로 전송된 콜백을 실행합니다.

다음은 게시자/구독자 패턴의 작은 예입니다.

 

이 디자인 패턴은 서로 다른 장소의 단일 이벤트에 응답하려는 경우에 특히 유용합니다. API에 여러 요청을 해야 하고 응답에 따라 다른 호출을 해야 한다고 상상해 보십시오. 여러 콜백을 중첩해야 하며 이는 관리하기 어려울 수 있습니다. 게시자/구독자 패턴을 사용하면 훨씬 간단한 방법으로 이 상황을 해결할 수 있습니다.

이 패턴의 문제는 테스트입니다. 게시자와 청취자의 행동을 테스트하기 어려울 수 있습니다.

6. 중재자 패턴

decoupled system에서 많이 사용되는 패턴은 mediator이다. 조정된 방식으로 통신해야 하는 시스템의 다른 부분이 있는 경우 중재자가 최선의 선택이 될 수 있습니다.

실생활과 마찬가지로 매개체는 다른 대상들 간의 소통의 중심이 되는 대상이다.

첫눈에 중재자와 게시자/구독자 패턴은 매우 유사해 보입니다. 그리고 실제로 둘 다 요소 간의 통신을 관리하는 데 사용됩니다. 차이점은 게시자/구독자는 이벤트를 아무렇게나 던지고 잊어버리는 반면 중재자는 각 구독자를 돌보고 메시지를 확실히 처리한다는 것입니다.

중재자 패턴의 좋은 사용 사례는 마법사입니다. 시스템에 등록하는 데 시간이 오래 걸린다고 가정해 보겠습니다. 일반적으로 큰 양식은 여러 단계로 나뉩니다.

이것은 코드에 대한 유지 관리를 더 쉽게 하는 방법이며 동시에 사용자는 거대한 형태에 압도되지 않을 것입니다. 중재자는 각 단계의 입력과 함께 다른 단계의 사용을 보여주면서 전체 마법사를 관리할 수 있습니다.

이 패턴의 명백한 이점은 시스템 부분 간의 통신이 향상된다는 것입니다. 토론에서 발생하는 것과 같은 방식으로 중재자는 각 사람이 말할 시간이 있고 아무도 순서가 맞지 않는 말을 하지 않도록 합니다.

중재자는 단일 실패 지점이 되며 중단되면 모든 것이 중단됩니다. 이것이 이 패턴의 주요 문제입니다.

7. 프로토타입 패턴

이 글을 읽는 것이 지겹겠지만 JavaScript는 기본 형식의 클래스를 지원하지 않습니다. 상속은 프로토타입을 통해 이루어집니다.

생성될 다른 객체의 프로토타입으로 사용될 객체를 생성할 수 있습니다. 프로토타입은 생성자가 만드는 객체의 청사진입니다. Java에서 클래스와 객체를 구별하는 것과 거의 같습니다.

이 패턴의 예를 살펴보겠습니다.

 

프로토타입에 의한 상속은 결국 성능 향상을 가져옵니다. 두 객체 모두 각각에 구현되는 대신 프로토타입에 구현된 동일한 메서드에 대한 참조를 갖기 때문입니다.

8. 명령 패턴

명령 패턴은 호출을 개체로 캡슐화하려는 경우에 사용됩니다. 호출자와 호출자의 컨텍스트를 분리된 상태로 유지하는 방법입니다.

JavaScript 애플리케이션에 API에 대한 여러 호출이 있다고 가정해 보겠습니다. 이제 API가 변경된다고 상상해 보십시오. API와 상호 작용하는 모든 위치를 변경하고 싶지는 않습니다.

API를 호출하는 객체와 API를 호출할 시기 를 결정하는 객체를 분리하는 추상화 계층이 있는 곳 입니다. 이렇게 하면 호출만 변경하면 되므로 애플리케이션에서 큰 변경을 수행할 필요가 없습니다. API를 한 곳에서.

이 패턴에서 발생하는 문제는 추가 추상화 계층을 생성하고 앱의 성능에 영향을 줄 수 있다는 것입니다. 성능과 코드 가독성의 균형을 맞추는 방법을 아는 것이 중요합니다.

 

9. 외관 패턴

파사드 디자인 패턴은 공개적으로 보여지는 것과 내부 구현 사이에 추상화 레이어를 만들고 싶을 때 사용됩니다. 더 간단한 인터페이스를 원할 때 사용됩니다.

이 패턴은 예를 들어 JQuery, Dojo 및 D3와 같은 라이브러리의 DOM 선택기에서 사용됩니다. 이러한 프레임워크에는 매우 간단한 방법으로 복잡한 쿼리를 작성할 수 있는 강력한 선택기가 있습니다. 뭔가 jQuery(".parent .child div.span")단순해 보이지만 그 밑에 복잡한 쿼리 논리가 숨겨져 있습니다.

여기서도 코드 위에 추상화 계층을 만들 때마다 결국 성능이 저하될 수 있습니다. 대부분 이 손실은 관련이 없지만 항상 고려하는 것이 좋습니다.

결론

디자인 패턴은 모든 JavaScript 개발자를 위한 기본 도구입니다. 그들은 모든 것을 더 간단하고 이해하기 쉽게 만들어 코드를 유지 관리해야 할 때 많은 협력을 합니다.

이 게시물이 정말 길어집니다. 디자인 패턴에 대해 더 알고 싶다면 고전 책 Design Patterns: Elements of Reusable Object-Oriented Software from the Gang of four와 또한 Addy Osmani 의 보다 현대적인 Learning JavaScript Design Patterns 를 추천합니다. 두 책 모두 정말 훌륭하고 읽을 가치가 있습니다(링크는 관련이 없습니다).

이것은 긴 기사였습니다. 여기까지 읽으셨다면 Medium에서 저를 팔로우하고 친구들과 공유하는 것을 고려해 보세요!

독립 구성 요소로 10배 개발

모놀리식 앱을 빌드한다는 것은 모든 코드가 내부에 있고 다른 곳에서는 유용하지 않다는 것을 의미합니다. 그것은 단지 이 하나의 프로젝트를 제공합니다. 그리고 더 많은 코드와 사람으로 확장함에 따라 모든 사람이 하나의 코드베이스와 동일한 버전에서 작업하기 때문에 개발이 느려지고 고통스러워집니다.

그러나 독립적인 구성 요소를 먼저 구축한 다음 이를 사용하여 여러 프로젝트를 구축하면 어떻게 될까요? 최신 개발을 10배 가속화하고 확장할 수 있습니다.

Bit 와 같은 OSS 도구는 독립적인 구성 요소를 구축하고 모듈식 응용 프로그램을 구성하기 위한 강력한 개발자 경험을 제공합니다. 많은 팀은 독립적인 구성 요소를 통해 디자인 시스템 또는 마이크로 프론트엔드를 구축하는 것으로 시작합니다. 한번 해보세요 →