마지막 수업............

• 웹을 먼저 만든다.
• 반응형 웹 PWA(프로그레시브 웹,앱)
• WebRTC, WebGL(VR, AR), App, AI
• 태블릿 버전
• 모바일 (안드로이드, ios)

실무형 알고리즘

• 검색
• 날짜
• 체크박스
  

firebase 응용

• Object 기능들
  
• 배열을 객체로 만들기
  

gitflow

• 개발 할 때에는 develop이라는 브랜치를 이용
• 개발이 완료된 후 배포를 위해 다른 브랜치를 하나 더 생성
• 브랜치 이동 하는 방법 git checkout -b develop --> 이렇게 하면 없는 브랜치를 만들어서 이동시켜준다. 여기서 변경을 해도 마스터는 변경되지 않는다.
• develop에서 개발을 다 하고 master로 merge(합치는 작업)한다.
• merge 한 후에 master브랜치를 초록색으로 만든 후(checkout) yarn start한다.
• 분산 작업 할때 develop 에서 만들지 않는다.
• 각자 피쳐 브랜치를 만들고 난 뒤 develop 으로 합친다.
• 다 만든 후 develop에서 더 이상 기능 추가는 없고 버그가 있는지 확인 버그가 다 잡히면 master브랜치로 옮기고 배포 시작. 버그를 잡기 위해서 만드는 브랜치는 release
• release에서는 버그만 잡는다. 버그를 더 이상 잡을게 없다 할 때 마스터로 merge
• 배포하고 난 뒤 미쳐 잡지 못한 버그가 있을 때, hotfixes란 브랜치를 만들어 버그를 잡은 뒤 다시 마스터로 merge

• master브랜치에 초기 보일러 플레이트를 세팅해놓는다.
• master에 있는 걸 그대로 develop으로 카피 한다.
• 개개인의 push를 막아 놓는다.
• master브랜치에서 포크를 해서 가져온다.
• 각자가 자기 레퍼지토리에 있는 걸 git clone 한다.
• 같은 걸 개발 하면 충돌이 일어난다.
• 개발을 한 후 각자 계정을 git push를 한다.
• develop 권한이 있는 사람에게 pull request 해달라고 얘기한다. pr 날린다 라고 한다.
• 코드를 본 후 develop에 merge를 하게 된다.
• 원본에 있는 걸 다운로드 한다. 이때는 원본(upstream)을 다이렉트로 받는다.

---------------------------주의 사항--------------------------

• 같은 기능을 두 명 이상 개발 하면 안된다.
• 하루에 두 번 이상 pr을 날릴 때 각 pr이 의존하면 안된다.
• 가급적 1일 1 commit하기 or pr(pull request).
• 공통 기능(로그인, 회원가입)잘 만들어야 한다. 공통 컴포넌트 연차가 있는 사람이 많이 담당을 한다.

취업

• 과제가 오면 기능 구현은 당연한거다. 얼마나 잘 만들었냐가 문제이다.
• 잘 만들었다는 기준!!
  1 . 반응형 디자인은 기본! (조건이 없어도 해야한다.)
  2 . UI가 절반은 먹고 들어간다. (최대한 신경 쓰기)
  3 . 모든 기능 구현하기 (유저 편의성 추가 구현)
  4 . 컴포넌트 재사용성 높이기
  5 . 타입스크립트
  6 . useCallback 적용하기
  7 . SSR 적용해서 배포하기 (상품상세 페이지, 상품에 따라서 어떻게 했다고 적어서 같이 보내기)
  8 . 과제를 위한 도메인을 구매해서 배포를 해서 넘겨주기!
  9 . 프로젝트 핵심 유저플로우 gif로 만들기!
  10 . 이력서 팀 프로젝트 다 만들고 지원하기 or 만들면서 지원하기
  11 . 경력 2~3년 차 위주로 지원하기

Closing OT

• 팀프로젝트 협업 능력 다지기
  1 . git협업 능력
  2 . 빠른 기술 습득 능력
  3 . 검색 능력 (에러가 났을 때 에러가 난 그대로 복붙)
  4 . 공식문서 리딩 능력
  5 . 집요하게 해결하는 능력(2~3일 일주일 이상 걸려도 해결하려는 끈기)

• 이력서 및 포토폴리오 작성하기

• 코드 한 줄 한 줄 , 변수명 하나 하나, 기술 스택 하나 하나,