
## Process Management

### 프로세스의 생성

- 부모 프로세스가 자식 프로세스를 만듦. (**트리 구조**)
- 프로세스는 자원을 필요로 함 (os로부터 받음, 부모와 공유)

### 복제 생성 (fork, exec)

- 자식 프로세스는 부모의 문맥(주소공간, 운영체제 등 자원, code,data, stack etc.)을 모두 복사
- fork: 자식이 그대로 복사. 일단 복제해놓고
- exec: 그 공간에 새 프로그램을 올림
- 자원은 공유 하기도, 안 하기도 (보통은 공유 X) 함. 공유를 해야 자원 등 절약이 가능하니까. 리눅스같은 효율적인 운영체제에서는 무작정 카피하지 않음. 스택이 달라지거나 분리가 필요할 때 **Copy-On-Write (cow). 즉, write가 발생할때 카피한다**.

### fork 코드 예시

![C언어 fork](https://user-images.githubusercontent.com/50111853/154212591-5918ba6c-ea96-453a-961b-0fdc3c967d3d.png)

- fork()한 후 반환된 pid가 새로 생기는 자식 프로세스의 pid.
- Pid로 자식/부모 프로세스 구분함. pid가 0인게 자식 프로세스
- 자식 프로세스의 경우도 부모 프로세스의 문맥(especially **프로그램 카운터)을 그대로 받기 때문에 fork()이후 코드부터** 계속 실행함. (무한루프 아님!)

### execlp 코드 예시

![C언어 exec](https://user-images.githubusercontent.com/50111853/154213451-ca76f59a-5c66-4342-ab2c-ab02ff0defa7.png)

- exec으로 덮어써서 execlp 안에 있는 함수를 실행하는 프로세스가 된다.
- 예시의 경우 리눅스 명령어임
- fork 안 하고 그냥 execlp만도 가능함

### wait

![wait 예시](https://user-images.githubusercontent.com/50111853/154214087-90459328-e68e-4712-9650-37727407008a.png)

- 프로세스를 blocked 상태로 바꿔서 잠들게 함
- 부모가 자식 프로세스가 종료되길 기다리려고 sleep

### 종료 (exit)

- 자식이 부모에게 output data를 보냄(via wait)
- 자식프로세스의 각종 자원이 os로 반납됨.

#### 종료 종류

자발적: 마지막 문장 실행 후 exit(), 컴파일러가 자동으로 중괄호 닫히는 곳(main 함수 리턴될때)에 exit 삽입
비자발적: 부모가 자식프로세스 종료(abort), 키보드로 kill or break 클릭, 부모가 종료됨

### 부모가 종료시킴 (abort)

- 자식이 할당 자원의 한계를 넘어선 경우 or 그 태스크가 더이상 필요하지 않은 경우 or 부모 프로세스가 종료되는 경우
- 자식이 무조건 부모 프로세스보다 먼저 죽는다.

fork, exec, wait, exit, abort 다 **시스템 콜**

### 프로세스간 협력 매커니즘 (Interprocess Communication, IPC)

![IPC](https://user-images.githubusercontent.com/50111853/154215397-d639f937-1832-4728-958c-0df27e3e2636.png)

- **shared memory**: 일부 주소공간을 두 프로세스가 공유 (커널한테 그 공간 쓴다고 얘기한 후에는 자기들끼리 알아서)
- **message passing**: 공유변수 일체 없이 **운영체제 커널을 통해** 메시지를 보냄.
- 1. direct: 메시지 받을 프로세스 이름을 직접 명시
- 2. indirect: mailbox 또는 port 이름을 통해 간접 전달

쓰레드는 사실상 프로세스이므로 **동일한 프로세스를 구성하는 쓰레드간 협력 당연히 가능함.**

### CPU and I/O Burst

![스크린샷 2022-02-16 오후 4 22 42](https://user-images.githubusercontent.com/50111853/154215769-6e0246a6-cd25-475f-abd3-c18162082784.png)
프로그램이 실행된다는건 CPU burst+ io burst가 반복되는 것이다.

![스크린샷 2022-02-16 오후 4 24 22](https://user-images.githubusercontent.com/50111853/154216000-0e217f07-43dc-491d-8e92-0c96fd767d79.png)

- IO-bound Job: 사람이 많이 끼어들고 **인터랙션이 많으면** io burst가 잦고 길다
- CPU-bound Job: 과학 연산 등은 주로 CPU를 많이 쓰고 CPU burst가 길다

-> **인터랙션이 많은 IO bound 잡한테 CPU를 많이 줘야 사용자가 안 답답함** -> CPU 스케줄링의 주요한 이슈

프로세스는 io bound / cpu bound 프로세스 두개로 나뉜다.

## 공부가 끝나고 느낀  점

- 부모 프로세스가 자식 프로세스를 만드는 건 알았는데 구체적인 방법과 그때 사용되는 명령어를 알게 돼서 지식이 깊어진 느낌이다.
- 지난 챕터들에서 배웠던 프로그램 카운터나 blocked 등의 개념이 이번 장에도 연결돼 나와서 엮어가며 생각해보는 맛이 있었다.


프로세스의 생애주기와 협력 매커니즘

프로세스의 생애주기, 협력 매커니즘, CPU Burst cycle


[강의](https://core.ewha.ac.kr/publicview/C0101020140318134023355997)

## 프로세스

: 실행중인 프로그램

### 프로세스의 문맥

**1. CPU 수행 상태를 나타내는 하드웨어 문맥**

- 프로그램 카운터가 어딜 가리키는지, 레지스터가 어떤 값을 가지고 있었는지

**2. 메모리와 관련된 프로세스의 주소 공간**

- 코드, 데이터, 스택

**3. 프로세스 관련 커널 자료구조**

- 프로세스가 시작될 때마다 운영체제는 PCB라는 자료구조를 가짐.
- 프로세스가 시스템 콜 일으키면 커널이 코드를 실행.

=> 프로세스가 번갈아 실행(시분할)되기 때문에 어디까지 작업했는지 기억하기 위해선 프로세스의 문맥을 알아야함.

### 프로세스의 상태 (CPU 관점)

![프로세스 상태도](https://images.velog.io/images/hailey99/post/ca7f82ef-8a52-4415-9e8e-62de67aa3c6d/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202022-02-13%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%206.32.56.png)

1. Running: CPU를 잡고 명령어 수행중
2. Ready: **다른 조건 다 만족하고** CPU 대기하는 중 (필요한 자원이 메모리에 올라와있고)
3. Blocked(wait, sleep): CPU가 있어도 당장 명령어 수행 불가한 상태 / **IO 등 오래 걸리는 작업** 중일 때
4. New: 프로세스가 생성중
5. Terminated: 수행 끝
6. Suspended: 중기 스케줄러에게 메모리를 뺏긴 상태. 프로세스가 통째로 디스크에 swap out된 상태 또는 사용자가 프로그램을 정지한 경우

=> 주로 ready-running에서 CPU가 쉐어링. **러닝에서 할당 시간 만료되면 타이머 인터럽트** 발생.

### PCB

- 운영체제가 각 프로세스를 관리하기위해 프로세스당 유지하는 정보.
- 프로세스 상태, PID, 우선순위, 스케줄링 정보, 코드/데이터/스택의 메모리 내 위치 정보 등

### Context Switch

- CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정. PCB에 프로세스 문맥 정보를 넣어 문맥을 저장해둔다.
- 시스템 콜이나 인터럽트 발생시 반드시 일어나진 않고 타이머 인터럽트나 IO 요청 시스템 콜이 일어난 이후 **다른 프로세스를 실행하러 갈 때** 문맥교환이 일어남.

### 프로세스 스케줄링 큐

![프로세스 스케줄링 큐](https://images.velog.io/images/hailey99/post/4a4d600e-049c-4237-a98c-e06279bb3edf/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202022-02-13%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%206.48.34.png)

- CPU 작업하다가 시간 지나면 다시 레디큐 가서 서야함
- fork a child(자식 프로세스 생성)하면 자식을 실행해두고 자기는 다시 레디큐에 선다

### 스케줄러

- 장기 스케줄러: 프로세스에 메모리를 주는 문제 결정. 메모리에 올라야 레디 큐에 올라갈 수 있음. 메모리에 프로그램이 너무 많아도 적어도 문제임. 너무 적으면 CPU가 놀 수도 있음. 얼마나 멀티 프로그래밍(degree of Multiprogramming)을 할지 정함
- 중기 스케줄러(=swapper): 메모리에 프로세스가 너무 많이 올라가 있으면 메모리를 뺏고 통째로 디스크로 쫓아냄

### 쓰레드

![쓰레드](https://images.velog.io/images/hailey99/post/31acbd63-e5e4-4c5a-9e19-15a56a219260/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202022-02-13%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%207.15.47.png)

- 프로세스 내부의 CPU 수행 단위. 각 쓰레드마다 현재 어떤 부분을 실행하고 있었는지 PCB 안에 각각 적어둔다.
- 프로세스에서 **코드 섹션, 데이터 섹션(메모리 주소공간), OS 자원 등은 공유**하고 CPU 수행 상태는 별도로 가진다. 이때 공유하는 부분은 task라고 한다. (= 1 process 1 task)

![쓰레드가 공통으로 가지는 것들](https://images.velog.io/images/hailey99/post/6a506304-622a-4237-9747-5ff86e48d266/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202022-02-13%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%207.30.00.png)

- **프로그램 카운터, 레지스터, 스택 공간을 별도로 가짐**

### 쓰레드를 사용하면 좋은 점

![나뉜 쓰레드](https://images.velog.io/images/hailey99/post/982ccff6-f5e6-42c0-b50f-552468b3c43a/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202022-02-13%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%207.17.27.png)

1. **응답성**: 1 process 안에 여러 쓰레드가 있으면 쓰레드 하나가 blocked여도 다른 스레드가 running이 가능.
(e.g.네트워크로 웹 페이지 읽어오는 동안(io 작업) 내 웹 브라우저는 blocked. 웹 브라우저를 여러 쓰레드로 불러오게하면 **한 쓰레드가 웹 읽어오는 동안 다른 쓰레드가 html 파일에서 읽어온 조금의 텍스트라도** 보여줄 수 있음.)
 - 비동기식 IO처럼
2. **자원 공유**: 한 프로세스에 있는 쓰레드간 자원을 공유함으로써 절약 가능
3. 경제성: 프로세스를 스위치할때보다 쓰레드를 스위칭할 때 오버헤드가 덜함
4. 멀티프로세서 구조의 효용성: 프로세서는 하나일때 쓰레드가 병렬로 일 가능 (e.g. 거대한 병렬 계산할 때 등)

### 커널 쓰레드와 사용자 쓰레드

- 커널 쓰레드: 쓰레드가 여러개라는 걸 os가 알고 있음. 커널의 지원 받을 수 있음
- 유저 쓰레드: 라이브러리를 통해 지원됨. 프로세스에 쓰레드가 여러개라는걸 os는 모름. 라이브러리 차원에서 관리함.

## 느낀점

이번 장을 통해 컴퓨터가 어떻게 한번에 많은 일을 하는가 알게 되었다. CPU 스케줄러에 종류가 있는지 몰랐는데 각각의 역할에 대해 알게 되었다.

## 되돌아보기 문제

1. PCB의 구성요소 3개를 말하시오.
2. 인터럽트가 발생할 때마다 문맥 교환이 일어난다 (O,X)?
3. 왜 현대의 시분할 시스템엔 보통 장기 스케줄러가 없을까?


프로세스와 쓰레드는 공유하는 자원이 다르고 문맥교환 시 정보를 PCB에 저장한다.

프로세스와 쓰레드란? PCB와 문맥 교환은 무슨 관계일까?


## 파이어베이스 연결할 때 에러

![암호화된 채 오는 데이터](https://images.velog.io/images/hailey99/post/de623ef7-2118-4909-8f86-ff9fcaec4ab6/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202022-02-11%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%208.30.46.png)

1. 위 사진은 아무 생각없이 구글만 보고 개발했을 때 응답으로 왔던 데이터. 
암호화되어있고 내가 원하는 데이터가 아니었다.
파이어베이스 V9를 썼는데 이전 버전에서 함수명도 바뀌고 사용법도 달라져서였다.
-> 아무생각없이 구글링하지말고 공식문서를 읽자. **해답은 모두 공식문서에 있었다.** 
아무래도 개발자가 적어둔 문서다보니, 명확했다.

![lite 안 쓰면 에러](https://images.velog.io/images/hailey99/post/ed9547a9-a46d-4d57-85d1-23b13782fbd9/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202022-02-11%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2010.34.27.png)

2. firestore import 할 때 "...firebase/lite" 에서 lite 안 쓰면 에러 뜸!!!

![FirebaseError](https://images.velog.io/images/hailey99/post/4320da84-fe75-4476-a7a0-34f88c31cf8a/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202022-02-11%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2010.34.52.png)

**FirebaseError: Expected first argument to collection() to be a CollectionReference, a DocumentReference of FirebaseFirestore**

3. 이 에러 진짜ㅜㅜ 내 속을 제일 뒤집어놨던 놈. 
파이어스토어에서 주는 데이터 그대로 리액트에 못 쓴다. 
`{data.name}` 이런식으로 렌더링할때 넣어주려고 했는데 객체는 안되고 배열로 바꿔서 넣어줘야한다고함.

### 3번 에러 해결법

1. 다른 변수 선언해서 거기다 넣어서 쓴다
2. **(완전 중요)** timestamp 형식의 시간,날짜 데이터 가져올 경우 객체타입이라 변환해서 가져와야한다.

## Vuepress 깃허브에 배포하니 사이드 바만 안보이는 현상

![로컬](/images/blog/2202/local.png)
![배포 후](/images/blog/2202/deploy.png)

`vuepress`로 TIL을 만드는데 로컬에서는 보이는 사이드바가 배포 후에는 안 보이는 경우가 있었다. 
`config.js`에서 디렉토리와 파일 이름으로 사이드바를 직접 만드는데 디렉토리에 파일이 없는게 아니라,
 **사이드바 자체가 아예 안보였다**.

알고 보니 배포 전용 브랜치인 `gh-pages`를 빌드된 디렉토리(dist)랑 연결해야했는데, 
실제 개발 디렉토리랑 연결해서 그런거였다.

github pages 문서 읽어보니까 `gh-pages`를 쓰는 건 예전 방법이래서 
난 docs 구조를 쓰고 있으니까 main 브랜치랑 연결하면 되는건가 했는데 아니었다.

## 깃허브 페이지 도메인 이름 잘못 지은 것

깃허브 페이지 만들 때 깃허브 아이디.github.io로 하면 저절로 깃허브 페이지가 만들어진다.  
근데 나는 왜??!!!?!??! github.io 뒤에 레포 이름이 붙나했더니..

![깃허브 페이지 배포](/images/blog/2202/gh1.png)

예전에 깃허브 페이지를 만든 적이 있어서 그런건가 했음

![repo 삭제](/images/blog/2202/gh2.png)

근데 repo delete 삭제하다가 봄... hailey 를 haliey로 썼었다.............................ㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎ
바보바보바보

repo 다시 만들었더니 정상적으로 작동했고, hailey99.github.io라는 도메인은 좀 긴 것 같아서 mango.dev 로 바꾸고 DNS 등록 되길 기다리는 중이다!!


리액트에 파이어베이스 연동하기, gh-pages 배포하기

블로그 만들면서 헷갈렸던, 만났던 에러 모아보기


JS 런타임은 코드가 실행될 때 자신이 무엇을 해야할지 결정하기 위해 값의 타입, 즉 해당 값이 어떤 동작과 능력을 가지고 있는지 확인한다.
`string`이나 `number`와 같은 원시형 데이터는 `typeof` 연산자를 써서 각 값의 타입을 실행전에 알 수 있으나, 함수가 인자로 오는 경우엔 코드 실행 전에 타입을 예측할 수 없다.
즉, 자바스크립트는 **동적 타입**만 제공한다. 그래서 순수 자바스크립트에선 `argument`가 2개 필요한 함수의 파라미터로 1개만 넣어도 실행 전까지는 오류가 나지 않는다.
그렇게 많은 `runtime error`를 마주치게 되고, 이에 대한 대안으로 등장한 것이 **정적 타입 시스템을 사용해 코드 실행 전에 코드를 예측하는 것**이다.
코드 실행 전에 에러를 잡고 우리가 사용할 수 있는 프로퍼티를 제안하고자 TS가 등장하게 되었다.
 
## Strongly-typed

타입스크립트를 설치하면 타입스크립트의 컴파일러인 `tsc`도 함께 설치된다. 타입스크립트 코드를 작성하면 자바스크립트 코드로 컴파일하는데, 이때 타입 에러가 있으면 아예 자바스크립트로 컴파일되지 않는다.
`tsc --target` 명령어로 타입스크립트 코드를 어떤 ECMAScript 버전으로 변환할지 지정할 수 있다.

타입스크립트 설정으로 `noImplicitAny`, 타입이 암묵적으로 `any`로 추론되는 변수(묵시적 타입)에 대해 오류를 발생시키게 하거나
`strictNullChecks`로 `null`이나 `undefined`를 명시적으로 처리하도록 제한할 수도 있다.

타입을 `any`로 지정하면 TS의 모든 보호장치가 해제된다고 보면 되고 `readonly`로 지정하면 말 그대로 데이터 읽기만 가능해진다. (이 때 readonly 여부를 JS로 변환하진 않는다.)
타입을 `unknown`으로 설정하면 어떤 작업 전 이 변수의 타입을 먼저 체크하도록 하도록 강제한다. 변수의 타입을 미리 알지 못할 때 사용한다.

```typescript
const player: readonly [string, number, boolean] = ['hail', 1, true];
player[0] = 'hi' // TSError: readonly입니다.

let a: unknown;
let b = a+1; // TSError: 타입 명시되지 않음

if (typeof a==='number') {
	let b= a+1;   // 이 구역에서는 a의 타입이 number
}
```

그래서 위 코드에서는 readonly 데이터인 `player[0]`에 값을 지정하려고 해 타입스크립트 에러가 발생한다.

## 사용법

`type alias`로 아래처럼 타입에 이름을 지정해주자.

```typescript
type Age = number;
type Player = {
	age?: Age
}
```

`Call Signature`로 함수 인자와 리턴값의 타입을 알려주자.

```typescript 
type Add = (a: number, b: number) => number;
const add: Add = (a,b) => a+b
```

`void`는 함수가 아무것도 리턴하지 않을 때,
`never`는 함수가 절대 리턴하지 않을 때, 즉 `exception`이 발생할 때나 절대 실행될 일이 없을 때의 타입이다.

```typescript
function hello(): never {
	return 'x'  // TSError: 이 함수는 리턴값이 없어야 한다.
}

function hello(): never {
	throw new Error('x') // O
}

function hello(name: string| number) {
	if (typeof name==='string') {
	} else if (typeof name ==='number') {
	} else {
		name // 절대 실행될 일 없다
	}
}
```

오버로딩을 해 함수가 서로다른 여러개의 콜 시그니처를 가지게 할 수도 있다.

```typescript
type Push = {
(path: string): void
    (config: Config): void
}

const push:  Push = (config) => {
    if(typeof config === 'string') {
        console.log(config)
    } else {
        console.log(config.path)
    }
}
```

### Type narrowing

```typescript
function foo(x: string | number) {
  if (typeof x === 'string') {
    // 이 부분에서 x의 타입은 string일 수밖에 없다. (narrowed type)
    x = 1; // 그러나 이런식으로 할당을 하면 선언한 타입이 된다.
  }
  
  // 또는
  if (Array.isArray(x)) {
      // 
  }
}
```

이렇게 제어 흐름에 따라 타입이 좁혀지는 것을 `type narrowing`이라고 한다. Type narrowing을 해서 **코드 구조를 바탕으로 TS가 더 구체적인 타입 추론을 할 수 있게** 해야한다.

## 다형성 적용하기

Generic
```typescript
type SuperPrint = {
	<TypePlaceholder>(arr: TypePlaceholder[]): void
}

type SuperPrint = <T>(a: T[]) => T;

// a
const superPrint: SuperPrint = (a) => a[0]

// b
function superPrint<V>(a: V[]) {
    return a[0]
}
```

위 코드의 a와 b 코드는 생김새만 다를 뿐 동일하다.  
`<>` 기호로 확정된 타입 대산 `placeholder`를 지정할 수 있다. 이렇게 제너릭을 쓰면 타입스크립트가 `placeholder`로 타입을 알아내 그 자리를 대체해준다.
코드를 자바스크립트로 변환할 때 타입스크립트가 placeholder 자리의 타입을 적절한 타입으로 변환한다.

```typescript
type Player<E> = {
    name: string
    extraInfo: E
}

const nico: Player<{age: number}> = {
    name: 'nico',
    extraInfo: {
        age: 29
    }
}
```

위 코드처럼 사용할 수도 있다.

### 다형성 타입 집합을 정의할 때는 Union 활용

```typescript
// as-is
type Animal = {
  kind: 'bird' | 'fish';
  isSwimming?: boolean;
  isFlying?: boolean;
}

// to-be
type Bird = {kind: 'bird', isSwimming: boolean};
type Fish = {kind: 'fish', isFlying: boolean};
type Animal = Bird | Fish;
```

위 예시의 `Animal`은 `kind`가 `bird`인 데이터를 위한 `isSwimming`과 `fish` 데이터를 위한 `isFlying` 속성을 함께 가진다.
이런 경우엔 `Bird` 타입과 `Fish` 타입으로 분리하고 `Union`을 사용해 `Animal` 타입으로 묶어주는 게 낫다. 이 때 Union 타입의 조합에 사용된 각 타입(`bird`, `fish`)을 '멤버'라고 한다.

여기서 더 개선하고 싶다면, 아래대로 `isBird`와 `isFish` 함수가 타입명제를 반환하도록 변경하고 `filter`를 사용하면 된다. 

```typescript
function isBird(animal: Animal): animal is Bird {
  return animal.kind === 'bird';
}

function isFish(animal: Animal): animal is Fish {
  return animal.kind === 'Fish';
}

const birds = animals.filter(isBird);
```

## interface

타입스크립트의 `interface`는 객체지향 프로그래밍의 개념을 활용해 디자인되었다.
자바스크립트에서 추상클래스는 상속받는 클래스의 청사진이다. 상속받는 클래스가 가져야할 프로퍼티, 메서드를 알려준다. (상속받는 클래스에게 *어떻게 구현할지* 말고 *뭘 구현해야할지*를 알려준다.)
추상클래스는 인스턴스를 만드는 걸 허용하지 않는다. 아래 코드에서 `extends User`는 할 수 있으나 `new User()`는 할 수 없다.

타입스크립트에서 추상클래스를 만들면 JS로 변환시 그냥 일반 클래스로 변환한다. 그렇기에 추상클래스 대신 인터페이스를 쓰면 좋다.
더욱이, `interface`는 컴파일하면 자바스크립트로 바뀌지 않고 사라지므로 가볍다!

```typescript
// js. 추상클래스
abstract class User { 
	constructor(
		protected firstName: string,
		protected lastName: string
	){}
	
	abstract sayHi(name: string): string;
	abstract getFullName(): string;
}

class Player extends User {
	getFullName() {
		return `${this.lastName}${this.firstName}`
	}
	sayHi(name: string) {
		return `Hello ${name}, I'm ${this.firstName}`
	}
}

// ts. interface를 사용하자
interface User {
	firstName: string
	lastName: string
	sayHi(name: string): string
	getFullName(): string
}
```

객체의 모양을 선언하는 목적으로 쓰는데, `type`은 정해진 문자열 값이라던가 특정한 값을 타입으로 제한 가능하지만
`interface`는 `type`만 타입으로 정해줄 수 있다. 

`type`은 새 프로퍼티를 추가하도록 개방될 수 없지만 `interface`는 타입을 상속 받아 프로퍼티를 확장할 수 있다. 아래 코드를 보자.
다만 `interface`를 상속할때에는 프로퍼티를 `private`으로 만들 수 없다.

```typescript
type User = { 
	name: string	
}

type Player = User & {
    // a
}

// User를 interface로 하면
interface Player extends User {
    // b
} 
```





타입스크립트 개념, 활용법, 타입 내로잉, 다형성, 인터페이스

내가 보려고 정리하는 타입스크립트


## 컴퓨터 시스템 구조

<img src='https://user-images.githubusercontent.com/50111853/152885901-d04bf6f3-fdf2-483c-8bcb-1621ce59cc35.png' width='400px' alt='컴퓨터시스템구조' />

컴퓨터 시스템 구조: 컴퓨터+ IO device  
컴퓨터: CPU+memory

### CPU: 일만 함

- 역할: 메모리에서 명령어를 읽어서 실행한다.
- disk보다 훨배 빠르다.
- memory에서 instruction 읽어서 실행 (ONLY memory에만 접근. io device에 접근X)
  - `scanf` 해야된다던가 io device 작업이 필요할땐 cpu가 명령어로 io컨트롤러한테 일을 시키고, 본인은 다른 명령어를 실행함 
  (`입력값 버퍼에 들어오면 나한테 연락때려라~`하고 자기 할일을 한다. 굉장히 빠른데 일만 한다. 쉬지 않음)

#### CPU의 구성요소
1. **register** : 메모리보다 빠른 정보 저장 공간
2. **mode bit** : 실행 중인게 os인지 유저프로그램인지 구분.
3. **interrupt line** : cpu는 명령어 실행이 끝나면 메모리 주소값을 증가시켜서 다음 명령어 실행하는 것을 반복한다.
그 사이에 cpu가 다른 일 처리해야 하는 게 있다는 걸 알려주는 역할을 한다.

### OS: CPU를 전체적으로 통제하는 역할

- OS는 대부분 사용자 프로그램이 쓴다.

**이때 만약 io 작업없이 CPU 무한루프 도는 프로그램이 있다면? 그 프로그램이 cpu 독점하게 될 수도 있다**  
**이걸 막기 위해 존재하는 하드웨어가 '타이머'이다.**

### 타이머: CPU 독점을 막는 하드웨어

- 컴퓨터를 켜면 os가 cpu를 가지고 있다가 **타이머 값을 세팅한 후** 사용자 프로그램한테 넘겨준다. 
프로그램은 그 시간 동안만 cpu를 사용할 수 있다.
- 만약 할당된 시간 끝나면 CPU한테 타이머가 인터럽트 보내고, cpu 사용권이 사용자프로그램에서 os로 넘어간다. 
(사용자프로그램도 io device 접근 불가. os를 통해서만 접근 가능)

### Interrupt

- 입출력장치 버퍼에 인풋 들어옴 -> io controller가 "버퍼에 입력 들어왔다"하고 CPU한테 io interrupt 보냄 -> 
CPU 제어권이 OS로 넘어감 -> os가 io buffe의 데이터를 본인 메모리에 카피
- **시스템 콜**: 사용자 프로그램이 운영체제의 서비스를 받고자 운영체제(커널)을 호출하는 것. 소프트웨어 인터럽트의 일종이다.
  - 방식: 사용자 프로그램이 '일 다했다~'하고 인터럽트 라인을 세팅하면 (= 인터럽트를 걸면) CPU 제어권이 OS에게 넘어간다.
- 소프트웨어 인터럽트(트랩) : Exception, System Call
- 하드웨어 인터럽트(대부분의 인터럽트): 타이머 인터럽트, io controller 인터럽트 등
  - 예시: '할 일 다했다~' (타이머 인터럽트)

<img src='https://user-images.githubusercontent.com/50111853/152990728-1932dd77-8606-4532-8dc0-0c89ced96bf4.png'/>

### mode bit: 사용자가 cpu 악용하는 것을 막는 역할

- `0` (모니터 모드, 커널모드): os 코드 수행중. 메모리접근, io 접근 등 다 가능
- `1` (사용자 프로그램 모드) : 모든 명령은 커널모드에서만 사용가능하므로 사용자 프로그램은 '시스템 콜'로 os에게 IO 요청함. 
바로 os에 접근할 수 없으므로 인터럽트를 일으켜 cpu의 제어권을 Os로 보낸다.

**만약 io device에서 계속 CPU한테 인터럽트를 걸어서 메모리에 있는 데이터 보낸다면?**  
**cpu가 인터럽트를 너무 많이 당함 -> 비효율적. 그래서 있는게 DMA Controller**

### DMA Controller

: **Direct Memory Access Controller**

- Memory에 CPU, DMA Ctrl 둘다 접근 가능.
- CPU 대신 DMA가 io device에게 직접 가서 로컬 버퍼의 데이터를 메모리에 복사해주고 CPU는 최종 인터럽트만 받도록 함
- DMACtrl 덕분에 CPU는 instruction 메모리 주소를 메모리에서 PC(Program Counter) 형태로 받아와서 실행하는데 집중 가능
- DMA가 버퍼에 있는 내용을 메모리로 카피, 모아서 block 단위로 직접 메모리로 전송 & CPU에게 인터럽트

### Memory Controller: 교통정리

- DMA 컨트롤러와 CPU가 동시에 특정 메모리에 접근하는 것 막는 역할

#### Device Driver

- 소프트웨어. os 코드중 각 장치에 접근하는 처리루틴

### Device Controller

- 하드웨어. io device의 CPU 역할
- local buffer 있음

### Program Counter: 프로그램 카운터 라는 레지스터

CPU는 메모리 주소를 가리키는 레지스터(프로그램카운터레지스터)가 가리키는 메모리 위치에서 인스트럭션을 읽어와실행함
그다음 프로그램카운터레지스터는 다음 주소를 가리킨다.
인스트럭션 하나가 주로 4바이트. 다음 인스트럭션 주소는 pc가 4 증가.
왠만하면 순차적으로 실행. 함수/if문 쓰루하는 경우 등 다른 메모리주소로 점프해야할 땐 메모리 위치가 점프

- 명령 끝나고 새로 시작할때마다 인터럽트 라인 확인.
- 인터럽트 벡터: 해당 인터럽트를 처리할 수 있는 처리 루틴(커널 함수) 주소를 가짐

<img src='https://user-images.githubusercontent.com/50111853/152990537-dae6e3fd-93db-4751-b112-a586702e6f93.png' width='600px' />

## 입출력 비교

- 동기식 입출력: io 요청 후 입출력이 끝나길 기다린 후 제어가 사용자 프로그램으로 넘어감
- 비동기식 입출력: io 작업 끝나는거 안 기다리고 제어가 사용자 프로그램으로 넘어감
  - e.g. 디스크에서 뭐읽어오는 작업할 경우 그 데이터를 몰라도 할 수 있는 작업을 한다. (주로 '쓰기'작업)

동기비동기 io 둘다 입출력작업 끝난건 인터럽트로 알려줌.

### IO 방법

- 일반적으로는 메모리, IO device에 접근하는 명령 따로따로
- memory mapped io: io 장치도 메모리 주소에 연장 주소 붙임

## 저장장치의 계층 구조

<img src='https://user-images.githubusercontent.com/50111853/152996435-6a71f464-cc76-4a42-9e74-febbe7e0b34f.png' width='500px' />

CPU-register-cache memory-main memory(d ram)-...

- 위로 갈수록 속도가 빠르고 비싸 용량이 적고, 대부분 휘발성이다.
- secondary: cpu가 직접 접근 불가. cpu는 바이트 단위로 접근하는데 세컨더리는 바이트 단위로 불가해 unexecutable
- 캐싱은 재사용을 목적으로함. 미리 위까지 읽어놓으면 아래에서 읽어올 필요없음.

## 프로그램의 실행

<img src='https://user-images.githubusercontent.com/50111853/152998172-78c42928-fb16-4c96-8120-e2740d736b35.png' width='450px'/>

- 주로 `.exe`
- 프로그램을 실행시키면 그 실행파일의 독자적인 주소 공간(`virtual memory`)이 생긴다. 이 공간은 프로그램 종료시 사라짐.
- 주소공간(Address space): 코드, 데이터, 스택으로 이루어짐 (0번지부터 시작)
- 이 주소공간을 **물리적인 메모리**에 올려 실행. 근데 주소공간의 전부를 다 올리지 않고 당장 필요한 코드 부분만 물리적인 메모리에 올림
- 어느 부분은 physical memory에 일부는 swap area에 나눠져있기도 함. (virtual memory 기법)
- swap area: 전원이 꺼지면 다 지워진다. 메모리 연장 공간으로 사용됨.

### 커널 주소공간의 내용

<img src='https://user-images.githubusercontent.com/50111853/152998323-c2a47006-f31c-4006-ad9e-93c00e7f101a.png' width='450px' />

커널 주소공간 = 버츄얼 메모리

- 커널도 하나의 프로그램이므로 주소공간으로 구성돼있음.
- os는 자원을 효율적으로 관리하는 역할 하므로 관련 된 코드가 code 안에 있음
- os는 인터럽트가 들어오면 cpu를 가지므로 인터럽트, 시스템콜 처리 코드가 code 안에
- os는 cpu, memory, disk 등 하드웨어를 관리한다. 이때 관리를 위한 자료구조가 필요하다.
- os는 프로세스를 관리. 프로세스 관리 위한 자료구조: PCB(Process Control Block) (프로세스마다 PCB가 하나씩 만들어짐)
- 운영체제의 코드는 사용자 프로그램이 막 불러 실행하기 때문에 어떤 사용자 프로그램이 커널에 시스템콜을 하는지 저장하는 커널 스택도 있다.

## 함수

- 사용자 정의 함수: 내가 만들고 내가 불러서 쓰는 함수
- 라이브러리 함수: 누군가 만들어놓은 함수로, 내 실행 파일 안에 포함되어 있다. **사용자 프로세스의 주소 공간**에 있음
- 커널 함수: os 안에서 정의된 함수. 시스템 콜을 해서 쓸 수 있음. **커널의 주소공간** 안에 들어있음.
- 사용자 정의함수나 라이브러리함수에서 커널 함수를 호출하는 것은 메모리 주소가 점프해야하므로 불가능하다. 
커널 함수를 호출할 땐 시스템 콜로 cpu 제어권을 os로 보내 실행함.

## 느낀 점

1. 처음엔 내용이 정말 방대하구나 싶었다. 선구자들이 오랜 시간동안 연구하고 만들어온 거니 사실 당연한 거다. 
강의를 들으면서 계속 새로운 장치와 개념이 나왔는데, 이것들이 다 연관되어있다는게 참 신기했다. 
컴퓨터덕에 우리가 누리는 편리함과 즐거움을 생각하면 당연한 거지!!! 더이상 미룰수 없다 나의 운영체제 공부!!!  
2. 목표는 꾸준히, 그리고 반복해서 보기
3. 컴퓨터를 더 잘 알고 더 나은 개발자가 되자.
4. 시스템 콜이라는 개념이 흥미롭다. 나 다했어~~~하고 알림이 아니라 인터럽트를 걸어버리는 놈


운영체제와 컴퓨터 하드웨어의 동작에 대해 배운다.

시스템 구조와 프로그램의 실행 (feat. CPU, 인터럽트, 커널모드란?)


[테헤란벨리 / 백엔드 vs 프론트엔드 비교 영상](https://youtu.be/S9qAtvvvxio)을 보았다.  
등장인물들의 개인적 의견이지만 어떤 분야를 팔지 고민하고 있는 나같은 사람을 위해 정리해서 올려본다.

## 프론트

- 코드의 유효 기한이 짧음 (n개월인 경우도 있음)
- 코드의 유효기간이 짧다 보니 추후에 유지보수가 쉽도록 하는게 별로 도움 되지 않음 
- 백엔드에 비해 '성능을 좋게 할 방법'을 고민하는데 쓰이는 시간의 중요성이 낮음. 그래도 이 고민을 통해 나온 결과물은 써보면 티가 난다(e.g. 토스의 웹뷰)
- 기획, 디자인 등의 이유로 바뀌는게 엄청 많음
- 백엔드나 다른 분야에 비해 변화가 극심하게 빠르다 (**학습에 즐거움을 느끼고 변화에 스트레스 안 받는 타입**이 좋음)
- 채용 수요가 가장 많다. 이에 비해 팀장급 이상 개발자가 적다.
- Bleeding Egde: 최첨단
- 역사가 없어 뭐가 더 나은지에 대해 이야기할 때 진영이 나뉘므로 **다양한 의견을 듣고 시도해보길 즐기는 사람**이 프론트엔드 개발을 하는게 좋다.

### 프론트엔드 개발자는 화면에 보이는 모든 것을 만든다. (정재남 님)

- html, css, js를 이용해 마크업 화면에서 이루어지는 애니메이션과 인터랙션 구현
- UI 성능 최적화
- 서버에 데이터 요청하고 응답을 받아서 화면에 뿌려주기 (XMLHttpRequest, 웹소캣, 쿠키, 로컬스토리지, 세션스토리지)

보통 문제가 생기면 디자이너나 기획자가 제일 먼저 찾는 사람이 **프론트엔드**. 
프론트엔드가 원인을 파악하고 백엔드로 넘겨주는 경우가 많음. => **커뮤니케이션 스킬**이 중요!

### 프론트엔드 개발자 전망

- SPA 시대가 되면서 템플릿 언어까지 프론트엔드가 맡는 경우가 많아짐.
- GraphQL 등 데이터를 직접 가공하는 일까지 넘어오는 추세
- 데이터 캐싱, 라우터 관리 등 업무 영역이 넓어지고 있음

## 백엔드 

- 백엔드 개발에서는 기술적 성능을 높이면 돈으로 직결된다. (프론트에서는 성능이 좋아져도 차이가 미묘한 경우가 많음)
- 추상적 사고력 중요 (완전 추상화된 세계)
- 설계를 지루해하지않고 트래픽이 늘었을 때를 상상해 설계할 줄 알아야함
- 백엔드 기술의 발전, 역사를 알고 기술이 어떻게 전 기술을 보완하며 발전했는지 파악하면 이해가 쉬움

## 나의 결론

위 영상에 나온 바로는 나는 앞구르기뒷구르기 프론트엔드 개발자...   
내가 변화, 새로운 것을 좋아한다고 해도 너무 빠르게 발전하니까 좀 압도당할 때가 있었는데   
여전히 더 고민해봐야할듯...ㅎ

유튜버 테헤란밸리와 정재남 님의 글을 요약 정리해봤다.

백엔드 vs. 프론트엔드. 개발자 적성 찾는 법과 신입 프론트엔드 개발자가 해야할 일



### 1분기(1~3월)

![2021년 1분기 회사앞에서 썰매](/images/blog/2201/1.jpeg)

- 작년 12월 중순에 입사했기 때문에, 완전 초초초신입 
- 프로젝트 세개를 연달아 했는데 자바 인공지능 프레임워크 부터 php, js 등등 다양하게 써볼 수 있어서 재미있었다. 
- 사내 리액트 스터디 시작. 처음엔 리액트가 지이이인짜 어렵게 느껴졌다. 책 '리액트를 다루는 기술'을 주제로 다른 팀원들과 서로 가르쳐주면서 했더니 즐거운 시간이었다!!!
- 일을 하면 할 수록 컴퓨터 공학적인 개념을 잘 알고 있을 필요를 느꼈다. 컴퓨터공학과 전공과목 강의를 개인적으로 듣기 시작했다.

### 2분기(4~6월)

![국정자원 출입증](/images/blog/2201/3.jpeg)

- 스터디 관련해 정부 지원금을 받았는데, 스터디장으로서 그 지출을 관리하고 증빙 서류를 준비하는 것들이 복잡하게 느껴졌고, 그 돈을 어떻게 하면 현명하게 사용할 수 있을까 고민을 많이 했다.
- 국가 기관에 들어와 네트워크 시각화 프로젝트에 참여하기 시작했다. 인터넷이 안 되는 환경에서 작업을 하는게 얼마나 불편한지 처음 알게 되었고... 밖에서 핫스팟으로 노트북 작업을 하느라 휴대폰 요금이 과하게 나오기도 했다. 
- 프로젝트에서 처음 맡은 업무는 웹 구현이었지만 네트워크 공부 또한 시작했다. 얼마나 이해했는지 확인하고자 하반기에 네트워크관리사 시험을 보기로 결심했다.
- 패스트 캠퍼스 강의를 들으며 node.js, typescript, React를 본격적으로 써보기 시작했다.

### 3분기(7~9월)

![스타벅스에서 노트북](/images/blog/2201/6.jpeg)

- 파이썬에 흥미를 느껴 장고를 써보고 싶어졌다. MDN의 도서관 사이트 튜토리얼을 따라해보면서 공부를 시작했는데, 두번 반복해보니까 장고로 만든 웹의 동작 구조가 잘 이해돼서 넘 좋았다!!! 
https://developer.mozilla.org/ko/docs/Learn/Server-side/Django/Tutorial_local_library_website
- 회사 프로젝트에서 네트워크 호스트별로 모델링 시작. 사무관님이 정의해둔 문서를 보며 모델링했는데 개념이 아주 자세하게 쪼개져있어서 이해하기 쉽지 않았다. 물리적으로는 하나지만 추상적으로 분리되어야하는 모델이 많아 차장님께 여러번 여쭤보며 모델링을 했다.

### 4분기(10~12월)

![클라이밍 벽](/images/blog/2201/7.jpeg)

- 모델링을 하고 그 모델대로 neo4j에 노드, 엣지를 생성하는 파이썬 코드도 구현했다. 모델에 어떤 자료구조를 쓰면 좋을까 고민을 많이 했다(딕셔너리->클래스->데이터클래스 etc). 처음부터 제대로 설계를 했으면 좋았을 걸...하고 생각했다. 이럴때 삽질해보면 좋지!!하는 생각이지만 다음번에는 삽질을 무조건 덜하자! 
- 해당 코드를 도커에 올리고 서버에서 구동시키는 과정에서 리눅스 명령어와 좀 더 친해졌다.
- '대롱대롱'이라는 이름의 대전의 주옥같은 가게를 리스트업하는 웹 앱을 개발했다. 지금은 멈춘 상태지만,,, 피그마로 디자인을 하고 리액트, 장고를 사용해 구현했다.



썰매 타고 새 프로젝트 들어가고 클라이밍까지

SI 업계 1년차 개발자의 2021년 회고


## Svelte

- 실행 시점(런타임)이 아니라 빌드 시에 앱을 바닐라 JS로 컴파일해주는 웹 컴파일러다. (리액트는 JS 라이브러리고, 스벨트는 컴파일러다. 웹 프레임워크라고도 하는데 흠 뭐지...! 글마다 말이 다르다 😂)

### 스벨트의 장점

- 효과1: 런타임이 아니라 빌드할 때 컴파일하기 때문에 앱 처음 불러올 때 지연이 적고 
- 효과2: 따로 라이브러리를 배포할 필요가 없다.
- 효과3: 가상 DOM, 진짜 DOM을 비교하는 리액트와 달리 진짜 DOM만 사용함.

## 스벨트 튜토리얼 따라해보기

[스벨트 공식문서](https://svelte.dev)에는 직접 코드를 쳐볼 수 있는 튜토리얼도 있다.

![스벨트에서 컴포넌트 추가하기](/images/blog/2201/sv1.png)

스벨트에서는 리액트처럼 컴포넌트를 import해서 보여줄 수 있다.

![html 문자열 html 안에 넣기](/images/blog/2201/sv2.png)

html 형태의 문자열을 스크립트에서 지정해 넣으면 그 html 태그가 반영된다. 

![reactive declarations](/images/blog/2201/sv3.png)

진짜 신기한 것!!! reactive declaration(반응형 선언?)이라는 건데, 이 **변수를 여러번 참조해아할 때나 이 변수가 다른 반응형 값에 의존적일 때 사용하면 좋다.**  
즉, 서로 연관된 변수에 쓰면 좋다.

## (추가적으로 찾아본) Astro : 정적 사이트 빌더

- 빌드 시에 사이트를 다 정적 HTML로 렌더링함. 최종적으로 JS는 다 지워진 정적 사이트가 됨.
- React, Vue 등에서 js를 걷어내니까 결과적으로 빨라짐.
- **신기하다.** 웹 프레임워크 만들어놓으니까 그걸 걷어내는 게 또 나왔다. ㅋㅋㅋ


리액트보다 훨 간결한 코드를 짤 수 있는 스벨트(Svelte)! 알아보자.


리액트나 Node.js를 쓸때 `yarn`을 설치하고 시작하는 튜토리얼들이 많았다.  
그래서 자연스럽게 yarn을 썼었는데 문득 yarn이 npm이랑 똑같은 역할을 같아 둘의 차이가 궁금해졌다.  
`package-lock.json`이랑 `yarn.lock` 둘다 있는게 번거롭기도 했고..
요즘엔 npm만 쓰는데 많은 사람들이 yarn을 쓰는 이유가 있을 테니까! 싶어서 둘의 차이점을 찾아봤다.

## npm과 yarn의 공통점

1. 둘 다 Node.js package manager다.
2. 둘 다 **package.json에 저장된 프로젝트 메타데이터를 사용**한다.

## Yarn

- npm을 보완하기 위해 페이스북에서 개발한 Node.js 패키지 매니저다.

### Yarn의 장점

1. 속도가 빠르다  
npm은 패키지를 설치할때 순서대로 하나씩 설치하는 반면, yarn은 동시에 (병렬로) 여러 패키지를 설치한다.

2. plug n play  
yarn은 node_modules 폴더 대신 `_pnp.cjs` 파일에 **최적화된 디펜던시 맵**을 만들어둔다.
그래서 빠르게 프로젝트를 구동하거나 install할 수 있다. ->
그걸 바탕으로 인스톨하기때문에 오프라인일때도 딜레이가 매우 적다!

3. 보안이 더 잘 되어있다.  
npm은 dependency(의존성)이 있는 모든 패키지를 바로 설치하는 반면,
yarn은 **`yarn.lock`이나 `package.json`에 있는 파일만** 설치한다.
(npm, yarn 둘다 시큐리티 체크는 한다.)

npm vs. yarn 비교해보기


## 리덕스란

리덕스는 **상태를 관리해주는 리액트 전역 상태관리 라이브러리**다. 지금은 Redux toolkit으로 표준화됐다.  
상태를 연쇄적으로 변화시키며, 리액트하고 사용할땐 react-redux를 깔아서 함께 쓴다.  
컴포넌트의 상태 변경 로직을 다른 파일로 분리해 효율적으로 관리할 수 있다.

**상태관리가 왜 필요할까?**  
리액트의 경우 컴포넌트에서 원래는 useState 등을 사용했는데, 각 컴포넌트가 아니라 **앱 전체에서 상태를 관리해야하는 경우**가 많다.

그럴 때 **앱 전역에서 사용되는 상태를 관리**하는게 리덕스!

```js
// 만약 todolist를 만드는데 투두와 완료, 삭제리스트를 이렇게 관리하면 한 js에서 관리할 게 너무나 많음
const state = {
      todolist:[],
      donelist:[]
}
```

그럴 때 리덕스를 사용하면 **상태를 앱 최상위에서 관리하기 때문에 그 하위 컴포넌트 어디서든 상태값을 가져와** 사용할 수 있다.

## 작동 순서

![리덕스 작동순서](https://images.velog.io/images/hailey99/post/1c7d4cad-f918-429c-b039-d65573c0a4af/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202022-02-11%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%204.41.49.png)

리덕스는 사용자 Action이 발생했을때, Store로 가기까지 무조건 한 방향으로 움직인다.

1. dispatch 함수를 실행하면
2. action이 발생한다.
3. 이를 리듀서(reducer)가 전달하면
4. 최종적으로 상태(state)를 바꾼다.

### 구성 요소

- Action: 무조건 타입을 전달한다
```javascript
{type:'some text'}
```

- Reducer: param으로 상태와 액션을 받고 상태를 변화시키는 함수

```javascript
function reducer(state, action) {
    return changeState;
```

- Store: 앱 전체에서 사용되는 상태 저장소
- Dispatch: 액션을 발생시키는 함수 (`e.g. dispatch(action)`)

참고: Fastcampus '한 번에 끝내는 Node.js 웹 프로그래밍 초격차 패키지 Online' 강의

## 장단점

**장점**

1. 데이터 관리하는 부분이 분리되어있어 테스트가 쉬움
2. 모든 구성요소는 Store의 모든 양식 상태에 액세스 가능

**단점**

1. Action type, selector, action 생성자, reducer 등 중복 코드가 많음
