현명한 소의 기록장

1. Meaning of 'dollar sign'($) and 'underscore'( _ ) in JS

a. dollar sign( $ )

• 특정 함수로의 shortcut을 의미
  • 보통, document.getElementById()를 가르킴
    e.g., $("div-id") === document.getElementById("div-id")
• 변수 앞에 붙이면, 보통 jquery 객체를 의미함

b. underscore( _ )

• class member 중, private member를 의미

https://www.thoughtco.com/and-in-javascript-2037515

1. Currying으로 onClick handler 함수 깔끔하게 작성하기

Currying이란, 여러개의 인자를 받는 함수를, 하나의 인자만 받는 함수의 연속으로 바꾸는 것

// Original function
function multiply(x,y,z) {
  return x * y * z
}
console.log(multiply(1,2,3))

// Curried version
function multiply(x) {
    return (y) => {
        return (z) => {
            return x * y * z
        }
    }
}
console.log(multiply(1)(2)(3))

In React

import * as React from "react";

const TestComponent: React.FunctionComponent = (props) => {
  const myList: any[] = [];

  const onClickItem = (item: any) => {
    console.log("Item: ", item);
  };
  
  const curriedOnClickItem = (item: any) => () => {
    console.log("Item: ", item);
  }

  return (
    <div>
      {myList.map((item) => (
        <div>
          <button onClick={() => onClickItem(item)}>My Button</button>
          <button onClick={curriedOnClickItem(item)}>My Button</button>
        </div>
      ))}
    </div>
  );
};

export default TestComponent;

1. Generic Component

• generic은 코드를 clean & 확장엔 열려있고, (코드의)수정엔 닫혀있게 도와 줌
• <T extends unknown> → T는 any type임을 명시

https://medium.com/@mathiassilva4/make-your-react-component-generic-with-typescript-497378515667

TODO

• 벨로퍼트와 함께하는 리액트 테스팅 실습해보기!
• Directory 구조 적용

리팩토링 기준

• 영향도 & 효용도

styling

• emotion.js 사용

Testing

• react-testing-lib 사용 중

Directory 구조

• src
  • assets
  • base
  • comonents
    • 사용되는 domain을 기준으로 나뉘어짐. 2개 이상의 domain에서 사용 → common으로 분류
    • 예시 - 아래 구조 참고! 

      

      • index.ts에 business 관련 logic들을 넣을 수도 있음
      • component에는 UI 로직 위주!
  •  features
    • redux-toolkit 등
  • hooks
    • 공통 custom hook
  • models
    • api 요청 관련
  • pages
  • server
  • services
    • api 요청 관련
  • tests
  • types
  • utils

Unit Testing에 대한 오해와 사실

• Unit testing은 버그를 고치기 위한 것이 아니다
• Unit testing은 더 나은 설계를 위한 design tool이다
  • 잘 설계된 unit test는 정교한 설계를 도와준다
  • 만약 unit test가 어렵다면, code가 잘못된 것이다

언제 Redux를 쓸까

Redux가 필요할 때

1. Redux 방식이 편하고 좋다고 생각할 때

2. 비동기 작업에 대해 많은 컨트롤이 필요할 때(단순 fetch는 react-query 등 사용 가능)

3. next.js를 사용하지 않고 서버사이드 렌더링을 해야할 때

4. Testing을 해야할 때

5. 컴포넌트가 아닌 곳에서 global state를 사용하거나 업데이트 해야할 때

...

Redux 대체제

Context API

- context를 수단으로 useState / useReducer를 사용하여 global state 관리

- 성능 최적화가 이뤄지지 않았음. 특정 컴포넌트가 사용하지 않는 global state가 업데이트 되어도 리렌더링 발생
  (redux는 최적화가 되어 있음)

- 위의 이유 때문에 관심사 분리가 매우 중요

- 따라서 global state가 다양해지는 경우, Context의 사용은 적합하지 않을 수 있음

Constate

- 위와 같은 Context API의 한계를 보완한 Library

- Context를 기반으로 작동하기에 Context API에서 추가로 배울 것이 따로 없음

Recoil

- Context API의 한계를 극복하고자 facebook에서 만든 전역상태 관리 Lib

- 현재 experimental 단계이지만 현업에서도 사용 가능

Selector는 아래와 같은 상황에 유용

1. state의 데이터 구조가 변경될 때

2. 컴포넌트 리렌더링 최적화를 할 때

