38일차

김혜진·2022년 5월 6일

Frontend

앞으로의 Frontend

앱과 웹의 간격이 거의 없어지고 있다.

실무형 알고리즘

자동으로 .이 붙게끔 만들어 주는 것, 년, 월을 지우면 자동으로 .이 사라지게 하는 것

전체 체크박스가 빠질 때와 빠지지 않는 경우의 수 만들기

객체를 배열로 만들기, 배열을 객체로 만들기
파이어베이스에서도 자주 나오지만 실무에서도 많이 나옴

isSubmitting

서비스 안정성 높이기

등록하기 버튼이 눌릴때마다 쿼리가 마구 날아가면 안된다.
응답이 돌아올 때까지 기다려야 함.

formState.isSubmitting은 버튼을 한번 누르면 다시 버튼을 누르지 못하게 한다.

sentry.io
코드들을 설정하고 try catch해서 난 에러를 sentry.send해서 에러를 보내게 되면 에러가 발생할 때마다 사이트에 정보가 수집이 된다.
어떤 IP에서 어떤 에러가 발생했는지 확인 가능
sentry와 slack을 연결 가능
모든 에러를 연결해두면 slack이 복잡하므로 critical한 에러만 수집하도록 한다.

Gitflow-Workflow

git으로 협업하기

gitflow를 검색하면 이런 사진들이 많이 나온다.

develop 브랜치를 만들고, 또 feature(기능) branches를 만들어서 개발하고 develop으로 합친다.
develop에서 오류가 나는 브랜치는 거절할 수 있음
develop에서 master로 합침.

여기서 오류가 나면 안됨
release 브랜치(버그잡는 곳)에서 합쳐서 master 브랜치에 합치기 전 확인
그리고 master 브랜치 (배포 브랜치)에서 배포

release 브랜치에서 버그를 다 잡았다고 생각했는데 버그가 아직 남았다면?
master 브랜치에서 hotfixes 브랜치로 이동

master 브랜치에서 만드는 브랜치는 다른 브랜치들과 다름.

브랜치를 이동할 때 브랜치가 만들어지면서 이동이 됨.
그 때 가지고 있던 폴더들과 함께 이동이 됨.
때문에 "어디서 체크아웃을 했느냐"가 중요 => "브랜치를 땄다"고 함.

master 브랜치에서 체크아웃을 하면 master의 폴더 내용이 전부 이동이 되는 것

전체 흐름

회사 레파지토리에서 각자의 레파지토리로 fork를 뜬다.

자신의 레파지토리에 있는 것을 clone 받는다

각자 자기 자신의 브랜치를 딴다.

레파지토리로 푸시

pull request (줄여서 pr)
merge request라고 하는 곳도 있다.
팀장은 pr을 보고 합치는 작업을 한다.

합쳐진 develop을 pull 받는다.
여기서 다시 브랜치를 따서 오늘의 작업을 한다.

vscode가 어디에서 pull을 받을 것인지 헷갈려 하기 때문에 이름을 지어준다.
git push origin master(철수 레파지토리 푸시)
git push upstream master(회사 레파지토리 푸시) => 하지만 권한 막혀있을 것이다(다이렉트 푸시X)

git pull origin master (철수 레파지토리 pull)
git pull upstream develop (회사 레파지토리 pull)

주의사항

서로 겹치지 않는 기능을 만들어야 한다.
잘하는 사람이 공통모듈 만들기 (전체가 에러 날 수 있기 때문)
merge가 안 된 상태에서 의존적인 기능 추가하지 않기
ex) 등록을 만들어놓고 merge도 되지 않은 상태에서(pr만 한 상태) 수정 브랜치를 만들어서 작업을 하면 문제가 될 수 있다.
독립적인 기능이면 괜찮으나 등록이 merge 됐을 때 에러가 날 수도 있고...

git checkout (브랜치 이동)
git checkout -b (-가 붙으면 새로 만들어서 이동, 없으면 그냥 이동)

잘못 만들었을 경우?
git checkout main
(메인으로 다시 이동 후 다시 생성)