TIL[40일차]마지막 수업. 프론트엔드의 미래, 깃으로 협업하기

남예지·2022년 12월 23일
0

TIL

목록 보기
29/47

Frontend

1. PWA

데이터 패칭으로 데이터를 패칭해서 보여주는건 모바일웹이 대부분이다.
안드로이드는 괜찮지만 ios에서는 막았다가 허용을 해서 더더욱 활용도가 높아진다고 한다.
홈페이지를 만들고 => 모바일 웹을 만들고(웹과 모바일의 순서가 바뀔수도 있음) => PWA를 추가해서 모바일앱으로 바꾼다.(push알림 등)

중요한건 다운로드 안해도 앱처럼 가능하고 안드로이드나 ios에 배포도 할 수 있다.

2. webRTC

코드를 검색해서 자바스크립트처럼 사용할 수 있음.

###3. webGL
3d 그림을 보여주고 싶다 등

webRTC, webGL을 섞어서 vr이나 ar로 가는 경우도 있다.

4. 데이터 시각화 d3.js

실시간 그래프 등(주식)

5. 모비일앱

ReactNative

6. AI

백앤드에서 이뤄지고 있는게 맞지만 프론트에서도 가능하다. 어느정도 넘어온 영역이 있다.

7. 자바스크립트 백앤드

풀스택을 해보고싶다면 자바스크립트 백앤드를 배워보면 되겠다.

시작은 이런 선택지 중에 한 가지 혹은 두 가지만 집중적으로 개발해서 전문가가 되는걸 권장.


실무형 알고리즘

v 검색창에 검색을 할 때 날짜를 입력하는데 .이 자동으로 나오게 하기.
v 체크박스 전체체크, 해지

v 디자이너와 친해지기... ㅋㅋ(초콜릿 많이 사주면서 이것좀 빼주세여...)


