CodeCamp 38일차

→ 슬리드로 보기

---

앞으로의 프론트엔드 => Frontend

전체적인 스타트업의 개발 그림

웹서비스와 앱서비스(안드로이드,IOS) 프론트앤드만해도 개발자가 너무 많이 필요하기 때문에

웹사이트를 우선 만들고 모바일웹(크롬브라우저를 켜고 그 안에서 웹을 구동한다. 반응형 웹)을 만든다.

ReactNative에 webview를 활용하여 브라우저를 띄워주게되면 GooglePlay,AppStore 배포가 가능해진다.

ReactNative가 NavtiveBridge을 이용하여 안드로이드,IOS 코드로 변환시켜주는 과정이 있기 때문에 성능이 조금 느리다.서비스 규모가 점점 커지게되면 어쩔수없이 안드로이드,IOS 팀을 만들어야한다.

웹과 모바일의 가장 큰 차이점은 웹은 주소라는 것을 가지고 있고 입력하면 바로 들어가진다. 앱은 다운로드 받아야하기 때문에 마케팅비용과 유저의 접근성 측면에서 모바일과는 다른 큰 장점이 있다.

웹으로 할 수 있는 다양한 것들

3D 그래픽 , VR, AR 또한 webGL을 사용하여 구현 가능하다.

머신러닝, 인공지능의 경우 순서가 front => back => db(빅데이터전문가) => 머신러닝전문가 이렇게 되는데 머신러닝 학습결과를 90%만 채워넣고 프론트에서 유저정보를 받아 다시 추가학습으로 10%를 채우는게 추세이다.

HTML의 webRTC 기능이 추가되어 녹음 및 영상 촬영 기능 모두 활용이 가능하여 웹과 앱의 간격이 사라지고 있는 추세이다.

그래서 요즘 완성되진 않았지만 계속 추진되는 것이 PWA이다. serviceworker라는 javascript 파일로 모바일웹을 만든 후 PWA(serviceWorker.js)를 활용하여 설치없이

1. 유저의 핸드폰에 로고 및 아이콘을 만들고

2. push알림 및

3. 배포까지 가능하다. 배포의 경우 IOS에서는 차단하고 안드로이드에서는 배포가 가능하다.

4. 브라우저 오프라인모드

추가적으로 공부하면 좋을것들

• 실무형 알고리즘

‏‏‎ ‎

• React와 FireBase

Object 기능들

배열을 객체로 만들기

‏‏‎ ‎

서비스 안정성 높이기 => isSubmitting

등록하기를 여러번 누르면 query가 마구마구 날아가기 때문에 한번만 누르게 해줘야하는데

과거에는 useState(false)를 만들어서 한번누르면 눌러지지않게 동작구현을 했었다.

‏‏‎ ‎

sentry => error가 났을때 어디서 어떤 에러가 났는지 자세하게 알려주고 slack이랑 연결하여 에러를 수집할 수 있다.

git으로 협업하기 => Gitflow-Workflow

기존에는 master branch에 push했었음

master 가로에 여러가지 branch들이 있음

앞으로 개발은 develop branch에서 개발을 하게된다. git checkout -b develop develop branch로 이동하기

develop branch에서 한번 더 들어가서 feture branch(기능별로) 기능 브랜치를 나눠서 개발한다.

기능별로 개발된것들을 develop에다가 합친다. 누군가 만든 branch 기능에 문제가 생기면 합치기 전에 그 기능에 한하여 거부할 수 있다.

배포하기 전에 develop을 master에 합쳐주고 배포는 최종적으로 다 합쳐진 master 하게 된다. 그런데 이렇게 합치게되면 버그가 쏟아지는 문제가 발생할 수도 있다.

이를 위해 master에 가기전에 release branch를 한번 거친다. 배포 전에 release branch에서 합치면서 생긴 버그들을 확인하고 수정하여 완벽해졌을때 master branch로 합치게 된다. release branch에서는 기능을 추가하지 않고 버그만 잡는것이다.

master branch에서 배포를하고 release에서 버그를 다 잡았다 생각했는데 배포상황에서 버그가 또 발생하게 된다면 hotfixes brach에서 바로 수정할 수 있다. git checkout -b hotfiexes 이 명령어를칠때 위치가 master branch여야 한다.

매우 중요!!!!어디서 checkout 명령을 쳤는냐에 따라서 default 폴더들이 checkout 명령을 친 폴더들이다.!!

‏‏‎ ‎

레포지토리 만드는 구조 방식

포킹레포지토리 :

회사계정으로 레포지토리 생성 =>

