tree shaking

트리 쉐이킹

patterns.dev

# Tree Shaking (트리 쉐이킹)

## Reduce the bundle size by eliminating dead code (데드 코드를 제거하여 번들사이즈를 줄이기)

> 이 글의 원글은 https://www.patterns.dev/posts/tree-shaking/ 이며, 번역 글입니다

가끔 우리는 어디에도 우리 앱에서 쓰이지 않는 코드를 작성하기도 한다. 죽은 코드 조각들은 번들 사이즈를 줄이기와 불필요하게 더 많은 데이터를 적재하는 것을 막기 위해서 제거될 수 있다! 우리의 번들에 넣기 전에 데드 코드를 제거하는 프로세스를 tree-shaking (트리 쉐이킹)이라고 한다.

트리 쉐이킹은 `math`와 같은 간단한 모듈들에서 동작하기도 하지만, 트리 쉐이킹이 꽤나 까다로운 케이스들도 있다.

### Concepts

트리 쉐이킹은 최종 자바스크립트 번들에서 쓰이지 않는 코드를 제거하는데 목적을 갖고 있다. 올바르게 작업이 된다면, 자바 스크립트 번들의 사이즈를 줄일 수 있고, 더 가볍게 다운로드 할수 있으며 파싱과 실행 시간을 줄일 수 있다. 모듈 번들러 (웹팩이나 롤업과 같은)를 사용하는 모던 자바스크립트 앱들을 위해서, 번들러들은 자동으로 당신의 예상대로 죽은 코드를 없앤다.

당신의 어플리케이션과 그것의 추상적인 신택스 트리 디펜던시들을 고려해 보라. (우리는 그 신택스 트리를 최적화 하기위해서 "shake" 하고 싶다.) 트리 내부의 각각의 노드는 당신의 앱을 기능하게 하는 디펜던시들 이다. 트리쉐이킹에서, input file들은 그래프로 취급된다. 각 그래프의 각각의 노드는 코드의 "part"라고 불리는 최상위 레벨의 상태이다. 트리쉐이킹은 순환하는 그래프이다. 엔트리포인트 부터 시작하여 포함하는 어떤 것들을 경로에 따라 모두 순회한다.

모든 컴포넌트는 심볼, 심볼 레퍼런스를 선언할수 있고 다른 파일들에 의존적이다. "parts"가 사이드이펙트를 가지고 있다고 표시되어 있든 아니든간에 말이다. 예를 들면, `let firstName = 'Jane'`이라는 선언은 사이드이펙트가 없다. 왜냐면 저 선언은 만약 어떤데에서도 firstName을 쓰지 않는다면 제거될수 있기 때문이다. `let firstName = getName()`이라는 선언은 사이드이펙트를 가지고 있다. 왜냐하면 `getName()`이라는 함수는 지워질수 없기때문이다. 만약 아무도 firstName이라는 변수를 쓰지 않아도 말이다.

### Imports
ES2015 모듈 신택스(`import`와 `export`)를 따라서 선언된 모듈들만이 트리쉐이킹을 할 수 있다. 당신이 모듈을 임포트하는 방식이 그 모듈이 트리쉐이킹 할수 있는지 여부를 나타낸다.

트리쉐이킹은 사이드 이펙트와 함께 엔트리 포인트의 모든 파트들을 거치면서 시작된다. 그리고 새로운 섹션에 도달할때 까지 그래프의 가장자리들까지 순회한다. 순회가 완료된다면, 자바스크립트 번들은 순회가 이루어지는 동안에 도달한 부분들만 포함한다. 그 외의 조각들은 포함되지 않는다. 다음과 같은 `utilities.js`라는 파일을 만들었다고 해보자:

```js
export function read(props) {⁣⁣
    return props.book⁣⁣
}⁣⁣
⁣⁣
export function nap(props) {⁣⁣
    return props.winks⁣⁣
}
```

그리고 다음과 같은 index.js 파일이 있다:

```js
import { read } from 'utilities';⁣⁣
⁣⁣
eventHandler = (e) => {⁣⁣
    read({ book: e.target.value })⁣⁣
}
```

예시에서, `nap()`은 중요하지 않다. 그러므로 번들에 포함되지 않는다.

### Side Effects

우리가 ES6 모듈들을 임포트 할때, 이 모듈은 즉시 실행된다. 우리가 어디에서도 모듈의 exports들을 코드에서 언급하진 않더라도, 모듈 자체가 실행될때 글로벌 스코프에 영향을 미치면서 발생 할수 있다. (polyfill 혹은 global stylesheets 같은 것들) 우리는 이것을 사이드 이펙트 (side effect)라고 부른다. 모듈 자체의 exports를 언급하지 않더라도, 만약 모듈이 시작과 함께 값들을 exports 한다고 하면, 모듈은 트리쉐이킹 될 수 없다. 그것이 import될때에 특정한 행동 동안에는 말이다.

