전체 글 163

CSS 레이아웃 비교 - Float vs Flex vs Grid

레이아웃을 코딩하는 방법은 다양한 방법이 있습니다. Float, Flex, Grid 순서로 레이아웃을 배치하는 방법이 발전되었습니다. 각 기술들의 차이와 가장 최근에 만들어진 Grid를 사용하면 어떤 장점이 있는지 정리했습니다. 그리드 시스템 구현 6 Grid를 1:3:2로 나누고 각각 같은 여백을 가질 때 코드를 비교해보겠습니다. 그리드 시스템 Float Float로 개발할 때는 가로 사이즈를 직접 계산해서 작성해야 됐고, overflow: hidden과 같은 특별한 방법을 사용해서 코딩을 해야 됐습니다. 1/6 3/6 2/6 .box {overflow: hidden} .item {float: left} .item:nth-of-type(1) { width: calc((100% - 20px) * 1 / ..

동시성과 병렬성 한 장에 정리

동시성 동시성은 동시에 얼마나 다양한 일들을 컨트롤할 수 있는지! 예를 들어 웹 브라우저에서 동영상을 재생하고 있을 때, 플레이 리스트 스크롤이나 댓글 작성 등 다양한 일을 함께 할 수 있는 것이 동시성 구현이다. 웹 브라우저는 메인 스레드 하나로 동작한다. 때문에 버벅임 현상 최소화를 위해 Idle Time[1]을 확보하고, Long Task[2]를 최소화해야 한다. 용어 정의 [1] Idle Time 메인 쓰레드의 작업이 없는 50ms 시간. 사용자 인터렉션이 발생할 수 있는 시간. [2] Long Task 50ms 이상 메인 쓰레드의 실행 시간 병렬성 병렬성은 동시에 얼마나 많은 일들을 할 수 있는지! 예를 들어 자바스크립트로 약 5초 걸리는 작업[1]을 웹 워커 5개로 실행[2]하면 좀 더 빠른 ..

순수 함수와 일급 함수 한 장에 정리

순수 함수 순수 함수는 동일한 인자에 상응하는 동일한 리턴 값을 가지는 함수입니다. 그러므로, 평가 시점이 변경이 되더라도 동일한 결과를 리턴하기 때문에 다루기 쉬운 함수가 됩니다. 순수 함수는 객체의 변경이 필요할 경우 새로운 객체를 생성하여 리턴합니다. 외부 변수를 사용하거나 외부 변수를 변경하면 순수 함수가 아닙니다. 비순수 함수는 평가 시점에 따라 다른 결괏값을 가지기 때문에 평가 시점을 미세하게 다뤄야 합니다. // 순수함수 const add = (a, b) => a + b; const add1 = (obj, b) => ({val : obj.val + b}) // 비순수함수 const add2 = (a, b) => a + b + c; const add3 = (a, b) => { c = b; re..

DOM Event의 역사와 정의

DOM Event의 역사 1) DOM Event API는 DOM Level 2에서 논리적으로 표준화하려는 시도했음 2) DOM Level 2의 개정 전, Internet Explorer와 Netscape가 서로 정반대 이벤트 흐름을 채택함. Internet Explorer는 이벤트 버블링, Netscape는 이벤트 캡쳐링 3) 현재는 두 이벤트 흐름을 모두 지원함 DOM Event의 정의 javascript와 HTML 간의 상호작용을 담당 옵져버 패턴으로 이벤트가 발생할 때만 리스너가 실행 이벤트 버블링 1) 이벤트 흐름상 문서 트리에서 가장 깊이 위치한 요소에서 시작해 거슬러 올라감 2) 가장 깊이 위치한 요소에서 시작해 거슬러 흐르는 모양이 마치 거품이 올라가는 것 같아 버블링이라함 이벤트 캡처링 1..

JavaScript - Decorators Proposal과 실용성

Decorators Proposal 1) tc39/proposal-decorators에 제안서 정의됨. 2) Orthogonal Classes와 Class Evaluation Order 제안을 바탕으로 Decorators와 Class Field 및 Private methods를 함께 작동시키는 방법에 대한 결합된 비전을 제안. 3) Decorators는 이미 정의된 클래스, 함수, 변수의 코드를 수정하지 않고, 기능을 추가하는 것에 유용함 4) 메모이제이션, 접근 제어, 인증, 계측, 타이밍 처리, 로깅, 속도 제한 등에 사용된다. Decorators 실용성 JavaScript에서는 Decorators를 사용할 수 없지만 TypeScript에서 Decorators를 사용할 수 있다. 그래서 Node.js..

TypeScript - Union Type 정의와 사용법 간단 정리

Union Type 이란? Union Type은 두 개 이상의 타입을 조합해서 정의한 타입이다. 예를 들어 다수의 자료형이 있으면, interface Square { kind: 'square' size: number } interface Rectangle { kind: 'rectangle' width: number height: number } interface Circle { kind: 'circle' radius: number } Union Type은 이렇게 |로 구분해서 정의한다. type Shape = Square | Rectangle | Circle Union Type의 타입 추론 TypeScript에서는 타입 추론(type inference)을 통해 각 타입을 추론하게 된다. TypeScrip..

SOLID 원칙 시리즈 - 의존성 역전 원칙

