Week 1: OT
0. 들어가기전에
- IT업계로 1차전직을 시도했고, 여전히 온보딩 중에 있다.
- 그 중 가장 많이 느끼는건 개발언어에 대한 이해(Hard Skill)보다는 협업관련(Soft Skill)이 훠어어어어어어얼씬 어렵다고 생각중이다.
- 성향상 나에대한 평가가 엄격한 편이라, 자신에 대한 확신이 생기려면 시간이 좀 걸리는 편이다.
- 그래서 사실 지금 필요한건 자기 객관화 작업인데, 내 수준이 어디인지를 파악하고 조금 더 자신감있는 개발자가 되고싶다.
- 여하튼, 내가하는 모든 학습들이 모여서 조금 더 성장하길 바랄뿐이다
1. 프론트엔드 개발자의 역할
- 프론트엔드 개발자란? 유저들에게 '결과물'을 보여주기 위한 '로직'을 만드는 사람
- 사용자 경험을 담당하는 사람
- 프론트엔드개발자는 왜 구하기 어려운가요(아티클)
- 웹에서 벌어지는 모든 일을 담당
전체업무
- 웹전체기능구현
- 퍼블리싱 -> 디자이나 협업시 Zeplin, Figma 사용
- 디자인 시스템 구축/관리
- 디자인에 대한 통일된 규칙을 시스템화하는 것
- 페이지 전체의 통일된 디자인을 줄 수 있음
- 변경해야될 상황이 생길경우 효율적 변경이가 능
- Storybook
- 작은단위의 컴포넌트로 쪼개는 관점이 생김
- 서비스 운영 및 배포
- Frontend 별도의 프로젝트로 소스코드 통합/배포를 하는 경우가 많다
- 약간의 DevOps 역할을 담당(CI/CD)
- 코드 변경을 buid/deploy하여 출시까지 반영되도록 자동화
- CI(Continuous Intergration): 새로운 코드 변경서항이 정기적으로 빌드 및 테스트되어 공유레포에 통합하는 것이다. 협업시 서로 충돌할 수 있는 문제를 해결할 수 있다.
- CD(Continuous Deployment): 개발사항이 레포를 넘어 유저 환경까지 릴리즈 되는 것
- 워더폴 vs 애자일
- 워더폴: 폭포수 기법
- 애자일: 요구사항을 작게 나눠서 개발을 진행
회사 상황에 따른 담당 업무
-
1) 퍼블리셔가 따로 있는 경우
-
기능구현 / 운영배포
-
2) 디자인 시스템이 없는 경우
- 기능구현 / 퍼블리싱 / 운영배포
-
3) SI/프리랜서
- 기능구현 / 퍼블리싱
2. 인기있는 프론트엔드 기술
3. Git에 대한 기능 이해(⭐️⭐️⭐️)
Git
- 로컬에서 관리되는 버전관리 시스템
- 소스코드 수정에 다른 버전을 관리해준다
Github
- 클라우드 방식으로 관리되는 버전관리 시스템
- 자체 구축이 아닌 빌려쓰는 클라우드 개념, 클라우드 저장소
Commit Convention을 명확하게 작성하는게 중요(⭐️)
- 유다시티 커밋 메시지 스타일 가드가 대표적
- 제목은 모두 현재형으로 작성
- 영어라면 명령조, 한글이라면 구문으로 작성
명령어
- 어떤 명령어 / 기능이 있는지 아는것이 중요
- GUI 툴을 쓰는 것에 찬반이 있음
Git 기초
- git init
- git add
- git commit / push
Branch 활용
Git 심화
- tag
- git commit -amend: 마지막 커밋 수정
- revert
- reset
- rebase
- 많음
Gitflow(⭐️)
-
약 10년전, Vincent Driessen 이라는 사람의 블로그 글에 의해퍼지기 시작했다
-
협업하는 사람들간의 Git을 사용하는 약속이다
-
브랜칭 작업을 규격화하여 브랜치를 쉽게 다룰 수 있게 해주는 방법
-
가장 보편화된 방법
-
각 목적을 가진 다섯가지 브랜치 사용
-
master / develop 기본으로 존재한다.
-
다른 브랜치들은 필요에 따라 추가/삭제
-
master(⭐️): 기준이 되는 브랜치, 제품을 배포하는 브랜드
-
develop(⭐️): 개발브랜치. 이 브랜치를 기준으로 각자 개발한 작업을 기능들을 병합
-
feature(⭐️): 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치로 병합
-
release: 마스터 브랜치 바내기 전에 먼저 QA를 하기위한 브랜치
-
hoxfix: 배포 후 긴급 버그 수정
Github Actions
- 배포 자동화 가능
Github Pages
- github에서 제공하는 적정 웹사이트 호스팅 서비스
4. 협업을 위한 디자인 툴: Figma
- 프론트엔드 개발자는 디자인요소를 추가하지 않는다
- 디자이너가 만들어준 컴포넌트를 받아서 구현하는 작업을 한다
5. React
리액트 기초 개념 정리
- UI라이브러리
- 전역 상태 관리, 라우팅, 빌드 시스템 직접 구축해야한다
- 리액트는 가상돔을 통해 UI를 업데이트 한다.
- 이전 UI상태를 메모리에 유지하고, 변경된 부분만 돔에 반영해주는 기술
- 가상돔은 js객체 형태로 되어있다
- DOM을 직접 수정하는 것보다 효율적인 작업으로 알려짐
Create-React-App(CRA)
- CRA는 리액트를 사용하기 위한 환경을 셋팅해놓은 boilerplate
- CRA는 서버사이드 렌더링을 지원하지 않는다. 백오피스 같은 SSR이 필요하지 않은 경우 CRA를 쓰면 좋다.
npx
- npm 5.2.0 버전에서 새로 추가된 도구
- 기존 글로벌로 설치해서 cli를 사용할 경우, CRA에 포함된 의존성 라이브러리들이 컴퓨터에 남게된다. 버전이 업데이트 될 경우 지웠다 새로 설치해줘야하며, 다른 글로벌로 설치된 라이브러리들과 충돌이 일어날 가능성도 있다.
- npx를 사용하면 CRA패키지를 잠깐 다운받고, 생성 후 패키지는 다시 삭제한다.
file and folder structure
- 리액트에서 폴더나 파일 구조에 대해서 제시하고 있지는 않다.
- 리액트 생태계에서 흔히 말하는 일반적인 접근 방법은 있다
파일의 기능이나 라우트에 의한 분류
- CSS, JS, Test파일을 기능이나 라우트로 분류된 폴더에 같이 두는 방법이다
- 기능의 정의는 보편적인 것이 아니고, 얼마나 세분화할 것인지에 달려 있다
common/
Avatar.js
Avatar.css
APIUtils.js
APIUtils.test.js
feed/
index.js
Feed.js
Feed.css
FeedStory.js
FeedStory.test.js
FeedAPI.js
profile/
index.js
Profile.js
ProfileHeader.js
ProfileHeader.css
ProfileAPI.js파일 유형에 의한 분류
- 비슷한 파일끼리 묶어주는 방법이다
- 애플리케이션 내에서의 역할에 따라 컴포넌트를 다른 폴더로 분리하는 것을 선호하기도 한다(아토믹 디자인)
api/
APIUtils.js
APIUtils.test.js
ProfileAPI.js
UserAPI.js
components/
Avatar.js
Avatar.css
Feed.js
Feed.css
FeedStory.js
FeedStory.test.js
Profile.js
ProfileHeader.js
ProfileHeader.css너무 많은 중첩을 피해라
- 너무 깊은 중첩은 프로젝트 간의 상대경로 입력이나, 파일이 옮겨졌을 때 업데이트의 문제가 있을 수 있다
- 3~4번을 최대한으로 폴더를 중첩하는 것을 제안한다
너무 깊게 생각하지마라
- 일단 시작하고, 문제가 생기면 바꿔보는게 좋다
6. 내가 집중적으로 공부할 것 + 회고
- git flow
- git 기능의 핵심: add/commit/push/pull/branch/checkout
- 현재 gitlflow 방식을 사용하고 있어서 익숙했다. 단지 Git에 대한 막연한 두려움이 있었던 것 같다.
- 그리고 내가 잘하고 있는 것인지에 대한 확신도 필요했다.
- 그래서 생각에 변화를 주었다.
- 지금 내가 git에 대해 알고있고, 사용하고 있는 것들이 일반적으로 사용되는 기능들이고 이것들만 알아도 Git을 조금더 자신감있게 사용할 수 있다.
- 그 외의 것들이 특수한 경우에 사용하는 기능들이기에, 언제쓰는건지는 알아두고 필요할 때 찾아보고 익히는게 좋겠다.
- 그런데 오늘 바로 git remote update 사용했다 -> git 리모트 정보 업데이트하기 모든 리모트 정보를 업데이트, fetch를 수행
- 상황: 동료가 초기 셋팅한 브랜치를 가져와서 사용하려는 경우 로컬브랜치를 만들고, remote update -> pull을 통해 코드를 받아서 자겅ㅂ
프론트엔드