개요 파사드는 라이브러리, 프레임워크 또는 기타 복잡한 클래스 집합에 단순화된 인터페이스를 제공하는 디자인 패턴이다. 해결하려는 문제 정교한 라이브러리나 프레임워크의 다양한 객체들을 다룰 때 모든 객체를 초기화하고, 종속성을 추적하고, 메서드를 올바른 순서로 실행하는 등의 작업을 수행해야 한다. 결과적으로 클래스의 비즈니스 로직이 써드 파티 라이브러리의 구현 세부 사항과 긴밀하게 결합되어 유지 관리가 어려워지게 된다. 해결법 파사드는 복잡한 서브시스템에 간단한 인터페이스를 제공하는 클래스다. 파사드는 서브시스템을 직접 사용하는 것보다 제한된 기능을 제공할 수 있다. 하지만 클라이언트가 실제로 중요하게 생각하는 기능만 포함한다. 파사드는 수십 개의 기능이 포함된 정교한 라이브러리와 앱을 통합해야 하지만 일..

6장 아키텍처를 고려할 때 변수의 가변성을 염려할까? 대답은 단순하다. 경합race 조건, 동시 업데이트concurrent update 문제가 모두 가변 변수로 인해 발생하기 때문이다. 다시 말해 우리가 동시성 애플리케이션에서 마주치는 모든 문제, 즉 다수의 스레드와 프로세스를 사용하는 애플리케이션에서 마주치는 모든 문제는 가변 변수가 없다면 절대로 생기지 않는다. 변수를 변경하는 컴포넌트와 변경하지 않는 컴포넌트를 분리해야 한다. 이렇게 분리하려면 가변 변수들을 보호하는 적절한 수단을 동원해 뒷받침해야 한다. 현명한 아키텍트라면 가능한 한 많은 처리를 불변 컴포넌트로 옮겨야 하고, 가변 컴포넌트에서는 가능한 한 많은 코드를 빼내야 한다. 이벤트 소싱 계좌 잔고를 변경하는 대신 트랜잭션 자체를 저장한다고..

1장 설계 design와 아키텍쳐 사이에는 어떤 차이가 있을까? 아무런 차이가 없다. 아키텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용된다. 설계는 저수준의 구조 또는 결정사항 등을 의미할 때가 많다. 설계의 목표는? 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다. 2장 모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공한다. 행위와 구조가 바로 그것이다. 대부분의 프로그래머는 행위(시스템이 동작하도록 하는 것)가 자신이 해야 할 일의 전부라고 생각한다. 소프트웨어라는 단어는 부드러운soft과 제품ware이라는 단어의 합성어이다. 제품이라는 단어는 상품product를 뜻하며, 부드러운soft이라는 단어는 행위를 쉽게 변경할 수 ..

다음의 글을 번역했습니다. 학습을 위해 번역하여 많은 부분을 생략하였습니다. https://blog.isquaredsoftware.com/2021/01/context-redux-differences/ Context와 Redux 이해하기 어떤 도구든 올바르게 사용하기 위해, 다음을 이해하는 것이 중요하다. 도구의 목적 도구가 해결하고자 하는 문제 언제 그리고 왜 이 도구가 생겨났는지 또한 현재 자신의 애플리케이션에서 해결하려는 문제가 무엇인지 이해하고, 이 문제를 해결하기 위한 도구를 선택하는 것 또한 중요하다. 컨텍스트와 리덕스에 대한 대부분의 혼란은 이러한 도구가 실제로 어떤 기능을 하는지, 어떤 문제를 해결하는 지에 대한 이해 부족에서 비롯된다. 따라서 실제로 언제 사용해야 하는지 알기 위해서는 먼저..

코드스쿼드 과정 중 바닐라 자바스크립트로 옵저버패턴을 통해 데이터 바인딩을 시도한 적이 있다. 하지만 Observable이 관리하는 observers에 이미 사용되지 않는 observer들이 누적해서 쌓이는 문제가 있었다. 명시적인 unsubscribe로 제거해주면 되지 않을까? 옵저버 패턴의 메모리 누수 (memeory leak)에 대해 검색해 봤을 때 많은 글에서는 다음과 같은 해결법을 말하고 있었다. 참고로 TS를 사용한다면 Updatable 인터페이스를 정의했을테지만, 글의 간략함을 위해 JS로 작성한다. class Observable { constructor() { this.observers = []; } subscribe(observer) { this.observers.push(observer..

기존 번들러의 어떤 점이 문제였을까? 기존의 번들러들 (Webpack, Parcel, Rollup, … )들은 기존 모듈 시스템들의 문제점을 해결해주었지만, 이제는 속도가 문제가 되었다. Vite의 공식문서에서는 이런 차세대 번들러가 어떤 문제를 해결하는지 명확히 알려주고 있다. “하지만 애플리케이션이 점점 더 발전함에 따라 처리해야 하는 JavaScript 모듈의 개수도 극적으로 증가하고 있습니다. 심지어 수천 개의 모듈이 존재하는 것도 대규모 프로젝트에서는 그리 드문 일이 아닙니다. 이러한 상황에서 JavaScript 기반의 도구는 성능 병목 현상이 발생되었고, 종종 개발 서버를 가동하는 데 비합리적으로 오랜 시간을 기다려야 한다거나 HMR을 사용하더라도 변경된 파일이 적용될 때 까지 수 초 이상 소..