각자 vscode에서 직접 회사레포지토리에 push pull 하는게 아니라, 각자 깃허브 레포지토리에 회사레포지토리를 fork해온다. =>

각자 포크한 자기 레포지토리에서 vscode로 clone을 해온다. =>

각자 게시판,상품등록,결제하기 기능을 feature 브랜치에서 기능을 만들고 난 후(feature-boardwrite...) 각자 레포지토리에 push를 한다.=>

회사레포지토리에 올릴때 회사레포지토리 권한 있는 사람한테 pull request(PR)를 한다. =>

팀장은 기능구현이 잘되지 않은 PR만 빼고 merge한다. =>

각자 자기 자리에 돌아가서 회사레포지토리에서 pull upsteram develop해오고 업데이트 된 develop branch에서 다시 feature branch를 만든다.

이름이 없으면 헷갈리기 때문에 레포지토리에 이름을 전부 붙여준다(회사레포지토리 upstream, 각자레포지토리 origin) 그에 따라 명령어도 바뀜 git pull upstream develop, git push origin...

‏‏‎ ‎

!!!!주의사항!!!!

1 . 철수가 게시판등록,영희가 게시판 수정과 같이 겹치는 폴더를 개발하여 upstream 레포지토리에서 합치려고하면 충돌이 일어남. 아예 서로 다른 기능을 구현해야한다.

2. 로그인과같은 겹치는 기능이 있을 수 밖에 없는데 잘하는 사람이 공통모듈을 만들어 develop에 merge를 한다.(내부에서 사용하는 모듈) 공통모듈이 잘못되면 다른 기능들에 영향이 가기 때문에 작업이 다같이 중단될 수 있다.

3. 게시판 등록을 너무 빨리 끝내 pr날리고 merge가 되기 전에 수정 branch를 만들면 문제가 될 수 있다

시간이 남으면 아예 게시판등록+수정까지 합쳐서 pr날리거나 앞에서 만들었던 기능들과 상관없는 기능들을 만들어야한다.

‏‏‎ ‎

팀장이 기본 베이스 폴더를 만들어놓음 !공통모듈!(보일러플레이트)을 만들어 푸시를 해놓음

upstream 레포지토리를 각자 git에 fork 해옴

자신 vscode에 fork해온 레포지토리를 git clone

각자 upstream 레포지토리 issues에서 할일을 올려 놓는다.(ex 지라) #number로 fetaure branch를 만들어준다.

checkout -b는 브랜치 만들어서 이동하기 checkout은 그냥 이동하기

branch를 잘못 만든경우 메인으로 이동해서 다시 만들어야함

코드 작성이 끝나고 add , commit(커밋메시지는 커밋컨벤션 활용) , push origin feature-#Number로 자신의 레포지토리로 올려준다. push가 끝나면 내 레포지토리에 pull request 버튼이 초록색으로 활성화 되고 pr을 날려준다.

회사 레포지토리 권한자는 pull request를 merge 할 수 있는 권한이 있다. 합치게되면 소스코드 수정이 이루어짐 거절하고싶으면 close pull request를 하면 된다.

최상위 회사 레포지토리를 upstream + git 주소하여 upstream을 만들어주고 git pull upstream checkout main(develop) 해본다.

다시 main branch에서 checkout -b feature-#Number해서 다른 기능을 구현하고 위에 과정을 반복하면된다.

‏‏‎ ‎

취업준비 가이드

면접관들은

1. 반응형처리가 되어있는지 먼저 확인해봄(포트폴리오는 반응형이 좋음)

2. UI는 기본이고 후에 코드를 확인하러 들어감

3. 서류합격 후 과제를 받게 됨 => 모든 기능 구현(중요!!컴포넌트 재사용성,Typescript,useCallback!!)

4. 서버사이드렌더링(SSR),클라이언트사이드렌더링(CSR) 구분할 줄 아는가

5. 도메인 연결하기

6. gif

완벽한 포트폴리오

적당한 완벽 -> 다듬으면서 취업준비 -> 받은 과제를 포트폴리오로 만들면서 취업준비

스타트업에서는 경력자 선호 : 지원할 때 3년차 기준으로 지원

‏‏‎ ‎

팀프로젝트 협업능력 다지기

git 협업 능력

빠른 기술 습득 능력(기술 스택이 어느정도 쌓이고 더 좋은게 나오면 빠르게 교체하는 능력)

검색능력

DOCS 리딩능력

집요하게 해결하는 능력

git / 블로그 다듬기(최근에 쓴 블로그 2~3개)

‏‏‎ ‎

코드 한줄한줄

변수명 하나하나

기술스택 하나하나 모두 이유가 있어야한다.