오늘은 무엇을 했나요?

part1 피어리뷰

part1 한달 간의 여정이 끝이났다. 코드잇 부트캠프에서 처음 함께한 팀과의 이별이라니.. 같이 프로젝트 한번 못해봐서 너무나 아쉬웠다. (모두가 부러워한 케미였는데..(뇌피셜ㅋㅋ))

part1이 끝난 후, 팀 내 피어리뷰를 진행했다. 다른 피어에 대해 구글 설문에 좋았던 점, 개선해야할 점, 다음 파트에 도전했으면 좋을 점을 작성해서 제출했고, 이를 모아서 pdf 파일 형태로 받을 수 있었다.

처음으로 가장 가까웠던 팀원들의 평가를 받는 것이라 긴장 반 기대 반ㅋㅋㅋ

든든했다는 것과, 좋은 코드를 작성하기 위해 노력했던 점을 알아봐주셔서 너무 고마웠다😭😭
사실 처음에는 열정이 넘쳤고 점점 지쳐가는 나를 느끼고 있었는데(feat 컨디션 조절 실패) 이런 리뷰를 해주셔서 다시 열정을 되찾을 수 있었다!

• 개선 및 도전해볼 점
  
  리딩 경험을 쌓는 것은 매우 중요하다고 생각한다. 매우 유익한 조언! 또한, 데일리 스크럼을 하면서 사실 하루하루 개념을 쌓는데 급급했지 복기하는 것을 소홀히할 때가 많았는데, 다시 한번 인지를 하게 되었다!
  • part1 멤버들끼리 데일리스크럼때 진행하던 <안보고 랜덤문제 대답하기> 미니 세션을 스터디로 만들어서 진행하기로 했다! 이름하야 "🐍청계천드래곤 면스" 매일 30분씩 진행하기로 했고, 복기하는 데에 큰 도움이 될 것으로 기대된다.

매니저 데이지, 제이와의 면담을 하면서 피어리뷰도 보고 전반적인 지금까지의 형태를 보았을 때 가장 분위기가 좋은 팀이었던 것 같다는 평을 받았다! 너무 기뻤고, 아쉬움도 컸다ㅎㅎ..

다음에 넷이서 프로젝트를 하는 날이 오기를 바라며..(아님 우리끼리 사이드 플젝?ㅎㅎ)

part1, 재미있었습니다!😊

오늘의 나는 무엇을 새롭게 배웠나요?

[1] 기본 자료구조 - 해시 함수

Direct Access Table

• 배열의 인덱스를 key로 이용해 원하는 값을 O(1) 저장하고, 접근하여 가지고 오는 방식
  • 효율적으로 key-value를 가져올 수 있다.
• 자칫 공간을 과도하게 낭비할 수 있다.

#

해시 테이블

키(key)를 값(value)에 연결하여 하나의 키가 0 또는 1개의 값과 연관됨

• 즉 데이터를 저장할 위치= 인덱스
• 해시 버킷(hash bucket)이라는 배열로 구성됨
  • ex) key 42, value 에바, 5개의 버킷이 있을 경우 나머지연산(mod)를 사용해 42%5 = 버킷 2에 매핑함
    • 버킷 2(배열의 인덱스2)의 값에는 42, 에바 가 담김
    • 즉 한 인덱스에 키와 밸류 쌍을 저장함
    • 나머지 연산 등을 하는 것을 해쉬 함수라고 한다.
• 두개의 키가 동일한 버킷에 해시될 때 해시 충돌 (hash collision)
  • 각 버킷에 대해 키-값 쌍의 연결 리스트를 저장해 처리

해시테이블 정리

1. 고정된 크기의 배열을 만든다
2. 해시 함수를 이용해서 key를 원하는 범위의 자연수로 바꾼다.
3. 해쉬 함수 결과값 인덱스에 key-value 쌍을 저장하는 자료구조

해쉬 함수

특정 값을 원하는 범위의 자연수로 바꿔주는 함수

해시 함수의 조건들

• 한 해시 테이블의 해시함수는 결정론적이어야 된다. (즉 일관성 있는 결과가 나와야한다)
• 결과 해시값이 치우치지 않고 고르게 나온다
• 빨리 계산할 수 있어야한다.

1. 나누기 방법 (MOD 사용)

   • 자연수 key를 해시 테이블의 크기로 나눈 나머지를 리턴하는 함수

2. 곱셈 방법

   • 0 ≤ a ≤ 1 인 a를 결정한다,
   • a를 key에 곱한 후 정수부분을 버리고 소수 부분만 남긴다.
   • 소수 부분에 배열의 크기를 곱해준 후 소수점을 버리고 정수 부분을 남긴다. 이 정수가 해시값이 된다.

   → 항상 0보다는 크고 테이블 크기보다는 작은 해시값이 나온다.

파이썬의 hash 함수

내부 메서드가 있다. 파이썬의 해시 함수는 파라미터로 받은 값을 아무 정수로 바꿔주는 함수.

• hash("파이썬")
• 파이썬 hash 함수는 언어 자체적으로 불변 타입 자료형에만 함수 파라미터로 넘길 수 있다
  • 불린, 정수, 소수, 튜플, 문자열

