원티드 12월 프론트엔드 챌린지 1차

원티드 프리온보딩 프론트엔드 챌린지 12월

 

비즈니스 로직 완전 정복 with React

- 강의 : 리맴버 오종택 강사님

- 역량 향상 세션 : 2주 커리큘럼

- 1차 : 12.5(화) 20시, 우리의 컴포넌트가 복잡해지는 원인

- 2차 : 12.9(토) 10시, 비즈니스 로직을 제압하는 개발자가 퇴근을 한다

- 3차 : 12.12(화) 20시, SOLID한 컴포넌트 만들기

- 4차: 12.16(토) 10시, Logic First, React Later

 

코스 시작 전 당부의 말씀

- 2주 동안 커리큘럼에 제시된 모든 것들을 '마스터' 한다고 생각하지 말자

- 키워드와 힌트를 얻어 간다.

- 책이나 강의 보다 내가 쓴 것만 기억난다. (계속 부딪치고 노력하자)

- 수업에서 들은 개념들을 면접에서 적용하기 힘들 수 있다.

- 강의 듣기가 아니라 직접 고민하는 시간이 바로 진정한 의미에서 챌린지이다.

- 지속 가능성을 위하여 절대로 재미를 잊지 말기!

 

핵심 타겟 수강생

- 첫 직장을 구하는 프론트엔드 구직 희망자

- 기술에 대해 깊이 생각해 볼 여력이 없었던 2년 이하 주니어 프론트엔드 개발자

 

진행 방식

- 우리가 가져야 할 기본 마음 가짐

- 가장 중요한 것은 '납득시키기'

- 공부 및 의견을 교환할 때는 가급적 뇌피셜 대신, 좋은 레퍼런스를 기반으로!
   (MDN, 공식문서, 오픈소스 - 코드, Issue, PR 등)

- 남의 코드(거의 다 비슷한 수준이기 때문에 더더욱)는 최고의 공부 자료

- 강의 종료 후 강의 내용 참고하여 다음 강의 전 까지 각자 과제 수행

 

수업 시작

- 모든 행복한 가정은 서로 닮았고, 불행한 가정은 제각각 나름으로 불행하다

- 퇴근을 못하는 이유? (react-query, useMemo, 렌더링 과정, Next.js 를 몰라서 퇴근 못해서가 아니다)

- 정해진 리소스 풀 내에서 그 좋음에 대해 지불할 수 있는 예산이 없으므로 그 유려함은 실상 존재하지 않는 것과 같다.

“개발자가 초인적인 노력을 기울이고, 잔업을 하며, 헌신함에도 불구하고 더 이상 진척이 없는 상황에 처하게 된다.
개발자의 노력은 기능 개발보다는 엉망이 된 상황에 대처하는 데 소모되기 시작한다. 심지어 사소한 기능을 추가하는 일도 그저 엉망이 된 코드를 이곳에서 저곳으로, 다시 다음 곳으로 이동하는 반복 작업으로 변질된다.
개발자들이 쏟은 노력의 가치가 결국 보잘 것없게 된다.” - 책, 클린 아키텍처, 9p

 

- 우리는 '일을 줄이는 일'에 대해서도 한번쯤 생각해봐야 한다.

빨리 가는 유일한 방법은 제대로 가는 것이다 - 로버트 C. 마틴

아키텍처는 종착지가 아니라 여정에 더 가까우며, 고정된 산출물이 아니라 계속된 탐구 과정에 더 가까움을 이해해야 좋은 아키텍처가 만들어진다. - 케블린 헤니

 

- ChatGPT가 있어도 월급을 받을 수 있는 이유. 동작에서 끝나는 것이나라 복잡도가 중요하다.

 

Todo list 요구사항에 따라 Pseudo 코드 또는 메모 작성해보기

요구사항 1) 할 일 목록을 보여주는 목록과, 할 일 추가 기능을 구현
사용자 입력을 받는 form 태그
할일이 추가될 때마다 li 태그가 하나씩 들어난다.
li 태그에 x 버튼을 누르면 할일이 없어진다.