시험 볼때 배열안에 객체로만 오지 않는다.
{
{아이디 :{write,title,contents}
{아이디 :{write,title,contents}
{아이디 :{write,title,contents}
{아이디 :{write,title,contents}
}
이렇게 올 수도 있는데 이럴때는 우리가 익숙한 배열안에 객체 형태로 바꿔준 뒤 맵으로 뿌려줘야한다.

혹은 반대의 경우를 원하는 경우도 있어서 연습을 많이 해보는 것이 좋다.

힌트 : object.keys, object.velue

실제 문제가 아래와 같이 나온다.


github로 협업하기 (feat.Gitflow workflow)

우리가 썼던건 master(혹은 main)이다.
브랜치를 이해해야한다.
쉽게 폴더라고 봐보자.

  1. 브랜치 만들고 이동하기
    git checkout -b qqq
    브랜치를 만들면서 그 브랜치로 이동하기 (qqq는 브랜치 이름)

  2. 이 상태에서 새파일해서 파일을 만들고 저장해서 깃커밋까지 하면 깃 브랜치에 파일을 저장했다.

  3. git checkout master
    다시 마스터 폴더에 가기
    이러면 위에서 만든 파일이 마스터 폴더에서는 안보임
    이렇게 따로 관리하기 위해 이렇게 함

  4. master일때 => git marge qqq
    마스터 브랜치와 qqq 브랜치 합치기

이제 브랜치 이름을 qqq 말고 develop 등으로 만들어보자.
그리고 우리는 이제 마스터를 사용하지 않을 것이다.
develop에서 개발할것이다.
기능은 feature branches
feature-boardList
feature-login
기능추가하고 커밋 기능추가하고 커밋
게시글 목록을 다 만들었다면 develop 브런치에 merge한다.(합친다)
이렇게 계속 develop 브렌치를 업데이트해가면서 팀플이 가능해진다.
배포할 때 release branches에 merge한다.
그리고 여기는 버그잡고 커밋, 버그잡고 커밋
더 이상 버그도 없다면 마스터 브렌치에 합친다.
이 마스터 브랜치를 EC2에 깃 pull origin master로 땡겨서 yarn start로 배포한다
중간에 운영상에서 나오는 오류들은 hotfixes라는 브랜치를 만들어서 오류를 잡고 마스터로 보내서 재배포를 한다.

이렇게 하는 이유는 각각에 어떤일이 있었는지 추적이 가능하다.

이런 전략을 gitflow workflow 라고 한다.

CI/CD => trunk based development로 발전했다.
CI/CD를 주로 사용하는 회사는 trunk based development를 사용한다.

CI/CD 란?

CI/CD는 여러 DevOps 단계를 아우르는 포괄적인 용어입니다. CI(지속적 통합)은 코드 변경 사항을 하루에 여러 차례 저장소에 통합하는 방식입니다. CD에는 지속적 제공을 통해 코드 통합을 자동화하거나 지속적 배포를 통해 최종 빌드를 최종 사용자에게 자동으로 릴리스한다는 두 가지 의미가 담겨 있습니다. CI/CD에서 빈번하게 수행되는 테스트로 코드 오류와 결함이 줄어들므로 CI/CD는 모든 DevOps 워크플로에 중요한 역할을 합니다.

장점

  • 신속한 반복 작업
  • 더욱 깔끔한 코드
  • 더욱 빠르게 버그 해결
  • 피드백 루프 단축
  • 더욱 효율적인 협업
  • 고객 만족도 향상

주로 위 2가지 방법을 사용한다.


github에서 가져올때 내 깃허브로 한번 포크(복제)를 해서 각자 레파지토리에 저장되고 그걸 클론해서 vscode로 가져온다.

feature브랜치를 만들고
게시글목록
상품목록
결제기능을 구현
각자 맡은 기능을 구현한다.

그리고 각자 레파지토리에 푸시를 한다.

그리고 상위계정에 pull요청을 한다. 이게 pull request (줄여서 PR 이라고 한다)

그럼 상위계정에는 PR목록이 쌓이게 된다.
회의실에 모여 pr을 합칠지 말지 정해서 합칠 pr만 합친다.
그리고 그렇게 합친걸 다시 각자 내려받는다. 근데 상위계정에서 바로 가져온다.

상위 계정은 upstream
각자 계정에서는 origin


git pull upstream develop이라고 하면 상위계정에서 바로 최신버전을 내려받을 수 있다.

이걸 반복( push-pr-퇴근-출근-회의-pr합치기-pull )

=================================

주의사항이 있다.

  1. 못해도 최소 1일 1PR이 올라가야함(가끔 완벽하게 구현하려고 많은 코드를 짜면서 pr을 안하다가는 코드를 날릴수도 있다. pr을 자주 올리자)
  2. 팀원간에 기능 분배를 할 때 서로간 의존성이 있는 기능들은 하지 않는게 좋다. 서로 독집적인 기능을 분배할 필요가 있다.
  3. 경력자 위주로 공통기능 (공통기능은 모든 영역에 영향을 미치는지 고민하고 신경써야함)
  4. 하루에 기능을 여러개 만들어 날릴때 게시글 등록 pr을 날리고 게시글 수정을 Pr하면 문제가 될 수 있다.
    등록이 되야 수정이 되기때문에 pr을 날릴때는 서로 독립적인 기능들로 날리는게 좋다.

오픈소스에 만약 참여하고 싶다면 똑같이 포크하고 클론으로 다운받아서 피처를 만들어 pr하고 이러면 된다.
이런 사람을 오픈소스 기여자라고 하고 contributor라고 한다.
오픈소스 주도를 하는 사람은 maintainer라고 한다.

main에서 딴 브랜치는 메인의 초기를 가지고 있고 ㅡ feature에서 따온 브랜드는 피처에 내용밖에 없다.

그래서 브렌치를 딸때는 항상 최신화된 develop브렌치(기준브렌치)에서 딴다.


트렐로(Trello)

일정관리 - 오늘할일
활용해서 할 수도 있고 간단하게 깃허브 이슈를 통해서도 할 수 있다.

profile
총총

0개의 댓글