해시 충돌

충돌은 서로 다른 데이터가 같은 해시값을 갖는 경우를 말하며, 충돌을 처리하는 방법에 따라 해시 함수의 성능이 결정된다.

1. Chaining

   배열 인덱스에 링크드 리스트 저장해서 충돌 해결

   • 탐색, 삽입, 삭제 모두 최악의 경우 O(n)
     • 평균 시간 복잡도로 따지면 O(1)
   • 삽입 시, 같은 키를 가지고 있는 노드를 찾으면 새로운 밸류로 변경함. 삭제 시, key를 이용해서 탐색 후 key-value 쌍을 삭제함.

2. Open Addressing

   • 충돌이 일어났을 때 다른 비어있는 인덱스를 찾아 저장하는 방법
   • 비어있는 인덱스를 찾는 방법?
     1. 선형 탐사(lindear probing)
        • 충돌이 일어났을 때 다음 인덱스로 이동하면서 비었는지 탐색
     2. 제곱 탐사 (Quadratic Probing)
        • 1의 제곱, 2의 제곱, 3의 제곱 …~~ 씩 이동하면서 비어있는지 탐색
   • 탐사를 하다 유의할 점
     • 탐색을 하다 비어있는 인덱스를 (최초로) 찾으면 key에 대한 데이터가 저장되지 않았다는 뜻! (왜냐면 저장된 데이터에 대해서는 최초에 빈 인덱스는 나올 수가 없기 때문)
     • 따라서 삭제를 할 경우, 단순 삭제를 하게 되면 문제가 생긴다!
       • 만약 해시값(=인덱스값)이 21로 나온 4개의 데이터가 선형 탐사 방식으로 저장되면 21, 22, 23, 24에 저장된다.
       • 이때 22인덱스에 해당하는 value를 삭제하고 아무런 표시를 해주지 않으면 다음에 23인덱스의 값이나, 24인덱스의 값을 탐색할 때 먼저 비어있는 22인덱스를 만나기 때문에 해당 값들이 없다고 판단된다.
       • 따라서 삭제된 데이터의 인덱스에는 DELELTED 등의 약속된 방법으로 저장해둔다.
   • 탐색, 삽입, 삭제 모두 최악의 경우 O(n)
     • 평균 시간 복잡도로 따지면 O(1)
     • load factor = 데이터 쌍수 / 해시테이블 크기
       • 탐사 연산의 기대시간은 기대값 : 1/ (1-load factor) 보다 작다.
         

[2] useState 뽀개기

비동기로 State를 변경할 때 주의할 점

setState 호출이 비동기적으로 처리되기 때문에, state 변수가 항상 최신 상태를 반영하지 않을 수 있다.

• React에서 useState hook은 state 값을 업데이트할 때 비동기적으로 업데이트한다.

WHY?

해당 코드가 실행될 때의 lexical environment에서 값을 참조하기 때문이다. 즉, 함수가 호출된 후에도 살아있는 변수를 확인할 수 있는 Closure의 특징을 이용한다.

JavaScript에서 함수의 실행 컨텍스트에는 해당 함수가 호출될 때 생성된 환경 정보가 포함된다. 이 환경 정보는 해당 함수에서 사용되는 변수들의 값을 저장한다.

const [count, setCount] = useState(0);

useEffect(() => {
  console.log(`The count is ${count}`);
}, [count]);

useEffect hook은 count가 변경될 때마다 실행됩니다. 그러나, count가 변경되는 동안 useEffect hook이 실행될 때 count 변수는 이전 lexical environment에서 참조된 값을 가지고 있습니다. 이는 useState hook이 setCount 함수를 비동기적으로 호출하기 때문에 발생합니다.

• setter함수에 값이 아니라 callback을 전달해서 해결 - 즉 콜백 함수형 업데이트를 사용해 해결할 수 있다.

함수형 업데이트

이전 상태값을 콜백 함수에 전달해 새로운 상태값을 반환하는 방법

if (options.offset === 0) {
      setItems(reviews);
    } else {
      setItems((prevItems) => [...prevItems, ...reviews]);
    }

• offset값이 0이 아닐 때 기존 items 배열과 새로 받아온 reviews배열을 합쳐서 새로운 배열을 만든 다음, 그 배열을 setItems를 함수를 통해 items state 값으로 설정한다.
  • 이때 setItmes 함수에 함수를 아규먼트로 전달하는데 (=즉 콜백) 이전 items 배열 값을 이용해서 새로운 items 배열을 만들어야할 경우 사용하는 방법이다.
  • 함수를 아규먼트로 전달하면 (콜백을 넣으면) React는 이전 items 배열의 값을 아규먼트로 전달하고, 새로운 state 값을 반환하는 함수를 실행한다.

왜 함수형 업데이트로 작성하면 이전 상태값을 전달하게 되는 거지?

• 추후 포스팅 예정

콜백으로 초기값 지정하기

const [state, setState] = useState(() => {
	return initialState;
});

처음 렌더링 할 때 한 번만 콜백을 실행해서 초깃값을 만들고, 이후 콜백을 실행하지 않는다.