요구사항 2) 할 일 상태에 따른 필터링 기능을 추가
완료 버튼을 누르면 li 태그가 색상이 변경되며 완료 됬음을 시각적으로 보여준다.

요구사항 3) 할 일 상태에 따른 필터링 기능을 추가
각각의 할 일에는 태그가 붙어 있어 할 일, 진행 중, 완료로 나뉘어 카테고리 별로 필터링이 가능하다.
마감 기한에 맞춰 정렬할 수 있는 필터링이 가능하다.

요구사항 4) 할 일 검색 기능을 추가
사용자의 입력을 받아 검색어와 일치하는 text가 있는 할 일만을 보여준다.
보여지는 할 일은 입력 검색어에 하이라이트가 쳐진다.

- 언제나 우리는 시간의 압박과 제한적인 정보 속에서 안정적인 기능을 만들어 나가야 한다.

- 중요한 사실은 리소스가 충분한 언젠가는 오지 않는다.

- 오지 않을 상황을 기다리는 것은 하지 않겠다는 의지의 표명이나 다름 없다.

- 도출된 ChatGPT 코드를 충분하다고 주장해도 좋고, 부족하다고 주장해도 된다. 중요한 건 이유이다.

- 왜 부족한지 그에 대한 이유를 설득력 댈 수 있는지를 이번 수업을 통해 생각해보면 좋겠다.

- 이미 복잡해진 코드를 수정하는 일의 비용(시장 기회, 개발자의 인건비 등)은 기하급수적으로 증가하고, 방치할 수록 많은 이자를 지불해야 하기 때문에 틈틈이 “일을 줄이는 일”을 해야 한다.

- 일을 줄이는 일이란, 빠르게 코드를 이해할 수 있는 코드 구조를 만들고,

- 하나의 수정 사항으로 인하여 다른 코드에 미치는 영향을 줄이는 것이다.

- 수정 사항을 줄이려면 수정의 이유와 시점이 서로 다른 코드들을 분리/격리하여 작성해야 한다.

- 그리고 이러한 목적을 달성하기 위한 여러가지 기법들을 활용할 준비가 되어 있어야 한다.

 

1) 데이터 / 계산 / 액션이 구분되어 보이나요? (1회차 강의)

2) 비지니스 로직이 구분되어 보이나요? (2회차 강의)

3. 부적절하게 조립된 컴포넌트가 보이나요? (3회차 강의)

 

추상화는 취향이 아니다, 오직 원칙과 협력 뿐

- 가능하다면 설계 초기부터 적극적으로 의견을 나누며 방향을 잡아야 한다.

- '개발에는 정답이 없다'고는 하지만 개발 분야의 핵심적인 원리들은 이미 다양한 수준과 분야에 걸쳐 잘 정립되어 있다. 오히려 그걸 얼마나 잘 이해하여 실무에 적용할 수 있는가 하는 하는 수준의 문제이다.

- SOLID, 클릭 아키텍처, 클린 코드, 리팩터링 서적에서 언급되는 기법들이 판단의 근거가 될 수 있다.

- 커뮤니케이션은 최선의 추상화 수단이다. 계속된 커뮤니케이션을 통해 모두가 납득할 수 있는 추상화를 수행한다.

 

데이터, 계산, 액션만 구분해도 중간은 간다

- 책 추천. 쏙쏙 들어오는 함수형 코딩

- 왜 함수를 나눠도 복잡함이 가시지 않을까

- 식(Expression)과 문(Statement)의 차이

 

순수 함수 / 부수 효과의 개념

- 입력 값에 대해 항상 동일한 출력값을 반환하며, 부수 효과가 없는 함수

- 부수 효과란 함수의 햄심 목적에서 벗아나 외부 세계에 영향을 주는 행위가 포함된 함수

- React 컴포넌트는 인자가 같다면 같은 return 이 보장하는 순수함수이다.