DIP: 의존성 역전 원칙 (Dependency Inversion Principle) 의존성 역전 원칙에서 말하는 유연성이 극대화된 시스템이란 소스 코드 의존성이 추상에 의존하여 구체에는 의존하지 않는 시스템이다. 이 아이디어를 규칙으로 보기는 확실히 비현실적이다. 소프트웨어 시스템이라면 구체적인 많은 장치에 반드시 의존하기 때문이다. DIP를 논할 때 운영체제나 플랫폼같이 안전성이 보장된 환경에 대해서는 무시하는 편이다. 우리가 의존하지 않도록 피하고자 하는 것은 바로 변동성이 큰 구체적인 요소이다. 그리고 이 구체적인 요소는 우리가 열심히 개발하는 중이라 자주 변경될 수밖에 없는 모듈들이다. 인터페이스는 구현체보다 변동성이 낮다. 그래서 실제로 뛰어난 소프트웨어 설계자와 아키텍트라면 인터페이스의 변동..

SOLID 원칙 시리즈 - 인터페이스 분리 원칙

ISP: 인터페이스 분리 원칙 (Interface Segregation Principle) Ops 클래스 그리고 op1, op2, op3 오퍼레이션이 있고 사용자 클래스인 User1, User2, User3가 있다고 가정하겠다. User1은 op1만 사용하고, User2은 op2만 사용하고, User3은 op3만 사용한다. Ops의 오퍼레이션이 하나라도 수정되면 사용자 클래스는 모두 수정되어야 한다. 각 사용자 클래스는 사용하지 않는 오퍼레이션에 의존하고 있다. 오퍼레이션의 의존성을 분리하기 위해서는 op1, op2, op3의 인터페이스를 분리하여 해결할 수 있다. ISP를 아키텍처가 아니라 언어와 관련된 문제라고 결론 내일 여지가 있다. 정적 타입언어는 사용자가 타입선언문을 사용하도록 강제한다. 선언문..

SOLID 원칙 시리즈 - 리스코프 치환 원칙

LSP: 리스코프 치환 원칙 (Liskov Substitution Principle) 리스코프 치환 원칙는 바바라 리스코프가 정의한 원칙으로 바바라 리스코드는 하위 타입을 다음과 같이 정의했다. 여기에서 필요한 것은 다음과 같은 치환(substitution) 원칙이다. S타입의 객체 o1 각각에 대응하는 T타입 객체 o2가 있고, T타입을 이용해서 정의한 모든 프로그램 P에 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위타입이다. LSP는 아키텍처 수준까지 확장할 수 있고, 반드시 확장해야만 한다. 치환 가능성을 조금이라도 위배하면 시스템 아키텍처가 오염되어 상당량의 별도 메커니즘을 추가해야 할 수 있기 때문이다. SOLID 원칙 시리즈 - 리스코프 치환 원칙 LSP: 리..

SOLID 원칙 시리즈 - 개방-패쇄 원칙

OCP: 개방-패쇄 원칙 (Open-Closed Principle) 개방 폐쇄 원칙은 "소프트웨어 개체(artifact)는 확장에는 열려 있어야 하고, 변경에는 닫혀있어야 한다."를 의미한다. 다시 말해 소프트웨어 개체의 행위는 확장할 수 있어야 하지만, 이때 산출물을 변경해서는 안 된다. 소프트웨어 아키텍처를 공부하는 가장 근본적인 이유가 바로 이 때문이다. 만약 요구사항을 살짝 확장하는 데 수정사항이 많다면 설계한 아키텍트는 엄청난 실패에 맞닥뜨린 것이다. 소프트웨어 아키텍처가 훌륭하다면 변경되는 코드의 양이 가능한 한 최소화될 것이다. 이상적인 변경량은 0이다. 어떻게 하면 될까? 서로 다른 목적으로 변경되는 요소를 적절하게 분리하고(단일 책임 원칙, SRP), 이들 요소 사이의 의존성을 체계화함으..

SOLID 원칙 시리즈 - 단일 책임 원칙

SRP: 단일 책임 원칙 (Single Responsibility Principle) 역사적으로 SRP는 "단일 모듈은 변경의 이유가 하나. 오직 하나뿐이어야 한다."로 기술되어 있다. 변경의 이유는 무엇을 의미하는 할까? 소프트웨어 시스템은 사용자와 이해관계자를 만족시키기 위해 변경된다. SRP가 말하는 변경의 이유는 바로 이들 사용자와 이해관계자를 가리킨다. 단일 모듈은 무엇을 의미하는 할까? 가장 단순한 정의는 소스파일이다. 대부분의 경우 이 정의는 잘 들어 맞는다. 하지만 일부 언어와 개발 환경에서는 코드를 소스파일에 저장하지 않는다. 이러한 경우 모듈은 단순히 함수와 데이터 구조로 구성된 응집된 집합이다. 응집된이라는 단어가 SRP를 암시한다. 단일 액터를 책임지는 코드를 함께 묶어주는 힘이 바..

의존성 역전! 한장에 정리

일반적인 상황의 제어흐름 일반적인 상황에서 프로그램은 Top-Down으로 제어흐름이 흐른다. 다형성으로 인한 의존성 역전 현상 다형성이 끼어들면 의존성 역전 현상이 발생한다. HL1 모듈은 인터페이스를 통해 F()를 호출한다. ML1과 I 인터페이스 사이의 소스코드 의존성이 제어흐름과 반대이다. 결론 객체지향 언어가 다형성을 안전하고 편리하게 제공한다는 사실은 소스 코드 의존성을 어디에서든 역전시킬 수 있다는 뜻이기도 하다. 결국 소스 코드 의존성이 제어흐름의 방향과 일치되도록 제한되지 않는다. 의존성 역전! 한장에 정리 일반적인 상황의 제어흐름 일반적인 상황에서 프로그램은 Top-Down으로 제어흐름이 흐른다. 다형성으로 ... blog.naver.com

728x90