Presentational & Container 컴포넌트는 이제 그만!

대신, 공통된 로직은 Custom Hook을 만들어 상태 관련 로직과 view를 분리하자!

간단한 API 요청은 react-query

- redux-saga 등을 쓰면 요청 시작 / 성공 / 실패에 대한 3가지 액션과 각 액션을 처리하는 로직을 따로 직접 관리해줘야 함

- 하지만 react-query를 쓰면 간단히 처리할 수 있음

그럼에도, 아래와 같은 상황에서는 redux middleware(redux-saga 등)가 필요하다

1. 요청을 연달아 여러번 했을 때, 이전 요청은 무시하고 맨 마지막 요청만 처리하도록 할 때

2. 특정 조건이 만족됐을 때 이전에 시작한 요청을 취소하는 상황

3. 특정 콜백함수를 원하는 액션이 디스패치 됐을 때 호출하도록 등록하는 상황

4. 컴포넌트 밖에서 어떤 작업을 수행할 때

테스트 코드 작성을 잘 하자

느낀 점

• 나중에 recoil 등이 더 발전하면 굳이 redux를 안써도 될 때가 오겠다
• selector를 적극 사용하자
• custom hook을 만들어 적용해보자
• react-query도 간단한 요청에는 사용해봐야겠다
• 현재 내가 수정한 부분이 자잘한 에러를 일으켜 골치아픈데, 테스트 코드 도입으로 해결 가능한지 검토해봐야겠다

오늘의 개발자 4주차 주제 - 개발자의 생애주기에 맞는 준비

[ 취업 준비 시기 ]

A. 사고방식을 바꾸는 효율적인 학습 방법

수단: 부트캠프, 책, 독학...

방법: ??

중요한 것은 학습 방법을 수집하고 끝내는 것이 아니라, 적용하는 것!!

나는 지나치게 정보를 수집만 한다

"가처분 시간"을 공부에 올인하는 것이 우선! 공부에 전념하는 시간을 확보하는 것이 첫 걸음이다.

강사 분은 개발 학원을 다니면서 잠을 3~4시간 잠ㅜ 자고 먹는 시간 말고 다 공부

두 가지 방법

1. Should. 해보면 좋을 방법

2. Have to. 반드시, 꼭 해야 하는 방법

수단은 점( . ) / 방법은 방향( → )

1. Should

⇒ 가던 방향이 아닌, 반대 방향으로 가보기

현재 방향이 효율적이라 생각하더라도, 반대로 해보기!

•  예시
  • 모르는게 나오면 못넘어가는 사람 vs 모르는게 나와도 일단 넘어가는 사람
  • Why가 중요한 사람 vs How가 중요한 사람
  • 숲을 먼저 보는 사람 vs 나무를 먼저 보는 사람
  • 기출문제부터 풀어보는 사람 vs 기본서부터 보는 사람
• 둘 중에 나은 것은 없다. 서로 다른 방향에 도전해볼 것

정현우: 모르는게 나오면 일단 넘어감 / How가 중요함 / 숲을 먼저 봄 / 기출문제부터 풀어봄

2. Have to

⇒ 지식의 "소비"보다, 지식의 "생산"을 먼저, 많이 해야만 한다

지식의 소비와 생산을 구분하여 학습할 것!

학습의 두 방향

- input. 지식의 소비. 

- output. 지식의 생산. 따라치는 것이 아니라, 적극적이고 능동적인 정보의 출력

나는 소비적인 활동을 너무나도 많이 한다. 특정 시간, 기간 동안에는 소비를 멈추고 생산을 하자

진정한 클론코딩은, 강사의 코드를 따라치는 것이 아니라, 서비스의 아이디어, 기능을 클론하여 나만의 코드로 구현하는 것이다.

사고 방식을 바꾸는 방법

• TDD
• 아마존의 Working Backwords(거꾸로 일하기)
  • 아마존은 새로운 프로젝트 전에, 그 프로젝트 이후에 뿌릴 보도자료(목표)부터 먼저 만듦
  • 그 이후, 보도자료 내용에 맞게 구현
  • 이력서에 적용하자면, 학습을 시작하기 전에, 내가 되고 싶은 내년 모습을 기준으로 해 이력서를 먼저 작성
    (강사님은 31살에 국비지원 등록함. 목표 = 3년 내에 네이버 들어가기로 세움. 네이버에 충분히 갈만한 목표를 잡고 남은 시간은 올인)