- useEffect는 React의 순수한 함수적인 세계에서 명령적인 세계로의 탈출구로 생각하라.

- 여기서 "순수한 세계"란 렌더링(Input → Output)을 뜻하고, 렌더링 이외에 일으켜야 하는 Side Effect를 일으킬 탈출구로 useEffect를 사용하라는 의미이다. useEffect는 Side Effect를 렌더링 이후에 발생 시킨다!

- API 성능을 개선하는게 렌더링 수를 개선하는 것보다 어플리케이션 성능 측면에서 낫다.

 

데이터/계산/액션의 구분

- 데이터 : 이벤트에 대한 사실. 문자열, 객체 등 단순한 값 그 자체

- 계산 : 입력으로 얻은 출력. 순수 함수, 수학 함수라고 부르기도 함 (ex. 최대값)

- 액션 : 외부 세계와 소통하므로 실행 시점과 횟수에 의존. 부수 효과를 일으킴

- console.log() 또한 액션이다. 이메일 보내기, 데이터베이스 읽기에 해당한다.

- 함수의 입장에서 외부세계와 react 상태를 바꾸는 것(setState)도 액션이다.

 

vitest 유닛 테스트를 추천한다.

 

setState 함수가 부수효과를 일으키는 함수인 이유

- Class형 컴포넌트의 상태 관리

- 함수 컴포넌트 자체는 JSX를 리턴하는 함수일 뿐이지만 setState 함수는 컴포넌트 외부에 존재하는 상태(React 내부에서 클로저를 활용하여 저장해두는 값)를 어떠한 요소(React) 컴포넌트를 다시 렌더링 하도록 기능한다.

 

함수 컴포넌트가 상태를 저장하는 방법 : 클로저(Closure)

- 함수 컴포넌트는 상태를 가질 수 없다.
- 함수는 실행이 끝나면 사용되었던 값들을 메모리에서 정리(Garbage Collection)하기 때문이다. 그래서 Hooks 등장 이전에 사용되었던 Container / Presenter 패턴에서는 상태나 로직을 갖는 요소들은 Class형 컴포넌트로 만들고, View를 담당하는 부분이나 파생 로직들에 대해서는 함수 컴포넌트로 만들었다.
- 함수 컴포넌트가 상태를 가질 수 있게 된 것은 React 16.8버전에서 Hooks가 등장한 이후의 일이다.

- React 16.8 이전 버전이라면 클래스형 컴포넌트를 만들고 클로저로 상태를 저장해서 구현해야 한다. 

 

과제 (필수 아님)

- 본인이 작성했던 코드 중에서 데이터 / 계산/ 액션을 분리해보고 느낀 점을 블로그에 정리하기

- 이번 챌린지 동안 과제는 대체로 글쓰기가 될 예정

- 중요한 취업 /이직 시 포트폴리오를 활용해 어려움, 고민과 성장의 흔적을 정리해서 보여주는 것이기 때문이다.

 

[아하! 모먼트 - 01] Redux와 React Query로 옵저버 패턴을 깨닫기까지

- 고도로 발전한 과학은 마법과 구분할 수 없다 (아서 C. 클라크)

- 상태관리를 위해서 Readux 대세 때는 redux-thunk, redux-saga, mobx의 삼파전이었다.

- 간단한 API로 된 라이브러리가 많이 나오게 되었다. recoil, 쥬스탄트

- flux 패턴의 redux

- React 코드를 뜯어 본다고 하면 GitHub에서 TenStack에서 하나하나 둘러보면 된다.

- Redux, React query는 옵저버 패턴이라는 디자인 패턴이었다.

- 마법은 없다. 마법 같은 과학이 있을 뿐

- 까보지 않으면 과학을 마법처럼(우와~) 대하는 엔지니어로 남게 된다. 부지런히 까보고 눈으로 확인(아하~)하자.

 

프리온도보딩 프론트엔드 챌린지 Repo. (링크)

- 사전과제 : 나를 힘들게 했던 로직에 대한 글쓰기 (링크)

- 과제레포 (링크)