• 주의할 점 : 콜백함수가 리턴할 때 까지 리액트가 렌더링을 하지 않고 기다린다.

Setter 함수 사용하기

배열이나 객체 같은 참조형은 반드시 새로운 값을 만들어서 전달해야 한다.

참조형 State 사용의 잘못된 예

const [state, setState] = useState({ count: 0 });

const handleAddClick = () => {
  state.count += 1; // 참조형 변수의 프로퍼티를 수정
  setState(state); // 참조형이기 때문에 변수의 값(레퍼런스)는 변하지 않음
}

참조형 State 사용의 올바른 예

const [state, setState] = useState({ count: 0 });

const handleAddClick = () => {
  setState({ ...state, count: state.count + 1 }); // 새로운 객체 생성
}

[3] React useEffect Hook의 Life Cycle와 Clean-up

공부하면서 어떤 어려움이 있었나요?

useState의 setter에 함수형 업데이트를 할 경우 왜 이전 상태값을 전달하게 되는 거지?

사실 이 내용은 내부 동작 원리에 대한 내용인 것 같다. 따라서 헨리(+케니)와 함께 약 4시간 동안😭 github 소스코드를 분석했지만 아직 정리가 완성이 안되었다.

간단하게 말하자면,
함수형 업데이트를 사용하면 이전 상태값을 인자로 받아서 새로운 상태값을 반환하는 함수를 전달하게 된다.

• 이전 상태값을 전달하는 이유는, React에서 상태값이 업데이트될 때 "동시성 이슈"를 방지하기 위해서!

React의 상태 업데이트는 비동기적으로 처리되기 때문에, setState() 함수가 호출되는 시점에 이미 이전 값이 새 값으로 업데이트된 경우가 있을 수 있다. 이 때문에 setState() 함수에 함수를 전달하여 이전 값을 인자로 받아와서 새 값으로 업데이트해야 한다.

예를 들어, 아래와 같은 코드에서 count 값이 0에서 1로 업데이트되는 상황을 가정해본다면,

setCount(count + 1);
setCount(count + 1);

이 코드는 count 값이 2가 아니라 1이 된다.. 왜냐하면 두번째 setCount() 함수가 호출될 때 count 값은 이미 1로 업데이트된 상태이기 때문이다.

하지만 함수형 업데이트를 사용하면 이러한 문제를 방지할 수 있다.

setCount(prevCount => prevCount + 1);
setCount(prevCount => prevCount + 1);

첫 번째 setCount() 함수가 호출될 때, 이전 값인 0이 prevCount 매개변수로 전달된다. 따라서 이전 값을 바탕으로 +1이 되어 count 값이 1이 된다. 두 번째 setCount() 함수가 호출될 때도 마찬가지로 이전 값 1이 prevCount 매개변수로 전달되어 count 값이 2가 된다.

즉, 함수형 업데이트를 사용하면 이전 값을 인자로 받아와서 안전하게 상태를 업데이트할 수 있다.

그래서 내부 동작에 어떤 차이가 있길래?

이 점이 궁금해서 삽질을 오래했다. 도저히 이해가 안됐는데, 케니의 설명에 힘을 받아 더 탐구해보고 드디어 이해했다! 이것은 state가 저장되는 Queue를 분석하면 알수 있었다. (github에 useState에 관련된 소스코드가 여기저기 흩어져있어서 힘들었다.. 공식문서에도 짧게 언급되어있긴 한듯?!)

추후 포스팅으로 정리해서 자세히 다뤄보고자 한다!

이전에 등록된 clean-up 함수라는 말이 뭐야?

이전에 등록된.. 이라는 말이 굉장이 생소했다. 도대체 어디서 등록이 되어서 기억하고 있다가, 다음 update때 실행이 되는거지?

그에 대해 탐구해본 결과(라고 쓰며 시간 갈아넣기라고 말한다)

그러니까, useEffect의 두 번째 인자로 전달된 dependency array에 따라, 이전 렌더링에서 등록된 clean-up 함수가 실행된다는 것이다. 즉, clean-up 함수는 현재 렌더링에서 실행된 useEffect 콜백 함수의 반환값을 기반으로 한다. 이전 렌더링에서 등록된 clean-up 함수는, 이전 렌더링에서 실행된 useEffect 콜백 함수의 반환값을 기반으로 하는 것이다.

그!러!니!까!
clean-up함수는 클로저인 것이다.
useEffect 내부에서 cleanup 함수를 정의하면 이 함수는 useEffect가 호출될 때의 렉시컬 환경에 대한 클로저를 가지게 된다. 그래서 cleanup 함수에서 이전 렌더링에서 생성된 리소스들을 제어할 수 있다.

결론적으로 useEffect 함수가 이전 렌더링에서 반환한 함수를 호출하는데, 이때 cleanup 함수는 이전 렌더링에서의 값들을 참조할 수 있다는 점에서 클로저 개념이 적용될 수 있는 것이다.

내일의 나는 무엇을 공부해야 할까요?

• 알고리즘 1강
• 함수형 업데이트에 관한 포스팅 올리기
• 피어 코드리뷰
• 리액트 데이터 다루기 완강!!