내 목표: 31살에 지난 개발 경력 인정 받고 토스/카카오 프론트 개발자로 입사
수정 → 31살에 백엔드 개발자로 당근/네카쿠라배 중 한 회사에 입사

B. 어떤 회사를 선택할 것인가?

어떤 회사가 좋은 회사인가?

좋은 회사의 기준?

• 예시
  • 체계가 있는 회사 vs 체계가 없는 회사
  • 성장 할 수 있는 회사 vs 성장과 별 상관없는 회사
• 각각의 장단점과 상황이 다른 것 뿐

좋은 회사라는 것보다 더 중요한 것은, 나의 성향, 나의 욕망에 대해 아는 것!

• 능동적으로 일하는 스타일 vs 수동적으로 일하는 스타일
• 체계가 있는게 좋은지 vs 체계가 없는지
• 일을 할 때 why가 중요한지 vs 그렇지 않은지
• 실력에 따른 연봉 vs 경력에 따른 연봉
• 개발의 퀄리티 vs 지금 잘 동작하는 걸로 충분
• 다른 직군이 하는 일에 대한 관심 vs 내가 맡은 것만 잘하면 됨

정현우: 능동적 / 체계 있는게 좋음 / why가 중요함 / 실력에 따른 연봉 / 개발의 퀄리티가 중요 / 다른 직군에 완전 관심

웹을 하는 개발자는 크게 회사의 것을 만드는 회사(서비스 회사) or 남의 것을 만드는 회사(SI/SM 에이전시) 두 종류의 회사에 갈 수 있다

자신의 성향에 대해 깊게 고민해보고, 그에 맞게 회사를 선택하라

근데 좋은 개발자가 되고 싶다면 서비스 회사를 가라

서류 제출 단계에서 떨어지는 이유

• 이력서인가 전단지인가?
  • 템플릿 만들어놓고 모든 회사에 다 찔러넣고 있는가?
  • 이력서, 자소서는 러브레터여야 한다
• 당신만의 전략이 있는가?
• "운"도 중요
• 신입의 이력서에 필요한 것은 실력보다 매력
  • 성장 가능성, 매력을 더 많이 봄.

10번 정도 면접을 보고자 10군데 넣었지만, 한군데만 면접 연락이 왔다면 취해야 하는 행동은?

1. 90번을 더 넣는다 → 소중한 기회의 90%를 날리기로 결정한 것이나 마찬가지

2. 확률을 올린다 → 선택과 집중

면접에서 약점(=이력서에서 이미 드러난)을 기회로 만드는 방법

채용 프로세스에서

- 지원자를 다음 단계로 보내지 않기 위해 하는 절차 → 코딩 테스트, 사전과제, 폰인터뷰

- 지원자를 다음 단계로 보내기 위해 하는 절차 → 면접

흔히들 이력서에서 약점이라고 생각하는 것 = 학력 / 비전공 / 나이 / 스펙 ( 모두 강사님의 약점이었음 )

하지만, 면접 단계에 왔다는 것 자체가 이런 것들이 결격사유가 아님을 방증

예를들어 면졉관이 많은 나이에 대해 언급하면, 당신은 나이가 많지만 그만큼 다른 장점이 많다 받아치면 됨. 보다 적극적으로 장점을 어필하라

면접에서 떨어진다면, 약점 때문이 아니라 장점 때문이다

나의 장점: 자기 주도적이다. 커뮤니케이션에 능하다. 3년 간의 조직 운영 경험이 있다. 문제를 조작적으로 정의하는 것에 능하다(희망)
+ 이거 말고, 개발 직군에 적합한 장점 리스트를 정리해보자

마지막으로 하고 싶은말 있으면 해보세요에 대한 팁

마지막 하고 싶은 말 있으세요? = 내가 듣고 싶은 말을 해보세요

• 면접관이 듣고 싶은 말이란
  • 면접관이 어떤 스타일인지 파악해야 함
    • 면접관은 겸손한/패기 있는 사람을 좋아하나? how / why 중 무엇을 우선시하나?

면접은 최대한 많이 보는게 좋은가? → NO

• "좋은" 면접을 많이 봐야 한다
  • "좋은" 면접에서의 경험만이 성장에 도움이 됨
• 어차피 떨어질텐데 봐서 뭐해.. 라는 생각이 드는 면접이 좋은 면접!

[ 취업 후 ] 

A. 취업을 하고 나서의 Attitude

취준생에서 직장인이 되면 입장이 완전히 바뀐다