Webpack 다큐먼트가 [트리 쉐이킹의 명확한 설명](https://webpack.js.org/guides/tree-shaking/#clarifying-tree-shaking-and-sideeffects)을 해준다. 그리고 어떻게 트리쉐이킹을 잘하게 만드는지도 알려준다.











트리 쉐이킹 번역 글

# Fastlane iOS - match 에서 duplicate profiles 오류가 뜰 때에 해결법

회사에서 fastlane 으로 iOS 빌드 자동화를 할 일이 생겨서 전체적으로 쭉 들여다 보는 와중에 해결하기 참 애매한 상황을 맞닥뜨렸다.

`match`를 이용하여 codesign에 필요한 certificate 및 profile들을 관리하는 레포와 연동을 해야 하는데, 다음과 같은 에러가 뜬 것 이다.


![에러사진.png](/uploads/1659405247751.png)


```bash
multiple profiles found with the name match 'match AppStore xxx.xxx.xxx'. Please remove the duplicate profiles and try again
```

말 그대로 `match AppStore xxx.xxx.xxx`이라는 name을 가진 profile이 존재 하고 있다는 것이다.
정확히는 모르겠지만, profile name이 하나의 unique key가 되어 profile을 구분하는 구분자로 사용되는 것 같았다.

따라서 이 오류를 해결 하기 위해선, 다음과 같은 두가지 방안이 떠올랐다.

1. 이미 만들어져 있는 동일한 이름의 프로필을 `match nuke`를 사용하여 없애거나 직접 developer portal에 들어가서 삭제한다
2. 1번의 방법이 안되면, cert와 sigh를 사용하여 우회한다

결론부터 말하자면 위 방법 모두 해결책이 되진 못했다.

이유는 다음과 같다.
1번의 경우 회사의 apple developer 계정으로 apple developer portal에 접속해도, `match AppStore xxx.xxx.xxx`와 같은 이름의 profile은 찾아 볼 수 없었다.
오리무중 이었다. 도저히 아무리 찾아봐도 우리가 관리하는 프로필에는 저런 이름을 가진 것이 없었다.

2번으로 어떻게 해보려고 했지만, github action에서 돌려야 해서 현실적인 부분에 부딪혔던 것 같다.

이렇게 삽질을 하던 도중, match를 사용하여 custom profile name을 주어서 굳이 `match AppStore xxx.xxx.xxx`와 같은 이름의 profile을 만들지 않아도 되는 방식을 알아냈다.

이 방식을 소개하려고 한다.
나는 fastlane cli 명령어를 사용하진 않았고, Fastfile에 custom 한 lane을 만들어서 실행했다.

## 1. 먼저 필요하다면 기존 profile을 삭제하는 match nuke를 실행한다

```ruby
match_nuke(
	type: "appstore",
	api_key: app_store_connect_api_key, # fastlane action 중 app_store_connect_api_key를 사용하여 받아온다.
	username: "apple developer account email", # 이쪽에서는 apple developer account email을 입력
	app_identifier: "bundle id", # app bundle id 입력
	profile_name: "match AppStore xxx.xxx.xxx" # optional (nuke할 profile의 name을 입력)
)
```

## 2. 실제 apple developer portal 에 profile을 만든다
```ruby
get_provisioning_profile(
	development: false,
	force: true,
	team_id: "apple developer team id", # apple developer team의 id를 입력
	filename: "xxxxxx.mobileprovision", # .mobileprovision이라는 확장자로 끝나는 파일 이름을 입력
	provisioning_name: "custom AppStore xxx.xxx.xxx" # 커스텀하게 만들 provisioning의 이름을 입력
)
```
만약 developer portal에 들어가서 profiles 탭에서 만들어진 profile의 상세를 눌러서 edit을 눌러보았을때, 하단의 certificates 옵션이 ios distribution으로 잡혀있다면 xcode와 모두 연동이 가능한 distribution으로 바꾸어준다.

## 3. match (readonly false)를 통해서 provisioning을 GitHub repo 에 연동시켜준다
```ruby
match(
	git_url: "https://github.com/user-name/repo-name", # certificate을 관리하는 github repo의 url을 입력
	storage_mode: "git",
	type: 'appstore',
	app_identifier: "xxx.xxx.xxx", # app bundle id 입력
	readonly: false, # readonly 를 false로 해줌으로써 repo와 연동할수 있게 함
	verbose: true,
	api_key: app_store_connect_api_key, # app store connect api key
	profile_name: "custom AppStore xxx.xxx.xxx" # 특정 커스텀하게 만든 프로필의 이름을 입력, 이 provisioning이 repo와 연동되게 됨
)
```

이렇게 하면 실제 repo와 연동하여 굳이 match가 정해준 이름이 아니더라도 커스텀한 이름을 사용할 수 있다.



Fastlane iOS - match 에서 duplicate profiles 오류가 뜰 때에 해결법

render pattern

rendering pattern

client side rendering

static rendering

server side rendering

patterns.dev 렌더링 패턴 소개

rust

web assembly

wasm

# Rust로 작성된 언어를 wasm-pack으로 js로 빌드하기

## 1. rust 및 wasm-pack 설치

* 만약 아직 rust가 기기에 설치되어 있지 않다면, https://rustup.rs/ 에서 rustup을 사용하여 rust를 설치해준다.
* https://rustwasm.github.io/wasm-pack/installer/ 링크를 참조하여 `wasm-pack` 을 기기에 설치해 준다.

## 2. cargo를 사용하여 rust 템플릿 생성

```bash
cargo new --lib my-lib
```

위와같이 명령어를 실행하게 되면, my-lib이라는 이름의 rust 템플릿 디렉터리가 생성된다.

## 3. Cargo.toml 작성

```toml
[package]
name = "<name>"
version = "<version>"
authors = [<author>]
edition = "<year>"
description = "<description>"

[lib]
crate-type = ["cdylib", "rlib"]

[dependencies]
wasm-bindgen = "0.2.63"
```

Cargo.toml에 대한 자세한 정보는 https://rustwasm.github.io/docs/wasm-pack/tutorials/npm-browser-packages/template-deep-dive/cargo-toml.html 이쪽 링크를 참조하면 자세히 설명되어 있다.


## 4. Javascript로 export 할 Rust 코드 작성

`lib.rs`
```rust
extern crate wasm_bindgen;

#[wasm_bindgen]
pub fn add(x: i32, y: i32) -> i32 {
	x + y
}
```

위와 같이 wasm_bindgen을 이용하여 js로 export할 rust 함수를 만든다.

```bash
wasm-pack build
```

wasm-pack 을 사용하여 Build를 하게 되면 pkg 디렉터리가 생긴다.
이곳에는 wasm_bindgen을 사용하여 작성한 코드들이 js 및 ts 파일로 생성된다.

이것을 다음과 같이 js파일에서 import 할 수 있다.

`package.json`
```json
...
"dependencies": {
  "rust-wasm": "file:../pkg",
  ...
},
...
```

```js
import * as wasm from "rust-wasm/rust_wasm";

alert(wasm.add(1, 2));

```

> 참고 자료
[utilForever님의 rust-wasm-ts-template](https://github.com/utilForever/rust-wasm-ts-template)
[wasm-pack 공식 문서 - 매뉴얼 셋업](https://rustwasm.github.io/docs/wasm-pack/tutorials/npm-browser-packages/getting-started/manual-setup.html)







Rust로 작성된 언어를 wasm-pack으로 js로 빌드하기

# 개발자 2차 면접 후기 (타팀과의 면접)

2차면접은 두가지 종류가 있는 것으로 나는 경험했다.
1. CTO 혹은 해당 회사의 개발직군의 "장"급과의 면접
2. 타팀원과의 면접 (개발 직군이 아닌 다른 팀원들과의 면접)

아무래도 타 팀과의 면접에서 가장 많이 보는 점은 다음과 같을 것 이다.
1. "협업"을 우리와 잘 할 수 있는지
2. fit의 적합성 (우리와 오래 함께 할 수 있는지)

## 협업
개발자도 물론이고, 스타트업에서 일하는 모든 직군은 대부분 혼자 일하지 않는다.
한 회사의 목표점을 향해서 서로가 협업을 하면서 일하기 때문이다.
물론 기업의 규모가 커지면 커질수록 자신의 분야에 전문성을 더 요구하게 되고, 자신의 직군에 속한 사람들과 많이 일을 하게 되긴 하지만 타팀과의 협업이 아예 없어지는 것은 아니다.

개개인의 실력이 충분해도 이러한 협업 과정에서 어려움이 보인다면, 지원자를 최종 합격시키는 데에는 많은 의문사항이 들게 될 것이다.

협업은 결국 서로 다른 시점을 가진 사람들이 자신의 의견을 제시하며 서로가 fit을 맞추며 일하는 과정이라고 생각 한다.
한 사람만의 의견으로 모든 일을 진행해 나갈 수는 없는 법.
서로의 도움과 협력이 밑받침 되어야 좋은 프로덕트가 나온다고 생각한다.

협업을 잘한다는 것은 정답은 없는 것 같다.
사람마다 일하는 방식이 맞을 수도, 다를 수도 있기 때문이다.
하지만 가장 가까운 정답은 `서로 다른 사람들끼리 하나의 목표로 의견을 합치시키는 문화를 만드는 것` 이라고 생각한다.

의견만 맞으면 사실 개개인의 능력이 출중하다면 남은 것은 개인의 분야에서 결과물을 내는 것 뿐이다.
혼자서 일하는 것은 쉽다. 여럿이서 합을 맞춰 일하는 것은 정답이 없기 때문에 어렵다.

협업에서 제일 중요한 점은 서로 다른 사람들끼리 의견을 존중하며, 하나의 목적을 향해서 합리적인 방향으로 의견을 합치시키는 것이 제일 중요할 것 같다.

`따라서 너무 자신의 세계에 갖혀있어선 안된다.`

## fit의 적합성

사적으로도 fit이 맞는 사람들을 찾기란 힘들다.
하지만 회사에서는 어느정도 프로세스라는 것이 존재하기 때문에, 그 프로세스에 fit을 맞춘다고 생각하면 쉬울 것 같다.

내가 이 회사의 프로세스와 맞지 않다면, 나는 이 회사와 오래 함께하기 힘들 것이다.
개인의 의견만으로 이미 잡혀진 프로세스나 문화가 바뀌긴 힘들다.

하지만 직접 일을 해보기 전까지는 실제 프로세스를 경험해보기는 힘들다.
따라서 나는 면접에서 프로세스를 설명해달라고 하지는 않는 편이다.
대신 나와 같은 자리에서 면접관으로 참석하고 있는 사람들의 언어 습관이나 행동적인 면을 더 유심히 관찰하는 편이다.

회사의 프로세스는 여러사람들이 일하는 가장 효율적인 방식대로 형성되기 마련이다.
그 프로세스가 형성되는 주체는 결국 일하는 사람들이다.
일하는 사람들이 어떤 생각을 가지고 있고, 어떤식으로 말을하고 어떤 언행과 행동을 하는지, 이런 사소한 부분이 사실 프로세스를 만드는 가장 기초적인 면이라고 생각한다.

`프로세스는 결국 사람이 만든다. 그 사람의 인격과 행동을 유심히 관찰해보자.`













개발자 2차 면접 후기 (타팀과의 면접)

# Rust 설치하기

이 [사이트](https://www.rust-lang.org/tools/install)를 참조하여 Rust Lang을 mac에 설치했던 과정을 나타내보겠다.

## rustup을 사용하여 설치
```bash
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
```
## 환경변수 설정
ohmyzsh을 썼기 때문에 다음과 같이 rust lang의 bin 디렉터리를 환경변수에 등록하였다.
```shell
export RUST_BIN=$HOME/.cargo/bin
export PATH=$PATH:$RUST_BIN
```
그리고 zshrc 파일을 다시 실행시킨다.

```bash
source ~/.zshrc
```

```bash
rustc --version
rustc 1.60.0 (7737e0b5c 2022-04-04)
```

rust lang이 mac에 설치되고 전역 환경 변수에 등록되었다.

mac에 Rust 설치하기

# 페어 프로그래밍(Pair Programming)과 결함 테스팅, 검증 테스팅

## 1. 페어 프로그래밍의 정의
* 페어 프로그래밍은 애자일 개발 방법론 중의 하나로 하나의 개발 가능한 PC 에서 두 명의 개발자가 함께 작업하는 것을 말합니다.
* 네비게이터(navigator)가 전략을 제시하고 드라이버(driver)가 실제 코드를 작성하며, 이 열할을 각자 번갈아가며 수행합니다.
* 짝 프로그래밍이라고도 합니다.
* 장점
	* 지식 공유
    * 업무에 대한 집중도 상승
    * 코드 리뷰 및 개발 방향의 지속
    * 팀원을 잘 알게된다
* 단점
	* 생산성 저하
    * 피로도 상승

## 2. 결함 테스팅(dynamic verification)의 정의
* 소프트웨어의 실행을 통해 소프트웨어의 결함을 찾는 테스팅

## 3. 검증 테스팅(static verification)의 정의
* 소프트웨어를 개발하는 모든 과정에 해당한다
* 요구사항 분석, 코드 리뷰 등 소프트웨어를 실행하지 않는 범위내에서 결함을 찾는 것을 말한다

## 4. 결함 테스팅과 검증 테스팅
* 둘다 v&v 프로세스에서 사용
* 소프트웨어의 검증은 요구사항을 만족할 수 있는지 확인은 가능하나, 실제 고객의 요구사항의 만족인지 알기는 어렵다

### 참고 자료
1. https://blog.mathpresso.com/mathpresso-%EA%B0%9C%EB%B0%9C%EB%B0%A9%EB%B2%95%EB%A1%A0-1-%ED%8E%98%EC%96%B4-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-pair-programing-f7d07ac323d0
2. https://hodev.tistory.com/67

페어 프로그래밍과 결함 테스팅, 검증 테스팅

# Lean 프로세스

## 1. Lean의 개요
### 1 - 1. 린(Lean)의 정의
* 낭비의 제거를 통해 프로세스를 지속적으로 개선, 수행 속도를 높이고 소프트웨어의 품질을 향상시키는 기법 (단순 개발 프로세스가 아닌 경영 기법 혹은 사상)

### 1 - 2. 린(Lean)의 특징
* 신속성
    * Lean은 낭비를 발견하고 제거함으로써 고객에게 가치를 빠르게 제공
* 생산성 향상
    * 생산성 향상을 위해 Lean 원칙을 소프트웨어 개발에 적용
* 결함 제거
    * 소프트웨어 개발에 있어 가장 큰 낭비는 결함
    * 결함 제거 개념이 Agile과 유사 (Agile보다 큰 개념)
    * 프로젝트 초기 고객과 많이 접촉하여 낭비 및 폐기를 줄이는 프로세스

## 2. Lean 개발 방법론
### 2 - 1. Lean 개발 방법론의 정의
* TPS(Toyota Production System)를 재정립한 경영방법론인 린 시스템의 품질 기법을 소프트웨어 개발에 적용한 개발 방법론

### 2 - 2. Lean 개발 방법론의 특징
* 품질기법 : 린 공학 품질 기법을 SW 개발 프로세스에 적용
* 낭비요소제거 : 낭비요소 제거하고 7가지 개발원칙 준수

## 3. Lean의 개발 원칙 및 낭비 요소
### 3 - 1. 린의 개발 원칙
* 낭비제거
	* 불필요한 코드/기능, 불분명한 요구사항 등 소프트웨어 가치에 영향이 없는 모든 것을 제거
* 배움증폭
	* 프로세스 진행 중 참여자(기획자, 개발자, 사용자 등) 학습의 필요성 존재
* 늦은결정
	* 주요문제에 대한 의사결정을 최대한 연기함으로써 요구사항 변경에 적극적으로 대응
* 빠른인도
	* 결과물을 가능한 빨리 제공하는 것이 도움
    * 사용자측면 : 불확실성 감소, 개발자측면 : 결함발견의 기회
* 팀에 권한위임
	* 팀원들의 동기부여 및 자기의사결정권으로 잠재력 극대화
* 통합성구축
	* 개발 초기부터 지속적인 통합으로 품질 향상
    * 소규모 개발단계마다 오류 발견 및 수정
* 전체최적화
	* 요구사항수집부터 S/W 배포까지 모든 프로세스 최적화

### 3 - 2. 린의 낭비 요소
* 미완성 작업
	* 코드화 하지 않은 문서, 테스트하지 않은 코드 등
* 여분기능
	* 필요하지 않은 기능을 추가
* 재학습
	* 지식보유자가 개발에 참여하지 못해 해당 지식을 학습하는 활동
* 이관
	* 업무 이관 시 상당량의 암묵지가 전수되지 못하는 경우
* 작업전환
	* 작업수행 중 다른 작업으로 전환할 경우 집중력 분산 및 시간소모
* 지연
	* 특정 인력이 가용한 상태가 될 때까지 기다림
* 결함
	* 테스트에 결함 유입을 걸러주는 실수방지테스트 포함

## 4. 린과 애자일 방법론의 비교
* 공통점
	* 요구 사항 변화를 빠르게 수용
    * 결과물을 사용자에게 빠르게 전달하여 고객가치와 만족도를 높임
* 차이점
	* 애자일: 사용자와의 협업을 통해 빠른 개발을 수행 (사용자와 협업)
    * 린: 사용자 관점에서 전체 프로세스 상 낭비 제거 (전적으로 사용자 관점)


### 참고 자료
1. https://itproda.tistory.com/90
2. https://needjarvis.tistory.com/323



Lean 개발 방법론

# 원격 의료 (U-Health)

## 1. 정의 및 필요성
* 정의
	* 유헬스는 유·무선 네트워킹이 가능한 정보통신기술을 활용하여 시간과 장소에 상관없이 언제 어디서나 이용 가능한 건강 관리 및 의료 서비스를 지칭한다.
    * 유헬스의 유(U)는 유비쿼터스에서 첫 글자를 따온 것이다

## 2. 장점과 문제점
* 장점
	* 전통적인 의료 영역에서 벗어나 시간적 공간적인 확대, 소비자 공급자의 확대, 서비스의 다양화 등 도모 가능
    	* 원격 진료 예약 및 원격 진료 가능
        * 집에서도 나의 건강 상태를 손쉽게 체크 가능
    * 시간적인 손실의 감소
    	* 굳이 병원에 매번 가지 않더라도, 원격으로 진료를 받을 수 있는 장점이 있다
    * 정보처리의 신속성
    	* 기술의 발달에 따라서 정보처리를 하는 속도가 빨라져 신속성이 좋아진다
    * 의료 비용의 감소
    * 부정확한 의료 제공의 방지
    	* 빅데이터 기술과 인공지능 기술의 발전에 따라서 더 정확도 높은 진료가 가능해진다.
    * 직접 대면하는 의료 서비스의 이용이 어려운 사람들, 혹은 취약 계층들에게 유헬스를 이용하여 적절한 서비스 제공 가능
    * 실시간 건강 모니터링 가능

* 문제점
	* 프라이버시 문제
    	* IoT를 사용한 uHealth 기술에 대해서는 개인의 프라이버시가 침해 될 가능성이 있다.
        * IoT 디바이스가 해킹당할 경우 개인의 의료 정보가 악용될 수 있다.
    * 불평등 문제
    	* uHealth 서비스를 이용할 수 없는 사람들에게는 의료 서비스 불평등 문제가 발생 할 수 있다.
    * 건강 행태 변화에 대한 책임 문제

## 3. 활용 될 수 있는 정보 통신망 기술
* 헬스케어 소프트웨어가 장착된 웨어러블 디바이스 기술
* 병명 진단에 인공지능과 빅데이터를 활용할 수 있다
* 사물 인터넷 (IoT)를 기반으로 사람이 사용하는 물건에 uHealth 기술을 접목 할 수 있다
* 병의원 어플리케이션 개발 기술을 바탕으로 원격 진료 예약을 하는 어플리케이션을 개발 할 수있다.

## 4. 결론

헬스케어 클라우드 컴퓨팅 시장이 매년 20% 이상의 성장률이 기대되는 등, 유헬스 분야의 발전이 기대되고 있다.
인공지능, 빅데이터, IoT와 같은 기술의 대중화와 함께 uHealth의 기술의 발전도 같이 기대되고 있는 추세이다.
또한 현재 인공지능과 빅데이터 기술을 바탕으로 uHealth 분야의 스타트업도 많이 성장을 하고 있는 추세이다.
따라서 앞으로 시간이 갈 수록, 전통적인 의료 진료 프로세스에서 벗어나서 조금 더 시간을 절약하고 맞춤형 진료 프로세스가 uHealth와 함께 이루어 질 것이다.
하지만 이에 따라, uHealth의 비용을 감당하지 못하여 의료 서비스의 불평등을 겪을 수 있다.
또한 IoT를 사용하기 때문에, 기기가 해킹을 당한 다던지 등의 개인의 프라이버시 문제가 확산 될 수 있다.
따라서 이러한 새로운 헬스케어 기술이 조금 더 안정적으로 서비스 되려면 상기 문제들을 해결함이 중요하고 윤리적인 면과 의료사고를 예방하기 위해 법적인 제재나 규율이 조금더 자리잡힐 필요성이 있어 보인다.
하지만 uHealth 분야는 현재 급속도로 성장하고 있는 분야이므로, 시행 착오 과정을 거쳐 결국은 미래의 산업으로 자리매김 할 것으로 예상된다.

### 참고자료
1. https://ko.wikipedia.org/wiki/%EC%9C%A0%ED%97%AC%EC%8A%A4

원격의료 (U-Health)

# 개발자 1차 (기술) 면접 후기

최근 이직을 준비하면서, 3 ~ 4개 정도 회사에 지원을 했다.
자세한 프로세스나 이직 관련 내용은 회사의 자산에 등록된 경우가 많으므로, 회사의 실명은 거론하지 않겠다.

개인적으로 이직을  준비하면서 또 한번 다시 공부하는 마음을 가졌다.
경험적으로도  좋은 경험이었다. 

이  글에서는  1차 면접 (기술면접)에서만 다룰 예정이고, 가장 면접경험이  좋았던  하나의 회사를 골라서 글을 작성할 것 이다.

## 기술면접에서는 무슨 질문들이 나오는가?

### 1. 자신에 대한 소개
* 자신을 어떤 개발자라고 한마디로 표현할 수 있을지?

처음  본격적인  인터뷰에 들어가기 앞서 대부분  면접관과  면접자의 어색한 기류를 없애기 위해 아이스브레이킹 타임으로 소개시간을 갖는다.
이때 면접자는 자신에 대한 소개를 하게  된다.

여기에서  단순하게  나에  대해 소개를  하였다.
ex) `모 회사에서 프런트엔드 개발자로 근무하고 있는 아무개 입니다. 현재 X년차 입니다 등`
이후에 질문이 들어왔다.
> 자신을 어떤 개발자라고 한마디로 표현할 수 있을지?

나는 `아이디어를 실현하는 것을 좋아하는 개발자`라고 대답했다.
너무 횡성 수설하지 않은 간단한 이유를 덧붙이기도 했다.

좋은 질문인 것 같다. 결국 기술면접이란, 축약적으로 다음과 같은 항목을 알아보는 것이 가장 중요한 것 같다.
* 면접자가 특정 기술에 대해서 이론적으로 혹은 실무적으로 얼만큼 알고 있는지?
* 이 면접자가 추구하는 기술을 다루는 방향은 무엇인지?
* 이 면접자가 당황하지 않고 돌발상황에 대처를 어떻게 하는지에 대한 태도
* 추가적으로 면접자가 경력자라면 자신의 포트폴리오나 회사에서의 경험

### 2. 본격적으로 회사에서 쓰는 특정 기술을 얼마나 알고있는지 알아보는 시간

이제 소개가 끝났으니, 어느정도는 이 면접자가 어떠한 방향으로 성장해왔고 혹은 어떤 방향으로 성장하고 나아가고 싶은지 알게 되었다.
이제는 실력을 알아볼 차례.
기술 면접에서 가장 중요한 파트인 것 같은데, 회사에서 쓰는 특정 기술에 대한 깊이를 보는 시간이다.

기본적으로 자신의 파트의 기술의 백그라운드 지식도 중요하지만, 메인 기술에 대한 이론적 요소와 감각은 같이 일할 개발자에게 꼭 알아봐야 하는 과정이다.

나는 프런트엔드 개발자 중에서도, React를 이용하여 주로 개발하는 개발자 이다.
따라서 면접시간에서는 React의 기본적인 지식을 물어보는 것으로 시작했다.
* Virtual DOM에 대해서 설명을 부탁드립니다 !

블로그를 시작하길 잘했다는 생각이 여기서 들었다. 블로그를 시작하면서 Virtual DOM에 대해서 알아보고자 글을 썼는데 참 많은 도움이 되었다.

[Virtual DOM에 대한 내 블로그 글](https://blog.coldsurf.io/article/Virtual%20DOM%EC%9D%80%20%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C%3F)

가장 중요한 부분은 아무래도 Diffing Algorithm을 사용해서 비교하는 부분이 아닐까 싶다.
그리고 Virtual DOM을 왜 쓰게 되었는지에 대한 이유까지 알면 훨씬 좋을 것 같다.

이 파트에서 강조하고 싶은 부분은, `기본을 무시하지 말자`이다.
자신이 쓰는 기술의 기본을 알고 있는지, 얼마나 탄탄하게 알고 있는지에 대해 보는 시간이므로 기술 면접전에 숙지해두고 참석하면 많은 도움이 된다.

### 3. 그렇다면 돌발상황에서는 어떻게 대처할까?

이것을 보는 가장 좋은 방법은 아무래도 `라이브 코딩` 일 것이다.
내가 보았던 면접에서는 어떻게 보면 까다로울수 있지만, 그렇게 시간이 많이 들지는 않는 알고리즘 라이브코딩을 진행 하였다.

아마 내 생각에 이 시간에서는 라이브 코딩을 하는 모습을 보면서 다음을 평가할 것 같다.
1. 돌발 상황에서 어떻게 행동하는지?
2. 문제를 풀어가는 과정이 합리적인지?
3. 합리적인 판단으로 당황하지 않고 결과를 도출해 내는 능력

따라서, 평소에 시간이 남을때에 꾸준히 알고리즘 공부를 해두면 좋다.
결국 알고리즘문제 해결능력은 감각이고, 여러번 풀다 보면 감각이 자라나는 것 같다.

[프로그래머스](https://programmers.co.kr/) 사이트를 추천한다!

### 4. 좋다! 이제 라이브코딩까지 했으니, 최신 기술에 대한 관심도를 알아보자. (feat. optimization)

간단한 예로 예전에는 window에 scroll 이벤트리스너를 등록하여 무한 스크롤링을 구현하는 경우가 많았다.
사람들의 글을 보아 요즘은 IntersectionObserver로 reflow를 최적화하여 무한 스크롤링을 구현하고 있는 태세로 돌아서는 것 같다.

이러한 예시처럼 최신 기술에 대한 관심도를 측정하는 시간이었다.
또한 단순히 이론적거나 기본적인 기술보다는 조금 더 심도높은 최적화에 대한 이야기도 같이 나누었다.

최적화 부분은 개인적으로 사이드 프로젝트가 많이 도움이 되었다.
아무래도 회사 프로젝트는 최적화도 조심스럽기 때문에, 조금 더 자유롭게 최신 기술을 써가면서 최적화 까지 할 수 있는 사이드 프로젝트를 경험해보는 것이 큰 도움이 될 것이다.

단순히 런칭만 하고 끝내는 것 보다, 계속 어떻게 하면 조금 더 나은 서비스를 제공할 수 있을지에 대해 심도있게 생각하다보면 최적화 기술도 자연스레 성장하리라 본다.


## 마치며

간단하게 4가지의 섹션으로 개발자 기술 면접에 대한 요약 및 정리를 해보았다.





















개발자 1차 (기술) 면접 후기

# IntersectionObserver 잠깐 알아보기

## IntersectionObserver란?

IntersectionObserver는 web API 이다.
Intersection Observer API는 타겟 요소와 상위 요소 또는 최상위 document 의 viewport 사이의 intersection 내의 변화를 비동기적으로 관찰하는 방법이다.

[출처](https://developer.mozilla.org/ko/docs/Web/API/Intersection_Observer_API)


## IntersectionObserver를 쓰는 이유

전통적으로 예전부터 스크롤을 감지하여 HTML element를 관리할때에 window의 scroll event listener를 사용하여 스크롤을 감지하거나, HTML element의 가시성을 알아볼때에 사용했다.

하지만 이 window의 scroll event listener의 단점이 있었다.

* 이 스크롤 이벤트가 발생할때마다 event listener의 콜백함수가 동작되므로 그것이 단시간에 불필요하게 수백번, 수천번 작동할수 있다. (debounce 혹은 throttle 방식을 적용하여 이 문제를 개선 가능)
* 그리고 특정 지점을 관찰하기 위해서 `getBoundingClientRect()` 함수를 사용해야 하는데 이 함수를 사용시에는 `리플로우(reflow)` 현상이 발생한다

> Reflow: 브라우저가 웹 페이지의 일부 또는 전체를 다시 그려야 하는 경우 발생

이러한 기존 방법론의 단점을 보완하기 위해서 IntersectionObserver API가 등장했다.
비 동기적으로 실행되기 때문에, 메인 쓰레드에 영향을 주지 않으면서 변경 사항을 관찰 할 수 있다.
또한 `IntersectionOberverEntry` 의 속성을 활용하면 `getBoundingClientRect()`를 호출한 것과  같은 결과를 알 수 있기 때문에 따로 `getBoundingClientRect()` 함수를 실행 시킬 필요가 없다.
따라서 `Reflow`현상이 발생하는 것을 방지 할 수 있다

[출처](http://blog.hyeyoonjung.com/2019/01/09/intersectionobserver-tutorial/)

## IntersectionObserver 간략 사용법
```js
const observer = new IntersectionObserver(callback, options)
```
형식으로 생성을 하여 쓴다.
그렇다면 세세하게 한번 callback, options 그리고 생성자로 받은 생성자 객체에는 어떤 것을 포함하고 있는지 알아보자.

### IntersectionObserver - callback

```js
let callback = (entries, observer) => {
  entries.forEach(entry => {
    // Each entry describes an intersection change for one observed
    // target element:
    //   entry.boundingClientRect
    //   entry.intersectionRatio
    //   entry.intersectionRect
    //   entry.isIntersecting
    //   entry.rootBounds
    //   entry.target
    //   entry.time
  });
};
```

### IntersectionObserver - options

```js
let options = {
  root: document.querySelector('#scrollArea'),
  rootMargin: '0px',
  threshold: 1.0
}

let observer = new IntersectionObserver(callback, options);
```
* threshold: 1.0 은 대상 요소가 root 에 지정된 요소 내에서 100% 보여질 때 콜백이 호출될 것을 의미합니다. 혹은 25% 단위로 요소의 가시성이 변경될 때마다 콜백이 실행되게 하고 싶다면 [0, 0.25, 0.5, 0.75, 1] 과 같은 배열을 설정하세요.
* root: 대상 객체의 가시성을 확인할 때 사용되는 뷰포트 요소입니다. 이는 대상 객체의 조상 요소여야 합니다. 기본값은 브라우저 뷰포트이며, root 값이 null 이거나 지정되지 않을 때 기본값으로 설정됩니다.
* rootMargin: root 가 가진 여백입니다. 이 속성의 값은 CSS의 margin 속성과 유사합니다. e.g. "10px 20px 30px 40px" (top, right, bottom, left). 이 값은 퍼센티지가 될 수 있습니다. 이것은 root 요소의 각 측면의 bounding box를 수축시키거나 증가시키며, 교차성을 계산하기 전에 적용됩니다. 기본값은 0입니다.

### IntersectionObserver - 생성자로 받은 객체

```js
let observer = new IntersectionObserver(callback, options);
let target = document.querySelector('#listItem');
observer.observe(target)

...

observer.unobserve(target)
observer.disconnect()

```

* observe: 특정 HTML Element를 관찰 하게 된다.
* unobserve: 특정 HTML Element의 관찰을 멈춘다.
* disconnect: observer가 모든 HTML Element에 대한 관찰을 멈춘다


## IntersectionObserver를 실무에서는 어떻게 쓸까?

### 예제 1. 무한 스크롤링
간단한 이 블로그 프로젝트에 쓰인 사용법을 소개하며 글을 마치려고 한다.
무한 스크롤링을 구현해서 더 가져오기 기능을 구현하는데 쓰였다.

```js
useEffect(() => {
  let observer: IntersectionObserver
  observer = new IntersectionObserver(
      (
          entries: IntersectionObserverEntry[],
          observer: IntersectionObserver
      ) => {
          const [entry] = entries
          if (
              !entry.isIntersecting ||
              articles.length < DEFAULT_PAGINATION_COUNT
          ) {
              return
          }
          loadMore()
          observer.unobserve(
              loadingIndicatorElementRef.current as Element
          )
      },
      {
          threshold: 0.5,
      }
  )

  if (loadingIndicatorElementRef.current) {
      observer.observe(loadingIndicatorElementRef.current as Element)
  }

  return () => {
      if (observer) {
          observer.disconnect()
      }
  }
}, [articles.length, loadMore])

...

return (
  ...
      <div
          className={css`
              display: flex;
              align-items: center;
              justify-content: center;
              width: 100%;
              margin-top: 10px;
              margin-bottom: 10px;
          `}
          ref={loadingIndicatorElementRef}
      >
          {isLoading && <RotatingLines width="100" />}
      </div>
	</ArticleListContainer>
)
```

설명을 해보자면 react의 ref를 사용하여 `loadingIndicatorElementRef`를 일반 div element에 주입을 시킨다. 그 div element가 IntersectionObserver가 관찰하게 될 HTML Element이다.
유저가 스크롤을 하여 하단으로 스크롤을 내리면, 특정 하단의 div element가 보이게 되고, 따라서 그것을 관찰하던 IntersectionObserver가 관찰을 하다가, 특정 threshold에 맞추어 콜백함수를 실행한다. threshold 값이 만족이 된다면, entry의 `isIntersecting` 속성이 true로 변하게 된다.
따라서 그때에 필요한 비즈니스 로직을 실행하게 된다. 여기서는 loadMore 함수를 실행 시킨다.

### 예제 2. dynamically fixed 사이드바

```js
const NavItemList = styled.ul<{ isFixed: boolean }>`
    position: ${(p) => (p.isFixed ? 'fixed' : 'relative')};
    top: ${(p) => (p.isFixed ? '1rem' : '0px')};
    width: ${(p) => (p.isFixed ? '230px' : '100%')};

...
`

...

useEffect(() => {
    let observer: IntersectionObserver
    observer = new IntersectionObserver(
        (entries, observer) => {
            const [entry] = entries

            if (entry.isIntersecting) {
                setIsFixed(false)
            } else {
                setIsFixed(true)
            }
        },
        {
            threshold: 0.1,
        }
    )

    if (sideBarTopSpaceRef.current) {
        observer.observe(sideBarTopSpaceRef.current as Element)
    }

    return () => {
        if (observer) {
            observer.disconnect()
        }
    }
}, [])

return (
  <Container style={{ position: 'relative' }}>
      <div
          ref={sideBarTopSpaceRef}
          style={{
              height: '90px',
          }}
      />
      <NavItemList isFixed={isFixed}>
          <NavItem>
              <Link href={`/`} passHref>
                  <NavLink matched={router.pathname === '/'}>
                      <NavLinkText>All</NavLinkText>
                  </NavLink>
              </Link>
          </NavItem>
...
```
이 상황에 대해서 살짝 설명을 하자면, 사이드바가 특정 스크롤 높이에서는 fixed 상태가 되어야 하는 상황이다. 따라서 스크롤바 위에 특정 높이를 가진 div element를 놓고 그것을 IntersectionObserver를 이용해 관찰한다. 그 후, 특정 element가 `isIntersecting === true` 일때 `isFixed` 상태를 변경한다.







IntersectionObserver 잠깐 알아보기

# Event Loop in Browser 번역 (feat. Macro Task와 Micro Task)

[원글 링크 (dev.to)](https://dev.to/jasmin/difference-between-the-event-loop-in-browser-and-node-js-1113)

![how event loop works in browser](https://res.cloudinary.com/practicaldev/image/fetch/s--I8K4E512--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tg7893fgvd0q8im1fy3s.png)

1. Heap
	* 함수에서 정의한 object와 변수를 저장한다
2. Call Stack
	* 코드에서 만든 함수들을 LIFO형식의 스택으로 쌓는다.
    * 가장 마지막에 들어온 것이 가장 위에 쌓이는 형태 (가장 처음 들어온 것이 가장 아래에 쌓인다.)
3. Web API
	* V8 엔진에 의해서 제공되는 추가적인 기능들이다.
    * Web API를 사용하는 함수들은 이 컨테이너에 저장되었다가, Web API가 완료 시 나오게 된다. (callback 함수)
4. Queues
	* 비동기적인 코드의 응답을 계산하기 위해서 사용된다.
    * 이러한 응답들은 엔진을 블락하지 않는다.
    * **Macro Task Queue**
    	* Job Queue보다 낮은 우선순위에 있는 비동기 함수들을 실행시킨다.
        * 또한 DOM Events, Ajax calls, setTimeout 등의 함수들을 실행시킨다.
	* **Micro Task Queue**
    	* Message Queue 보다 높은 우선순위에 있는 비동기 함수들을 실행 시킨다.
        * promise를 사용하는 비동기 함수들을 실행시킨다.
        
> Event Loop는 Call Stack을 확인하여 Stack이 비어있을 때에 Queue에 있는 함수들을 Call Stack으로 넣고 실행한다. 이미 제공된 함수들은 높은 우선순위를 받게 되고 Message Queue에 있는 함수들보다 먼저 실행된다.

Event Loop in Browser 번역 (feat. Macro Task와 Micro Task)

# React memo를 쓸 때 주의해야 할 점 (feat. 배열의 아이템을 index로 가져오기)

이 글은 React memo를 쓰다가 나온 장애를 회고하는 글 입니다.

기존 코드는 다음과 같았다.

```jsx
export default memo(ProjectItemList, (prev, next) => {
  return prev.data.length === next.data.length && prev.data[0].id === next.data[0].id
});
```

배열의 아이템의 개수가 0개일때 exception 처리를 안한것이 에러의 원인.
따라서 유저가 생성한 project의 개수가 0개였을때 rerender가 일어나면 에러가 나는 현상 이었다.

다음과 같이 코드를 변경하였다.

```jsx
export default memo(ProjectItemList, (prev, next) => {
  const prevFirstId = prev.data?.[0]?.id;
  const nextFirstId = next.data?.[0]?.id;
  return prev.data.length === next.data.length && prevFirstId === nextFirstId;
});
```

test 파일에서는 단순히 `render`라는 testing-library의 함수로만 테스트를 했기 때문에 해당 에러를 잡을 수 없었다.
또한 dummy empty array에 대한 테스팅이 추가되어있지 않았고 무조건 array의 length가 1이상이었기 때문에, 빈 array에 대한 테스팅 조차 없었던 것이 테스팅으로 거를수 없었던 이유.

따라서 test파일에서는 `rerender` 함수를 사용하여 React.memo가 props를 compare하도록 만들었다.

```jsx
import { screen, render } from "@testing-library/react";

...
...

describe("ProjectItemList", () => {
  it("render with empty data array", () => {
    const { rerender } = render(
      <ProjectItemList
        data={fakeProjectList} // 이때에는 배열의 길이가 0
        renderItem={(item) => <ProjectItem key={item.id} data={item} />}
      />,
      {
        wrapper: AllTheProviders,
      }
    );
    expect(screen.getByTestId("project-item-list").children.length).toBe(0);

    // rerender를 사용하여 React의 memo가 작동하게 하여 memo내의 areEqual 콜백 함수가 작동하게 한다.
    rerender(
      <ProjectItemList
        data={fakeProjectList}
        renderItem={(item) => <ProjectItem key={item.id} data={item} />}
      />
    );
    expect(screen.getByTestId("project-item-list").children.length).toBe(0);
  });
```

## 결론
* 배열의 아이템을 index로 가져올 때에는 반드시 유효성 검사를 하자.
* React memo를 사용할때에 testing 코드를 쓸 때에 `@testing-library/react`모듈의  `rerender` 를 사용하여 memo 함수의 areEqual 콜백함수가 동작하도록 해서 memo를 테스트 할 수 있다.

React memo를 쓸 때 주의해야 할 점 (feat. 배열의 아이템을 index로 가져오기)

# 알고리즘 - number array flat 시키기

[코드샌드박스](https://codesandbox.io/s/condescending-haslett-xeqbm0?file=/src/index.js)

### 문제 1
> [1, [2, 3], [4, 5]]를 모두 flat 해보세요

**답안**

```js
function flat(numbers) {
  var answer = [];
  answer = numbers;
  answer = answer.flatMap((v) => v);
  return answer;
}

console.log("문제 1:", flat([1, [2, 3], [4, 5]]));
```

답안 설명: 간단하게 flatMap을 쓰면 1 depth array까지는 flatten이 가능하다.

### 문제 2
> [1, [2, 3], [4, 5], [4, [5, 6, [6, 7]]]]를 모두 flat 해보세요

**답안**

```js
function flatAll(numbers) {
  var answer = [];
  answer = numbers;
  while (answer.some((v) => Array.isArray(v))) {
    answer = answer.flatMap((v) => v);
  }
  return answer;
}

console.log("문제 2:", flatAll([1, [2, 3], [4, 5], [4, [5, 6, [6, 7]]]]));
```

답안 설명: depth 가 무한개일때라고 가정 할때, 모두 flatten작업이 들어가야 하므로, `some` 함수를 사용하여 하나라도 array type인 것을 걸러낸다. 따라서 answer값을 계속 검사하여 하나라도 array type을 가질때까지 모두 flat 작업을 계속 한다.

알고리즘 - number array flat 시키기

# useEffect와 useLayoutEffect

## useEffect
> componentDidMount 혹은 componentDidUpdate와는 달리 useEffect에서 사용되는 effect는 브라우저가 화면을 업데이트하는 것을 차단하지 않습니다.
이를 통해 애플리케이션의 반응성을 향상해줍니다.
대부분의 effect는 동기적으로 실행될 필요가 없습니다.
흔하지는 않지만 (레이아웃의 측정과 같은) 동기적 실행이 필요한 경우에는 useEffect와 동일한 API를 사용하는 useLayoutEffect라는 별도의 Hook이 존재합니다.

[React 문서](https://ko.reactjs.org/docs/hooks-effect.html)

이 설명을 코드로 풀어 말하자면 다음과 같다.

```jsx
const Page = () => {
	const [name, setName] = useState("")
    
    useEffect(() => {
    	setName("John Doe")
    }, [])
  
	return <h1>My name is {name}</h1>
}
```

위 코드에서 name값의 초기값은 ""이다.
useEffect를 사용하여 초기 렌더링 시 name값을 "John Doe"로 바꾸어준다.
실제로 이 코드를 실행 시켜 보면, 잠깐동안 layout shifting (깜빡이는 현상)이 일어날 것 이다.
(layout shifting을 경험해보기 위해서는, 브라우저의 네트워크 설정에서 throttling을 걸어서 느리게 할 필요가 있다.)

이것을 방지하기 위해서 `useLayoutEffect`를 사용할 수 있다.

## useLayoutEffect

위에서 쓴 코드를 useLayoutEffect를 사용한다면 다음과 같다.


```jsx
const Page = () => {
	const [name, setName] = useState("")
    
    useLayoutEffect(() => {
    	setName("John Doe")
    }, [])
  
	return <h1>My name is {name}</h1>
}
```

이렇게 사용한다면 John Doe라는 글자가 layout shifting이 없이 초기 화면에서 그려질 것이다.

* useLayoutEffect
	* **DOM이 그려지기 전**에 실행
	* 동기적
* useEffect
	* **DOM이 그려지고 나서** 실행
	* 비동기적

### 참고 자료
> https://merrily-code.tistory.com/46

useEffect와 useLayoutEffect

# Virtual DOM은 무엇인가?

[유튜브영상](youtube.com/watch?v=d7pyEDqBDeE)

## DOM
> Document Object Model

트리구조로 HTML, XHTML, XML 문서에서 보여주는 기준화된 API
Javascript를 HTML과 연결해준다.
DOM Node들은 직접 접근이 가능하다. (ex. getElementById)
Tree의 각 노드들은 html element를 나타낸다

## Web Browser 작동 순서
> HTML을 파싱하여 DOM Tree를 구성한다
-> 렌더 트리를 만든다
-> 렌더 트리의 레이아웃을 구성한다
-> 렌더 트리를 그린다

* DOM 트리 자체는 HTML 문서를 파싱하는 렌더링 엔진에 의해 생성된다. (ex. Webkit)
* CSS를 파싱하고 HTML에 파싱된 CSS를 적용하는 하여 렌더 트리를 생성한다
* 렌더트리가 브라우저에 그려진다.

우리가 node를 변경할때에 위의 일들이 매번 일어난다.
node의 변경이 자주 일어날수록, 뷰를 다시 그려주기 위해 브라우저가 받는 부하는 계속 된다.
굉장히 고비용의 일이 되는 것 이다.

## Virtual DOM을 사용함으로써 해결한 일들

* node들의 변화를 감지하여 바로 그려주는 대신, 먼저 Virtual DOM에 적용한다.
* Virtual DOM에 적용된 것은 실제 뷰에는 그려지지 않는다. 따라서 저비용의 작업에 해당한다. 새로운 빌딩을 짓는 것과 새로운 빌딩을 짓기위한 청사진을 그리는 것의 차이이다.
* 또한 Virtual DOM은 효율성을 위해 변화를 한번에 모아서 배치작업을 한다.

## Virtual DOM
> 단순히 Virtual DOM은 트리구조를 가지는 순수 자바스크립트 객체이다.

가볍고, 메모리 내부에 존재한다. 절대로 실제로 그려지지 않는다. 이 Virtual DOM이라는 아이디어는 React에 의해서 나왔지만, 다른 프런트엔드 프레임워크들에도 사용중이다. (ex. Angular 2, Vue)


## React의 Virtual DOM은 어떻게 작동할까?
* 초기 렌더링 작업에서, JSX는 템플릿 컴파일러에게 in-memory DOM Tree를 어떻게 생성할지 알려준다.
* `ReactDOM.render()` 함수를 불렀을때에, Virtual DOM Tree를 메모리 내부에서 생성한다.

## State의 변화 다루기
* 대부분 `setState`함수에 의해서 App이 업데이트 된다.
* 이 때에 Tree는 완전히 다르게 새로이 생성된다.
* state가 변할시에 두개의 다른 Virtual DOM이 메모리 내부에 존재하게 된다
* 이것은 비효율적으로 보이지만, 실제로는 그렇지 않다. React Element들은 굉장히 가볍기 때문이다.
* 이때에 React는 두개의 Tree를 비교한다. 그리고 두 Tree간의 차이점을 매핑한다.
* 그 차이점들을 조합하여 패치를 만들어내고, 변화를 실제 DOM에 반영한다.
* 이때 사용하는 diff 알고리즘은 실제 DOM을 업데이트하기 위해서 최소한의 작업을 찾기 위해 사용된다.
* 이러한 작업들은 batch되어 처리되어서 매 lifecycle 마다 실제 DOM은 한번만 변화된다.

## Diffing, or "Reconciliation"
* 최소한의 작업을 찾기 위한 것은 `O(n3)` complexity를 가진다.
* React는 `O(n)`을 사용한다.
* 어떻게? 두가지 가정에 의존한다.

### 가정 1
* 서로 다른 타입의 Element들은 서로 다른 Tree를 생성해낸다.
* 따라서 React는 두개의 서로다른 Tree를 비교할때에 각 트리의 Root Element를 비교한다.
* 만약 두개의 Root Element가 서로 다른 타입을 가지고 있다면, React는 이전의 Tree를 모두 새로운 Tree로 갈아 엎는다. Root Element 밑의 모든 SubTree를 새로이 그려낸다.

### 가정 2
* `key` 값을 사용하는 것이 자식 Element들의 변화를 감지하는데 힌트가 되어 줄 수 있다.
* 성능을 개선하기 위해서는 `key`값들이 모두 안정적이고 예측가능하고 중복된 값이 없어야 한다.

```html
<ul>
  <li>John</li>
  <li>Alice</li>
</ul>
```


```html
<ul>
  <li>John</li>
  <li>Alice</li>
  <li>Ed</li>
</ul>
```

`key` 값이 없다면 새로운 자식 element가 추가되어도, 모든 자식 element를 모두 다시 그려줘야 한다. 하지만 `key` 값으로 자식 element를 구분할 수 있다면, 어떤 것만 새로이 추가해야 하는지 알 수 있다.

```html
<ul>
  <li key="9">John</li>
  <li key="10">Alice</li>
  <li key="11">Ed</li>
</ul>
```

만약 `key` 값이 예측하지 못하는 random한 값이라면 (ex. Math.random()) React는 예측할 수 없기 때문에 자식 Element가 제대로 그려지지 못하는 현상이 발생 할 수 있다.

## 다음은?
### React Fiber
> React의 reconciliation 알고리즘을 다시 쓰는데에 새로 나온 것이다.
DOM 을 계속 순환하는 대신에, fiber라고 부르는 새로운 데이터 구조를 사용한다.
Fiber는 순수 자바스크립트 객체이며 parent-child node 간 관계를 하나의 linked-list형태로 트래킹한다. 위의 작업들은 "incremental rendering" 혹은 "scheduling"이라고 불리운다




Virtual DOM

# <dialog /> 대화 상자 요소
tabindex 속성을 dialog에 사용해서는 안 된다.
IE에서는 지원하지 않는다

## 속성
* open: 대화상자가 활성화 된 상태임을 나타낸다. open이 없을 때에 사용자에게 대화상자가 보여져선 안 된다. 

## 예시

### open
```html
<dialog open>
  <p>여러분 안녕하세요!</p>
</dialog>
```

### showModal event
```js
updateButton.addEventListener('click', function onOpen() {
  if (typeof favDialog.showModal === "function") {
    favDialog.showModal();
  } else {
    alert("The <dialog> API is not supported by this browser");
  }
});
```

### close event
```js
favDialog.addEventListener('close', function onClose() {
  outputBox.value = favDialog.returnValue + " button clicked - " + (new Date()).toString();
});
```

[MDN 문서](https://developer.mozilla.org/ko/docs/Web/HTML/Element/dialog)

dialog 태그

# LocalStorage

document 객체 안에 포함.

localStorage는 sessionStorage와 비슷하지만 sessionStorage는 session이 만료되면 사라진다.
localStorage는 session이 만료되더라도 사라지지 않는다.

localStorage는 http protocol에 따라서 다르게 저장된다.

같은 도메인 호스트를 가지고 있더라도, http와 https에서의 localStorage는 다르다.

자동으로 값은 문자열로 변환되어 저장되며, key, value 형태로 저장된다.
각 key, value는 2 byte를 최대로 UTF-16 DOMString 형태로 저장한다.

```js
localStorage.setItem(key, value);
localStorage.getItem(key);
localStorage.clear() // localStorage 항목 전체 제거
```

# Session Storage

브라우저가 열려있는 동안만 값을 저장한다.
세션 쿠키와는 다르게 새 탭이나 새 페이지를 열면 또 새로운 sessionStorage가 동작.
http protocol에 따라 다르게 동작한다. (http, https)
각 key, value별로 최대 2 byte까지 저장 가능, UTF-16 DOMString 형태로 저장.

```js
sessionStorage.setItem(key, value);
sessionStorage.getItem(key);
```

Web Storages

# Proj. surf-log (블로그  프로젝트)

[github repo](https://github.com/coldsurfers/surf-log)

## 1. Spec

* NextJS + Typescript
* marked + codemirror + prismjs

## 2. markdown meta build 기능 구현

```js
const fs = require('fs')
const path = require('path')
const matter = require('gray-matter')

const thumbnailDirPathStr = '../thumbnails'

function generateUniqSerial() {
    return 'xxxx-xxxx-xxx-xxxx'.replace(/[x]/g, (c) => {
        const r = Math.floor(Math.random() * 16)
        return r.toString(16)
    })
}

function main() {
    const mdFilesDirectoryPath = path.resolve(__dirname, '../articles')
    const mdFileNames = fs.readdirSync(mdFilesDirectoryPath, 'utf8')
    const mdFilesMetaArray = mdFileNames
        .map((fileName) => {
            const mdFilePath = path.resolve(
                __dirname,
                `../articles/${fileName}`
            )
            const mdFileContent = fs.readFileSync(mdFilePath, 'utf8')
            const mdFileMeta = matter(mdFileContent, {
                excerpt: function (file, options) {
                    file.excerpt = encodeURI(file.data.excerpt)
                    if (file.data.thumbnail) {
                        const thumbnailFileBase64Encoded = fs.readFileSync(
                            path.resolve(
                                __dirname,
                                `${thumbnailDirPathStr}/${file.data.thumbnail}`
                            ),
                            'base64'
                        )
                        file.thumbnailBase64 = thumbnailFileBase64Encoded
                    }
                },
            })
            return mdFileMeta
        })
        .sort((a, b) => {
            return new Date(a.data.createdAt) - new Date(b.data.createdAt)
        })
        .reduce((prev, curr) => {
            if (prev.find((prevItem) => prevItem.excerpt === curr.excerpt)) {
                curr.excerpt = `${curr.excerpt}-${generateUniqSerial()}`
            }
            return prev.concat(curr)
        }, [])
        .sort((a, b) => {
            return new Date(b.data.createdAt) - new Date(a.data.createdAt)
        })

    const categories = mdFilesMetaArray
        .map((meta) => meta.data.category)
        .filter((value, index, self) => self.indexOf(value) === index)

    const mdFilesMeta = mdFilesMetaArray.reduce((prev, curr) => {
        prev[curr.excerpt] = curr
        return prev
    }, {})

    const metaFilePath = path.resolve(__dirname, '../public/article-meta.json')

    const meta = {
        articles: mdFilesMeta,
        categories,
    }
    fs.writeFileSync(metaFilePath, JSON.stringify(meta))
}

main()

```

## 3. editor 기능 구현
[codemirror](https://codemirror.net/)로 editor 기능을 구현하였다.

## 4. markdown renderer 기능 구현
[marked](https://www.npmjs.com/package/marked) 모듈을 사용하여 markdown으로 작성된 string text를 html로 변환
prismjs로 코드 부분 Highlight

## 5. markdown 파일 쓰기(write) 기능 구현
next page api를 사용하여 구현.

```typescript
import { NextApiHandler } from 'next'
import fs from 'fs'
import path from 'path'

function generateUniqSerial() {
    return 'xxxx-xxxx-xxx-xxxx'.replace(/[x]/g, (c) => {
        const r = Math.floor(Math.random() * 16)
        return r.toString(16)
    })
}

const SaveAPI: NextApiHandler = (req, res) => {
    if (req.method === 'POST') {
        const { title, excerpt, category, thumbnail, text } = req.body
        let articlePath = path.resolve(
            __dirname,
            `../../../../articles/${title}.md`
        )
        if (fs.existsSync(articlePath)) {
            articlePath = path.resolve(
                __dirname,
                `../../../../articles/${`${title}-${generateUniqSerial()}`}.md`
            )
        }
        let content = `---
title: ${title}
excerpt: ${excerpt}
category: ${category}
thumbnail: ${thumbnail}
createdAt: ${new Date().toISOString()}
---
${text}`
        fs.writeFileSync(articlePath, content)
        return res.status(200).json({
            error: null,
        })
    }
    return res.status(501).json({
        error: 'not implemented',
    })
}

export default SaveAPI

```

## 6. markdown meta 정보 가져오기
nextjs server side api를 사용하여 다음과 같이 초기 fetching 후 pageProps로 페이지에 전달
```typescript
export const getStaticProps: GetStaticProps<ServerProps> = async (ctx) => {
    const articleMeta = (await import('../../public/article-meta.json')) as {
        articles: {
            [key: string]: Article
        }
        categories: string[]
    }
    return {
        props: {
            articles: Object.entries(articleMeta.articles).map(
                ([key, content]) => content
            ),
        },
    }
}
```

## 7. emotion으로 스타일링
[emotion](https://emotion.sh/docs/introduction)을 사용하여 style 코드 작성.
꽤나 편리하다. styled-components가 제공해주는 기능도 제공하면서 css로 children의 tag들도 모조리 styling 할 수 있는게 장점이다.
```jsx
import { css } from '@emotion/css'

...

<SaveModal
    className={css`
        label {
            font-weight: bold;
        }
        input {
            height: 1.5rem;
            margin-top: 0.5rem;
        }

        input + label {
            margin-top: 0.8rem;
        }

        button {
            margin-top: 1rem;
            font-weight: bold;
            background-color: #000000;
            border: 1px solid #000000;
            border-radius: 3px;
            color: #ffffff;
            cursor: pointer;
            height: 1.95rem;

            &:active {
                background-color: #ffffff;
                color: #000000;
            }
        }
    `}
>
    <label>Title</label>
    <input
        name="title"
        value={modalValues.title}
        onChange={handleChange}
    />
    <label>Excerpt</label>
    <input
        name="excerpt"
        value={modalValues.excerpt}
        onChange={handleChange}
    />
    <label>Category</label>
    <input
        name="category"
        value={modalValues.category}
        onChange={handleChange}
    />
    <label>Thumbnail</label>
    <input
        name="thumbnail"
        value={modalValues.thumbnail}
        onChange={handleChange}
    />
    <button onClick={handleClickSaveModalSave}>save</button>
</SaveModal>
```
앞으로 애용할 것 같다.

## 8. 배포

vercel을 사용하여 domain 연결 후 배포

## 9. 깃 전략

git flow를 사용


블로그 프로젝트 (proj. surf-log)

# JS Asynchronous

## Promise

Promise와 같은 비동기 작업은 eventQueue에 들어간다.
main thread가 끝난 후 실행되어 Javascript의 block 현상을 막는다.
queued된 작업들은 가능한 빨리 실행되어 Javascript 환경으로 결과를 반환해준다.

## Worker

분리된 thread에서 태스크들을 실행 가능하게 한다.
하지만 여러 thread를 동시에 사용한다면 동시성을 보장하기 어렵다.
따라서 이러한 사이드 이펙트를 막기 위해서 main 쪽 코드와 worker의 코드는 완벽히 분리되어야 한다. 같은 변수를 공유하면 사이드 이펙트가 일어난다.

### 종류
* Shared Worker
* Dedicated Worker
* Service Worker

## Animation

```js
element.animate();
```

### 예시

```js
const aliceTumbling = [
  { transform: 'rotate(0) scale(1)' },
  { transform: 'rotate(360deg) scale(0)' }
];

const aliceTiming = {
  duration: 2000,
  iterations: 1,
  fill: 'forwards'
}

const alice1 = document.querySelector("#alice1");
const alice2 = document.querySelector("#alice2");
const alice3 = document.querySelector("#alice3");

alice1.animate(aliceTumbling, aliceTiming);
```

JS Asynchronous 간략 설명

# HTTP 상태 코드 (HTTP Status Code)

웹 브라우저가 서버에 http 요청을 할 경우, 성공 혹은 실패 여부 및 다음 행동으로 무엇을 해야 하는지 알려주는 상태 코드이다.

그룹은 5개 그룹으로 나누어 진다.

# 100번대 (Information): 정보 응답
* 100 (continue): 서버가 request header는 받았고, 클라이언트가 request body를 보내고 있는 상태
* 101 (switching protocols): 요청자가 서버에게 switching protocol 을 묻는 상태
* 102 (processing): 요청자가 서버에게 요청 하였고, 서버가 이를 처리하였지만 응답이 없는 상태
* 103 (checkpoint): 중단된 Put과 Post 요청을 되찾을 수 있는 request를 사용하는 상태

# 200번대 (Successful): 성공 응답
* 200 (ok): 에러없이 성공이 완료된 상태
* 201 (created): request가 되었고, 요청을 바탕으로 새로운 자원이 만들어진 상태
* 202 (accepted): 서버가 request를 전송 받았으나, 현재 완전하게 처리되지 않은 상태
* 203 (non-authoritative information): 서버가 클라이언트 요구 중 일부만 전달한 상태
* 204 (no content): request 요청을 처리 후 클라이언트에게 전달 할 컨텐츠가 없는 상태. 주로 삭제 요청 후 status code로 쓰인다.
* 205 (reset content): no content 상태라서 클라이언트의 뷰가 reset이 필요한 상태
* 206 (partial content): 클라이언트의 header 범위 문제로 서버가 자원의 일부만을 전달**받은** 상태
* 207 (multi-status): 멀티-상태 응답은 다수의 리소스가 여러 개의 상태 코드인 상황이 적절한 경우에 해당되는 정보를 서비스에 전달한 상태 (*사실 무슨 말인지 잘 모르겠다*)
* 208 (multi-status): 멀티-상태 읍응답 DAV에서 사용, propstat(property와 status의 합성어) 응답 속성으로 동일 컬렉션으로 바인드된 복수의 내부 멤버를 반복적으로 열거하는 것을 피하기 위해 사용하는 상태 (*사실 무슨 말인지 잘 모르겠다*)
* 226 (IM Used): 서버가 GET 요청에 대한 리소스를 처리했으며, 응답이 하나 또는 그 이상의 인스턴스 조작이 현재 인스턴스에 적용이 되었음을 알리는 상태

# 300번대 (Redirection): 리다이렉션 응답
* 300 (Multiple Choices): 최대 다섯개의 링크를 골라서 이동할 수 있는 상태
* 301 (permanently moved): 요청된 페이지가 새로운 URL로 이동 된 상태
* 302 (found): 요청된 페이지가 일시적으로 새 URL로 이동 된 상태
* 303 (see other): 요청된 페이지는 다른 URL에서 찾을 수 있는 상태
* 304 (not modified): 마지막 요청 이후 수정되지 않은 상태
* 305 (use proxy): location 필드에 proxy의 URL을 사용하는 상태
* 306 (switch proxy): 사용하지 않는 코드
* 307: Temporary Redirect 302 Found HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 사용된 HTTP 메소드를 변경하지 말아야 하는 점만 다른 상태
* 308: Permanent Redirect 301 Moved Permanently HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 HTTP 메소드를 변경하지 말아야 하는 점만 다른 상태

# 400번대 (Client Error): 클라이언트 에러 응답
* 400 (Bad Request): 요청에 대한 문법적 오류가 있어서 서버가 이해할 수 없는 상태. 주로 전달 받은 요청의 자원의 불충분함을 나타낼 때 쓴다.
* 401 (Unauthorized): 특정 요청이 인증이 되지 않아서 권한이 없는 상태
* 402 (Payment Required): 최신 status code 인데 아직 쓰지 않는 걸로 알고 있음. 추후 payment 서비스에서 결제를 요할때 쓰는 것으로 알고 있다.
* 403 (Forbidden): 요청이 인증은 되었지만, 요청한 자원에 대해서는 접근 할 권한이 없는 상태. 401은 인증이 되지 않아서 누구인지 모르는 상태이지만 403는 인증은 되어서 요청자가 누구인지는 알고 있으나 요청한 자원에 대한 권한은 없음을 알리는 상태이다.
* 404 (NotFound): 요청한 자원을 찾을 수 없는 상태
* 405 (Method Not Allowed): 요청의 method가 제공되지 않은 상태
* 406 (Not Acceptable): request에서 accept header에 not acceptable의 내용을 가진 자원을 요청한 상태
* 407 (Proxy Authentication Required): 프록시 서버에게 해당 요청이 수행되도록 인증을 받아야 하는 상태
* 408 (Request Timeout): 요청 대기시간이 지난 상태
* 409 (Conflict): request 충돌로 인해서 요청이 완료되지 않은 상태, 생성 요청인데 이미 생성되어 있는 상태
* 410 (Gone): 요청 페이지는 더 이상 사용할 수 없는 상태
* 411 (Length Required): Content-Length 부분이 빠져서 요청을 허가하지 않은 상태
* 412 (Precondition Failed): request 헤더 필드에 선결 조건에 대한 값이 서버에서 false가 나온 경우
* 413 (Request entity too large): 요청 엔티티를 서버가 처리하기에 너무 큰 상태
* 414 (Request-URI Too Long): 요청 URI가 너무 긴 상태
* 415 (Unsupported Media Type): 지원하지 않는 미디어 타입을 요청한 상태
* 416 (Requested Range Not Satisfiable): 클라이언트가 파일의 일부를 요청했을 때 서버가 지원하지 않는 상태
* 417 (Expectation Failed): Expect request-header 필드의 요구를 서버가 충족시킬 수 없는 상태
* 418 (im a teapot): HTTP 418 I'm a teapot 클라이언트 오류 응답 코드는 서버가 찻주전자이기 때문에 커피 내리기를 거절했다는 것을 의미합니다. 이 오류는 1998년 만우절 농담이었던 하이퍼 텍스트 커피 포트 제어 규약(Hyper Text Coffee Pot Control Protocol)의 레퍼런스입니다.
* 422 (Unprocessable Entity): 요청은 잘 전달 됐지만, 문법 오류가 난 상태
* 429 (Too Many Requests): 사용자가 지정된 시간에 너무 많은 요청을 보낸 상태

# 500번대 (Server Error): 서버 에러 응답
* 500 (Internal Server Error): 포괄적인 서버 에러 메시지, 서버가 에러가 왜 났는지 어떻게 처리해야하는지 아직 모르는 상태. 서버 측에서 특정 에러에 대한 핸들링이 되어있지 않다.
* 501 (Not Implemented): 서버가 해당 요청 메소드를 인식 못하거나, 이행할 능력이 없는 상태
* 502 (Bad Gateway): 게이트웨이나 프록시의 상태가 나쁘거나 과부하인 상태
* 503 (Service Unavailable): 일시적으로 서비스가 사용 불가능 한 상태, (임시 조건에 사용되어야 하며, Retry-After: HTTP 헤더는 가능하면 서비스를 복구하기 전 예상 시간을 포함해야 함)
* 504 (Gateway Timeout): 과부하 등의 이유로 게이트웨이나 프록시의 한계 대기 시간이 지난 상태
* 505 (HTTP Version Not Supported): request에서 사용한 HTTP 프로토콜을 서버가 지원하지 않는 상태
* 511 (Network Authentication Required): 클라이언트의 접근을 위한 네트워크 인증이 필요한 상태

> 참고자료
http://www.incodom.kr/Status_code
https://developer.mozilla.org/ko/docs/Web/HTTP/Status/418





HTTP Status Code

# JAM Stack 그리고 SPA, CSR, SSR

# 목차
1. JAM Stack 이란 무엇인가?
2. JAM Stack은 SSR / CSR과 어떻게 다를까?
3. 그럼 SSR 방식은 필요가 없어진 것 일까?


## 1. JAM Stack 이란 무엇인가?
* J: Javascript
* A: API
* M: Markup

Javascript와 API 그리고 Markup(HTML)으로만 이루어진 웹의 구성을 이야기 한다.
우리가 알고 있는 SPA 과는 비슷하지만 다르다고 한다.
JAM Stack은 특정 기술 (ex. React, Vue)을 채택하는 것과는 다른 관점이며, 이들을 이용해서 웹사이트를 어떻게 구성할지에 대한 관점이다.

> **JavaScript**
Client 의 모든 처리는 Javascript 에게 맞긴다.
**API**
모든 기능 및 비즈니스 로직은 재사용 가능한 API 로 추상화한다.
**Markup**
SSG (Static Site Generator) 나 Template Engine (Webpack 등) 을 이용하여 Markup 을 미리 생성한다.


비슷하게 `MERN Stack`이 있다.
* M: Mongo DB
* E: Express
* R: React
* N: Node.JS

## 2. JAM Stack은 SSR / CSR과 어떻게 다를까?

React, Angular, Vue와 같은 모던 웹 프레임워크 및 라이브러리가 나오기 전에 SSR로 웹 사이트를 보여주었다. SSR이라 함은 브라우저의 요청을 받아 서버에서 html을 내려주어 렌더링 해주는 방식을 말한다. 하지만 이러한 방식은 CSR에 비해 서버의 자원을 많이 쓰게 되므로 그런 부분에서 비효율 적이다.
또한 속도측면에서도 CSR은 서버를 타지 않고 렌더링을 해주기 때문에, SSR에 비해 효율적이다.
페이지를 이동할 때 마다 서버에서 html을 받아서 뷰를 그려주는 것보다는 http request를 통해서 필요한 자원만 받아서 뷰에 그려주는 것이 속도상 이점이 있기 때문이다.

그래서 React와 같은 SPA (Single Page App) 프레임워크 및 라이브러리는 html 마크업 부분은 사실상 title 및 meta 를 나타내는 head 태그와 body 태그내에서 javascript를 이용하여 렌더링 할 tag를 지정해주는 태그 외에는 많은 부분이 비어있다.

SPA 방식은 서버에서 의존하던 클라이언트를 그려주는 방식에서 많이 탈피한 방식이다.
서버에서 html을 그리는데 필요한 자원을 모두 받아오는 SSR 방식에서 서버에서는 필요한 자원(클라이언트와 분리된 서버 API를 통해서)만을 받아오며 html은 기본 토대만을 담당 하며 나머지 클라이언트에서 보여주는 모든 뷰들은 자바스크립트와 css가 담당한다.

## 3. 그럼 SSR 방식은 필요가 없어진 것 일까?
SPA를 통한 CSR 방식은 다음과 같은 두가지 단점을 가진다.
1. SSR에 비해서 첫 그림을 그려주기 전 까지 딜레이가 걸린다.
2. HTML이 거의 비어있기 때문에, SEO (검색엔진 최적화)에 좋지 않다.

SPA를 사용한 CSR 방식은 위 두가지 단점에도 너무나 매력적인 스택이기 때문에, 위 두가지 단점을 보완하고자 하는 방식들이 나오게 되었다.

예를들면 부분적으로 SSR 방식을 채택한 Next (React)와 Nuxt (Vue) 등이 있다.
첫 페이지는 SSR로 보여주고, 나머지는 SPA의 javascript를 사용하여 CSR로 보여주는 방식이다.
이로써 단점 1번을 보완하여 첫 페이지는 완성된 html을 보여주어 `First meaningful paint`의 속도를 향상시키고 단점 2번을 보완하여 검색 봇이 html을 크롤링 해서 SEO를 향상 시켰다.






JAM Stack 그리고 SPA, CSR, SSR

# SOLID 원칙

## SOLID 원칙의 개요
컴퓨터 프로그래밍에서 SOLID란 로버트 마틴이 2000년대 초반에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 마이클 페더스가 두문자어 기억술로 소개한 것이다.
프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있다.
SOLID 원칙들은 소프트웨어 작업에서 프로그래머가 소스 코드가 읽기 쉽고 확장하기 쉽게 될 때까지 소프트웨어 소스 코드를 리팩터링하여 코드 냄새를 제거하기 위해 적용할 수 있는 지침이다. 이 원칙들은 애자일 소프트웨어 개발과 적응적 소프트웨어 개발의 전반적 전략의 일부다.

> 자료
https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)

좀 더 나은 코드의 품질을 위해 클린 코드를 지향하는 원칙인 것 같다.
프로젝트 사이즈가 커지면서 혹은 프로젝트 사이즈가 작더라도, 각 클래스가 맡은 일에 최대한 영향을 받지 않으면서 어떻게 깔끔한 코드를 작성 하는가에 대한 논리이다.

객체 지향 설계라고 나와있으나, 굳이 객체 지향 방법을 따르지 않는 react같은 라이브러리의 방식에도 적용할 수 있다.

사람이 이해할 수 있는 코드를 만드는데에 있어서 알고 있으면 굉장히 도움이 되는 원칙이라고 할 수 있다.

## SOLID 원칙의 내용
SOLID 원칙은 다음과 같이 5개로 나뉜다.

### S: 단일 책임 원칙 (Single responsibility principle)
>한 클래스는 하나의 책임만 가져야 한다.

단일 책임 원칙에 의하면 하나의 클래스는 하나의 책임, 즉 하나의 하는 일에만 집중해야 한다.
하나의 클래스가 하는 일이 여러개로 뭉쳐져 있다면, 클래스를 수정시에 다른 일들에 엮여서 깔끔하지 않을 가능성이 높다. 관심사를 분리하여 최대한 잘게 나누어 하나의 클래스는 하나의 일에 집중하도록 만들어야 추후 코드를 변경 할 시에도 안전하게 변경할 수 있다.

### O: 개방-폐쇄 원칙 (Open/closed principle)
> 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

만약 우리가 하나의 모듈을 수정했다고 가정 할 때에, 그 수정으로 인해 이 모듈을 쓰는 다른 곳에서 똑같이 수정을 해줘야 한다면 규모가 큰 프로젝트에서는 굉장히 많은 수정작업이 일어나야 한다.
따라서 무엇을 수정하여 모듈의 사용성을 확장 할 때에는, 이 모듈을 사용하던 기존의 코드를 **수정**하는 것이 아닌 코드를 **추가**하여 확장성을 넓히는 방향으로 가야한다.

```js
let cakeMaker = {
	availableFlavor: ['chocolate', 'milk chocolate', 'strawberry'],
  	makeCake: function(flavor) {
    	const cake = this.availableFlavor.find((v) => v === flavor)
        if (cake) {
        	return cake
        } else {
        	throw Error(`We don't have ${flavor} flavor`)
        }
    }
}
```

더 많은 맛을 가진 케익을 만들고 싶다면, 이 cakeMaker 코드에서 availableFlavor를 늘려주는 것이 아닌 아래와 같이 `addFlavor` 함수를 추가하여 이 cakeMaker를 사용하는 쪽에서 변경하는 것이 좋다.

```js
let cakeMaker = {
	availableFlavor: ['chocolate', 'milk chocolate', 'strawberry'],
    makeCake: function(flavor) {
    	const cake = this.availableFlavor.find((v) => v === flavor)
        if (cake) {
        	return cake
        } else {
        	throw Error(`We don't have ${flavor} flavor`)
        }
    },
    addFlavor: function(flavor) {
    	this.availableFlavor = this.availableFlavor.concat(flavor)
    }
}
```

### L: 리스코프 치환 원칙 (Liskov substitution principle)
> 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

하나의 인터페이스로부터 파생된 인터페이스를 만들고, 파생된 하위 인터페이스에서 확장을 한다.

### I: 인터페이스 분리 원칙 (Interface segregation principle)
> 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다

여러 기능이 모여진 인터페이스라면, 한 기능을 사용할때에는 다른 기능을 사용하지 않을 가능성이 생긴다. 따라서 이런 기능들을 분리하여 따로 인터페이스를 구현한다.

```typescript
interface Phone {
	call: {
    	photoShoot: () => void
        callTo: (phoneNumber: string) => void
    }
}
```

위와같이 call에서 photoShoot을 사용하는 일은 드물 것이다, 하지만 Phone객체는 photoShoot기능이 필요하다. 따라서 photoShoot기능은 call에서 분리한다.

```typescript
interface Phone {
	call: {
        callTo: (phoneNumber: string) => void
    }
    photoShoot: () => void
}
```

### D: 의존관계 역전 원칙 (Dependency inversion principle)
> 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다.

확장성이 필요할 시 이미 구현되어있는 구현체에서 작업을 한다기 보다는, 하나의 기능을 더 늘려서 새로운 인터페이스를 만든다. 그 새로이 추가된 인터페이스에서 확장성을 구현한다.

즉 새로운 기능을 하나 만들어서, 기존 있던 기능을 확장을 위해 고쳐서 사이드이펙트를 만드는 상황을 줄인다.