- 개인 평가에서 개인, 팀, 조직 평가로

- 경쟁자에서 팀으로

입장이 바뀌었는데, 학생의 마인드를 유지하면 문제가 생긴다

돈을 쓰는 입장이 취해야 할 태도 → 돈을 더 아껴쓰는 방향

돈을 버는 입장이 취해야 할 태도 → 돈을 더 버는 방향

취업을 해 돈을 더 버는 입장으로 바꼈는데, 여전히 돈을 아껴쓰는 방향으로만 고민을 하면, 열심히 살아도 삶이 나아지지 않고 계속 고달픔

직장인의 기본 자세 → 남에게 피해주지 않으려면 일을 잘해야 한다

학생일 때는 내가 못하면 나 혼자 피해를 보지만, 직장인일 때는 내가 일을 못하면 타인이 피해를 본다

그렇다고 일을 못하는 사람을 욕하는 것은 옳지 않다. 우리는 깐부니까...

면접 때도 협업에 능한 사람인가 엄청 많이 봄.

IT 바닥 정말 좁다...

- 몰래 면접 일정 잡았는데 기존 회사 사람들이 알고 있다던지...

실력의 속도 & 경력의 속도

- 꾸준한 실력 단련으로, 경력의 실력을 앞지를 수 있다

- 흐르는 시간의 속도에 비해 실력의 속도가 떨어질 수록, 이직이 되려 힘들어진다

B. 연봉과 이직

연봉 협상은 퇴사빵이다!

- 보통 연봉은 통보받음. 그 통보를 인정할 것인가?

- 인정 못할 때 연봉 협상

- 모든 협상은 결렬될 가능성을 내포

- 결렬은 입사 포기 또는 퇴사...

- 다른 회사에 합격해놓는게 거의 유일한 협상 시도 방법

일년에 연봉 3번 올리는 방법

가격을 결정하는 변수 with 가중치

• 원가 * → 노력
• 품질 ** → 실력
• 언제 *** → 언제
• 어디서 **** → 어디서

실력이 좋아도 연봉이 안따라올 수 있음

연봉협상에 중요한 것은 "언제 & 어디서"!

준비된 사람만이 기회를 잡을 수 있다.

[언제] 이직하는 시점을 잡는 기준

- 나의 상태(경력, 포트폴리오 등)이 기준이 되면 안됨

- 회사의 인사평가 기간을 기준으로 해야 함!

- 인사평가 기간을 무시하고 이직하면, 연봉 상승을 못누릴 가능성 농후

좋은 개발자가 되고 싶다면, SI/SM을 하루라도 빨리 벗어나야 하는 이유

• 좋은 개발자와 함께 하는게 좋은 개발자가 되는 유일한 길
• 좋은 개발자가 향하는 길에 SI/SM은 없다
• 좋은 주니어가 먼저 되어야 좋은 시니어가 될 수 있다
• 시작이 어떻더라도, 서비스 회사로 가는 것을 추천한다

[ Q & A ] 

Q. 쿠팡에서의 프론트엔드 tasks들은?

A. Server에 요청을 보내는 Front Server에 기여. 각 Front 팀이 무슨 일을 하는지 최대한 구체적으로 알 수록 좋다
(Front server에 대해 알아보자)

Q. 개발과 관련 없는 경력을 넣는게 좋은가?

A. 회사 마다 다르다. 회사의 도메인과 관련이 있다면 좋을 수 있음

Q. 이전 회사의 짧은 경력(4개월 정도)을 이력서에 넣는게 좋은가?

A. 회사마다 다르다. 넣는다면 분명 물어볼 것. 좋다 나쁘다 말하기 어려움. 장점으로 어필할 수 있다면 넣는게 좋을 듯

Q. 토이 프로젝트를 할 때, 백엔드를 어디까지 하는게 좋을까?

A. 프론트 개발자라도, Backend의 CRUD 정도는 기본으로 할 줄 알아야 한다. 숲을 이해하는 정도면 충분. 단순 백엔드를 했다는 쪽으로 어필하는 것은 무의미

Q. 프론트 공부할 때, 오픈 소스, 프로젝트를 까보면서 공부하고 싶은데 혹시 해보셨나? 했다면 무엇을?

A. 안해봤음. 상용 코드와 오픈소스 코드는 지향하는 바가 달라, 큰 도움이 안될 수 있음. 일 할 때 sdk를 만들어야 해서, 다른 sdk를 까본 적은 있음. 남들이 한다 해서 오픈소스 보는게 아니고, 달성코자 하는 목적이 분명할 때 오픈소스를 보는게 좋다.

Q. 신입 프론트 개발자로 9개월 째 사수 없이 일하고 있음. 사수가 있는 곳으로 이직하면 보다 빨리 성장할 수 있을지 궁금함

A. "좋은" 사수만이 의미 있다. 있다고 다 좋은게 아님. 사수가 없어도, 다른 분야의 개발자와 커뮤니케이션 하며 성장할 수 있음. 

Q. 블로그 같은 걸 작성하시는지 궁금함. 기록 정리하는 것과 개발의 시간 분배를 어떻게 관리하는지 궁금함

A. 개발 블로그 도전해봤지만 결국 못했음. 본인은 말로 정보를 인출하는 쪽을 선택함. 블로그는 정보 인출의 한 형태일 뿐임. 다른 형태의 정보 인출 방법도 시도해볼 것을 추천함

Q. 이직을 위해 기술면접 대비 공부 중임. 하지만 프론트 개발 지식이 너무 방대해 무엇부터 준비해야 하는지 고민임.

A. Working Backward 방법을 추천함. 목표로 하는 회사를 설정하고, 그 회사가 요구하는 스펙에 맞게 준비.

Q. 신입이라 협업 경험이 적음.

A. 개발적인 내용보다는, 협업 스타일이 궁금한 것. 개발과 관련이 없더라도, 협업에 대한 자신의 가치관과 경험을 말해줘도 됨. 아님 커뮤니티에서 실제 협업해보는 것도 추천

Q. 프론트 개발자에게 중요한 것은 예쁜 UI? 깔끔한 코드?

A. 프론트라도, 좋은 개발자의 본질은 "문제 해결"이라 생각한다. 상황과 서비스마다 다를 것. 우아한 개발자 CTO님 인터뷰 꼭 참고해볼 것

출처 - 모두 꼭 직접 자주 읽어볼 것!

https://speakerdeck.com/jaeyeophan/mentoseuwa-inteonkolra

https://speakerdeck.com/jaeyeophan/miri-alassdamyeon-johasseul-geosdeul

https://speakerdeck.com/jaeyeophan/junieo-gaebaljayi-seongjange-daehaeseo

"이유와 목적"이 있는 개발

지금까지 냅다 버젼 올리고, data flow 무조건 통일시키려 했다. 물론 이것도 해두면 좋은 작업이긴 하다.

하지만 모든 일에는 시간이라는 자원이 소모되기에, 일의 우선순위를 꼼꼼히 따져보는 것이 매우 중요하다.

리팩토링이 가장 필요한 부분은, 리팩토링을 해서 실제 "효용"이 큰 곳이여야만 한다. 과연 위 두 작업을 한다고 실제로 효용이 증가했을까? 아닌 것 같다.

리팩토링 시 가장 효용이 있을 것 같은 부분

- redux-toolkit 도입 - 스터디 진행?

- TypeScript 스터디 진행

- 추후 컴포넌트 생성 시, "변경에 유연하게" 만들기

- 많이 사용되는 컴포넌트 순으로 rendering 최적화

- (후순위) material-ui v 5 migration

고민

- "나 혼자" 필요하다 생각하는 내용 말고, 현재 "FE 팀"이 문제로 인식하고 있는 것들은 무엇일까?

- 그 중에서 내가 빠르게 작업할 수 있고, 그 결과로 큰 효용을 얻을 수 있는 작업은 무엇일까?

0.0.0.0 vs 127.0.0.1(localhost)

0.0.0.0으로 요청 보내니, 아래와 같은 CORS에러가 뜨고, localhost ip에서는 CORS 에러가 안뜨는 현상 발생!

먼저, CORS에 대해 알아보자

CORS에 대한 설명

설명 1 - 희창 정리

설명 2 - 설명 with img

설명 3 - MDN CORS 설명 문서

0.0.0.0 vs localhost

https://velog.io/@gwak2837/127.0.0.1localhost-vs-0.0.0.0

forEach는 break가 불가능하다

함수형 프로그래밍은 함수의 네이밍과 실제 그 작동이 중요하기 때문에 그런 듯...

forEach → 모든 element 탐색할 것을 기대

+ forEach는 promise도 안기다림

공식 MDN 문서에서도 break가 필요하면 다른 방법을 쓸 것을 권장함

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach