Homile

✅ Github 레포지토리 팀원 추가 

코드스테이츠에서 팀장마다 레포지토리를 하나씩 할당 해주었으며 해당 레포지토리에 팀원들을 초대하고 권한을 부여했습니다. 이 과정에서 나의 권한을 admin에서 write로 낮춰 다른 분들의 권한 수정을 하지 못하고 있었는데 어드민권한을 부여했던 팀원에게 연락하여 권한을 다시 부여받았다. 휴 ;-;

✅ 사용자 요구사항 정의서 작성

스택오버플로우에 어떠한 기능이 있고 해당 기능의 역할이 무엇인지를 서술하는 시간을 팀원들과 같이 작업을 했다. 작업을 하는 중 우리가 할 수 있는 만큼 지정하여 작성을 하였고 추가적으로 작업할 수 있는 내용은 추후 추가하기로 하였다. 

가장 메인 기능으로는 질문하기, 답변하기, 로그인, 회원가입 등의 기능이 있었다. 사용자 요구사항 정의서는 이번이 2번째 작성해보는 것인데 학부생때 배웠던 것과는 조금 틀이 달랐지만 비슷하게 작성을 했다. 

라이브 세션때 다른 팀들이 한 사용자 요구사항 정의서를 보았는데 굉장히 많이 기술한 팀은 10페이지 이상이었던 것 같다. 그런걸 보면서 '아 저렇게 많이 작성했어야 했나?' 라는 생각이 들때쯤 크루분께서 많이 상세하게 작성하는 것은 좋지만 이것을 '정해진 기간내에 할 수 있는지도 판단 했으면 좋겠다' 라는 말씀을 하셔서 그나마 위안을 받은 것 같다.

✅ 화면 정의서 작성

나는 프론트엔드 개발자가 되기위한 과정을 밟고 있기 때문에 화면 정의서를 작성해야 했다. 화면 정의서를 작성하는 이유는 팀원 간의 소통을 조금 더 원할하게 할 수 있게 도와주며 특히 API 구성시 필요한 데이터를 백엔드분들께 요청을 자세하게 할 수 있기 때문에 작성해야 했다. 화면 정의서 같은 경우 첫 날에는 간단하게 스택오버플로우 사이트를 캡처하여 데이터가 필요한 부분을 체크하고 어떤 데이터가 필요한지 간단하게 팀원 전체가 모여서 회의를 하며 작성을 했다. 그리고 나중에 든 생각으로는 이렇게 해도 좋을 것 같지만 문서를 조금 더 깔끔하게 작성해서 보여주는 것이 백엔드분들께 좋을 것이라 생각하여 일과 시간이 끝난후 개인적으로 작성하여 넘겨주었다.(조금 부족했던듯....)

메인에서 작성할때는 와이어프레임으로 간단하게 화면을 구성하고 정의서를 작성해서 백엔드 분들이 API 명세서를 작성하는 동안 와이어프레임을 가지고 디자인을 작성해야 겠다.

✅ 프로젝트 주제 발표, 팀원 발표, 툴 세팅

📌 프로젝트 주제 및 목표

주제: Stack Overflow 사이트 클론 코딩

일반적인 클론코딩이라고 생각할 수 있겠지만 Stack Overflow는 React로 구성되어 있지않아 변경하는데 시간이 조금 걸릴 것이라 생각했고, 기획단계가 사라져서 코드를 구현하는데 시간을 조금 더 쓸 수 있을 것이라고 생각했다.

Pre-Project 목표

• 프로젝트에 대한 기본적인 이해도를 높입니다.
• 프로젝트에서 필요한 Github 이해도를 높입니다.
• 프로젝트에 대한 문서작성 능력을 향상 시킵니다.
• 팀 커뮤니케이션 이해도를 높입니다.

✅ 팀원 발표 및 툴 세팅

팀원은 4~5명으로 구성됐고 4인조는 (프론트2, 백엔드2)이었고, 5인조는 프론트나 백엔드가 1명더 많은 구조로 팀원이 구성되었다. 저희 조는 54조로 57개조 중 뒷쪽에 위치하고 있어 찾기도 쉬웠다. 팀원들과 1차적으로 만남을 가지는 자리가 주워져서 이야기를 나누다보니 다들 좋으신분들 같아서 프로젝트가 재미있게 진행 될 수 있을 거라는 생각이 들었다. 그러던 중 팀장에 대한 얘기가 나왔는데 어쩌다 보니 팀장이 되었다. 팀장이라는 직책은 뭔가 책임감을 가져야하는 것이라 살짝 부담이 되었지만 열심히 하기로 마음을 먹었다. 그리고 팀에 대한 규칙을 정하게 되었다.

📌 팀장 역할

일정 조율 및 Github 레포지토리 관리 정도만 하기로 했다. 팀원분들이 팀장의 무게를 덜어주기 위해서 간단하게만 하자고 했다.

📌 팀 규칙

팀 규칙도 간단하게 작성하였다. 오히려 많은 규칙을 가지고 있게 된다면 모두 그 규칙에 얽매이게 되어 능률이 나오지 않을 것이라는 생각이 있었다.

프로젝트 일반 규칙

• 11시 ~ 17시 모여서 프로젝트 진행 (점심시간 제외 (12시 ~ 13시))
• 1일 회고록 작성 (노션)
• 오버 커뮤니케이션
• 호칭은 OO님으로 고정
• 쿠션어 사용

프로젝트 개발 관련 규칙

• Git merge, PR 하기 전 모두 확인 후 실행

📌 툴 세팅

• 상시 커뮤니케이션 툴: Discord, KakaoTalk
• 화상미팅 툴: Discord
• 프로젝트 관리 툴: Github

📌 오늘 드디어 프리 프로젝트가 시작하는 날이다. 어떠한 과정으로 팀장이 됐더라도 앞으로 열심히해서 좋은 결과를 낳을 수 있도록하자!

📗 오늘 학습한 내용

Github 권한 설정, 칸반보드

📘 추가로 공부할 내용

Study원과 함께 진행중인 프로젝트 구현(메인 플젝 후 다시시작)

나만의 포트폴리오 사이트 구현  해보기

pre-project (스택오버플로우)

• 기능 나누기
• 회의시간 정하기
• 파트 나누기

📝 중요한 내용

• Github

📌 프로젝트를 시작하기전 Github 세팅을 배우는 날이다. 이미 한 번 해봤어도 다시 깊게 학습해보자!

📗 오늘 학습한 내용

Github 레포지토리에 필요한 파일

• README.md
  • 프로젝트 이름
  • 프로젝트 핵심 기능 소개
  • 팀원 소개
  • Wiki로 링크
• .gitignore
  • git으로 관리하지 않는 파일 모음
  • secret token, 공유할 필요가 없는 설정 파일을 기록하면 git에 push 되지 않는다.
• LICENSE
  • 해당 코드의 라이센스 표기

Github 기능

• Issue
  • 프로젝트에 새로운 기능 제안, 버그를 찾아 제보하는 등 프로젝트의 이슈를 작성
• Milestone
  • 이정표 역할, 테스크 카드(Issue)를 그룹화 하는 데 사용
• Pull Request
  • git branch에 합칠 수 있는지 확인하는 요청
• Project
  • Github 내에서 업무 관리를 해줄 수 있게 돕는 기능

칸반

• 팀과 조직이 작업을 시각화하고, 업무의 병목 현상과 리소스 낭비를 해결하는 업무 관리 방법
• 반반 보드를 통한 시각화
• 업무를 하나의 티켓으로 표현하고, 업무 단계를 하나의 열로 표현한다.
• 새로운 업무가 생기면 가장 왼쪽 열에 업무가 쌓이고, 업무가 잘 진행되면 가장 오른쪽으로 전달되는 방식이다.
• 백로그 → 할 일 → 진행중 → 완료

칸반 실천법

• 업무 시각화
• 진행 중인 업무 제한
• 흐름 관리
• 명확한 프로세스 정책
• 피드백 루프 구현
• 협력적인 개선, 실험적인 발전

Github 이슈

1. Issue (task card) 생성
2. 테스크 작성
3. 테스크 일정 완료 후 이슈 닫기

Github 이슈 템플릿 카드

1. Settings 클릭
2. Issue의 Set up templates를 클릭

Github 마일스톤

깃허브 마일스톤을 이슈, PR 그룹의 진척도를 확인하는데 사용한다.

1. Milestones 생성
   1. Issue 탭을 누르고 Milestones를 누른다.
   2. Create a Milestone 혹은 New milstone을 누른다.
2. Milestones 세부 내용 작성
3. Milestones 생성 확인

Project 

1. Project 생성
   
   1. Projects 탭 선택 후 Add project 클릭 Go to the.... 클릭
   2. New Project 클릭
   3. 템플릿 선택 후 Create 버튼 클릭
2. Project 이름 및 접근 설정
   1. 오른쪽 상단의 버튼을 눌러 Settings 클릭
   2. 프로젝트의 이름과 간단한 설명을 추가하고 Save 클릭
   3. 프로젝트의 이름이 변경 확인
   4. 설정 페이지 왼쪽 탭에 Manage access 클릭
   5. Base Role을 Read로 변경
   6. Admin 권한으로 팀원 초대
3. Issue 연결하기
   1. #으로 자신의 레포지토리 찾기
   2. 레포지토리 선택 후 Issue, PR 선택
   3. Add selected items 버튼 클릭 후 item 추가
   4. 레포지토리에 작성한 Issue들 추가 확인
4. Project 설정
   1. 각 이슈들의 상태 설정 Todo, In Progress, Done
   2. Labels, PR, Reviewers, Repository, Milestone 등 칼럼 추가 가능
   3. 그룹으로 나눠보기 가능
   4. Assignees, Status, Milestone, Repository 등으로 나누기
5. Project 적용
   1. Projects 탭 Add project 클릭 생성한 project 클릭

Git branch

• 기존 개발중인 메인 개발 코드를 그대로 복사하여 새로운 기능 개발을 메인 개발 코드를 건드리지 않고 할 수 있는 버전 관리 기법
• 브랜치 생성 및 변경하기 (git switch)

# 브런치 생성(switch)
git switch -c 브런치명

# 브런치 생성(checkout)
git checkout -b 브런치명

# 기존에 있던 main 브런치로 변경
git switch main
git checkout main

브랜치 로컬에서 합치기 (git merge) 

# 기능 개발 진행
git commit -m "세부 기능1"
git commit -m "세부 기능2"
git commit -m "개발 완료"

# 머지를 위해 main 브런치로 전환
git switch main

# main 브런치로 feat/todo 브런치 병합
git merge feat/todo

브랜치 Github에서 합치기 (git merge) 

# 기능 개발 진행
git commit -m "세부 기능1"
git commit -m "세부 기능2"
git commit -m "개발 완료"

# Github 레포지토리에 푸쉬
git push origin feat/todo

# Github에서 Pull Request를 진행
# 검수 후 merge

브랜치 삭제 (git branch -d 브런치 명)

Git flow

• 대규모 개발 프로젝트를 제작하여 하나의 소프트웨어의 릴리즈 버전을 명확하게 나누고, 다양한 버전을 배포해야 하는 당시의 개발 환경과는 적합했지만, 빠르게 제작하고 배포하고 고객의 피드백을 받는 애자일한 개발 팀에 적용하기에는 복잡했다.
• 개발 현장의 상황에 맞게 Git flow를 정하는 것이 중요하다.

git 핵심 브랜치

• main: 사용자에게 언제든 제품으로 출시할 수 있는 브랜치
• dev: 다음 버전 배포를 위한 개발중인 브랜치
• feature: 기능 개발, 리펙토링, 문서 작업, 단순 오류 수정 등 다양한 작업을 기록하기 위한 브랜치

프론트엔드 개발 전 개발환경 구성

필수항목

• Node.js
  • JS 브라우저를 벗어나 다양한 운영체제에서 실행할 수 있는 JS런타임이다.
• Node.js 패키지 매니저
  • 여러 소프트웨어를 한꺼번에 모아 설치, 업그레이드, 설정, 삭제 등을 할 수 있는 소프트웨어 툴이다.(npm, yarn)
• 버전 관리 시스템 / 형상 관리 시스템 + 원격 레포지토리 서비스
  • Git을 주로 사용하고, Github와 같은 원격 레포지토리 서비스도 함께 사용한다.
• 프론트엔드 프레임워크(라이브러리)
  • React (18버전 사용 권장)
  • vue
  • Angular
• CSS
  • CSS 프레임워크(라이브러리)
    • CSS 모듈
    • Styled-Components
  • CSS 네이밍 컨벤션
    • BEM
    • Utility-First (Tailwind)
  • CSS 관리 방법
    • CSS-inJS 라이브러리르 사용하여 컴포넌트로 묶어 관리: Styled-Component, Emotion
    • Utility-First (Tailwind CSS)
    • CSS 파일 따로 관리
    • SASS 사용
    • UI 프레임워크 사용 (Meterial UI, Chakra UI, Redix UI)
• Create React App
  • 쉽고 빠르게 React SPA를 개발할 수 있도록 여러 오픈소스를 묶어 제공하는 툴체인
• 린터
  • 문법 에러나 코드 스타일 규칙에 맞지 않는 코드를 찾아주는 툴이다.
  • JS에서는 eslint, prettier가 가장 유명하고 많이 쓰이는 툴이다.

선택항목

• HTTP 요청 (혼용되지 않게 하나만 사용)
  • Fetch API & isomorphic-fetch
  • Axios
  • React Query
  • SWR
• 상태 관리
  • Redux
  • Recoil
  • Zustand
  • React Context API
  • Mobx
• TypeScript
  • 정적 타입 언어처럼 사용할수 있게 변수나 함수의 리턴값에 타입을 지정하여 해당 타입이 아니면 TypeScript를 JS로 컴파일 하지 않게 하고 에러를 내어 견고한 개발을 돕는다.
  • 초기 설정이 어렵고 학습에도 시간이 오래걸린다.
• 번들러
  • webpack
  • esbuild
  • vite
  • parcel
• 테스크 프레임워크
  • Jest, React Testing Library
  • Cypress

📘 추가로 공부할 내용

Study원과 함께 진행중인 프로젝트 구현(메인 플젝 후 다시시작)

나만의 포트폴리오 사이트 구현  해보기

pre-project (스택오버플로우)

• 파트 나눠보기
• 자료 찾기

📝 중요한 내용

• Github

📌 프로젝트 전 마지막 Section4 회고를 하는 날이다... 내가 학습했던 만큼만 한다면 무리없이 협업을 통해 프로젝트를 완성할 수 있다고 생각한다. 그리고 오늘 기술 면접을 준비하면서 내가 항상 부족했던 부분을 조금 더 채워갈 수 있는 하루가 되었으면 좋겠다.!.!

📗 오늘 학습한 내용

JavaScript

• Hoisting과 Temporal Dead Zone이 어떻게 연관되어 있는가?
  • 호이스팅: 함수 안에 있는 선언들을 모두 끌어올려서 해당 함수 유효 범위의 최상단에 선언하는 것을 말하며 var변수 및 함수를 사용하면 호이스팅이 된다.
  • Temporal Dead Zone: let, const, class 구문의 유효성을 관리한다.
  • 해당 질문에 대한 답을 드리기전에 변수의 생성 단계인 선언, 초기화, 할당 단계가 있음을 알아야 합니다. 호이스팅은 변수의 선언 및 초기화가 동시에 이루어지게 되어 변수의 사용이 선언 및 초기화 보다 앞에 있을 경우에 undefined가 출력되지만 TDZ의 경우 변수의 생성단계 3단계를 각자 실행하기 때문에 undefiend가 아닌 에러를 출력합니다.

브라우저 렌더링

• 브라우저 렌더링 방식이란?
  • 사용자가 브라우저를 통해서 페이지에 접속할 때, 서버에서 필요한 파일을 다운받아 화면에 보여주는 것을 브라우저 렌더링이라고 하며, 동작 방식은 HTML, CSS 파일을 파싱하여 Tree를 형성하고, 두 트리르 결합하여 렌더 트리를 만듭니다. 렌더링 트리에서 각 노드의 위치와 크기를 계산하여 각 노드를 화면상에 실제 픽셀로 변환하여 레이어를 만들고 합성하여 실제 화면에 나타냅니다.
  • 렌더링 트리: 렌더링 목적으로 만들어진 트리로 DOM트리와 CSSOM트리를 결합한 것입니다.
• 리플로우와 리페인트?
  • 리플로우란 어떠한 액션이나 이벤트에 따라 요소의 크기나 위치등 레이아웃 수치를 수정하여 영향을 받는 자식, 부모노드들을 포함하여 레이아웃 과정을 다시 수행하게 되는데 이때, 렌더 트리와 각 요소들의 크기와 위치를다시 계산하는 과정을 리플로우라고 합니다.
  • 리페인트란 리플로우만 수행될 경우 실제 화면에 반영되지 않습니다. 리플로우를 통해 다시 계산된 요소들을 화면에 나타나게 하는 것이라고합니다.
• 반응형 웹은 무엇이고 장단점은 무엇인가?
  • 반응형 웹이란 여러 장치의 다양한 특성에 대응하는 하나의 웹 사이트로 브라우저의 크기에 따라 실시간으로 반응하여 레이아웃이 변하는 웹 사이트를 의미합니다.
  • 반응형 웹의 장점으로 하나의 소스만 수정하면 되기 때문에 효율적인 유지보수가 가능하며 URL 기반으로 화면이 바뀌어 검색엔진 최적화에 유리합니다.
  • 반응형 웹의 단점으로 여러 장치에 적응하게끔 만들어져 모바일 전용으로 하는 사이트에 비해 속도가 느리며 많은 데이터를 소비하게 되는 단점과 웹 브라우저의 호환성 문제가 잇습니다.
• JS 엔진의 콜 스택이란?
  • 실행 중인 서브루틴을 저장하는 자료구조입니다.

번들링과 웹팩

• 번들링은 왜 필요한가?
  • 번들링은 여러 제품이나, 코드, 프로그램을 나누어서 패키지로 제공하는 것 입니다. 패키지로 제공되기 때문에 로딩 속도가 일반적인 배포 방식보다 빠릅니다.

React

• Virtual DOM?
  • 실제 DOM의 사본 같은 개념으로 React에서는 실제 DOM 객체에 조작하는 대신 가상 DOM 객체에 접근하여 변화 전과 변화 후를 비교하고 바뀐 부분을 적용하는 것입니다.
• Virtual DOM이 좋은이유
  • 실제 DOM을 조작하게 될 경우 불필요한 트리까지 재 렌더링을 해야하지만 가상 DOM의 경우 바뀐 부분만 적용하기 때문에 속도가 빠릅니다.
• 클래스 컴포넌트와 함수 컴포넌트의 차이점
  • 클래스 컴포넌트의 경우 코드가 많아지고 복잡해질수록 이해하기 어렵고, 컴포넌트 사이에서 상태 로직을 재사용하기 어려웠습니다. 이러한 것을 보완하기 위해 사용되는 것이 함수 컴포넌트입니다. 하지만, 함수 컴포넌트의 경우 상태 값을 사용하거나 최적화할 수 있는 기능들이 부족했지만 Hook이라는 개념을 도입하여 상태의 조작을 쉽게 하도록 변화되었습니다.
• React Hook의 사용 규칙
  • 리액트 함수의 최상위에서만 호출되어야 하며, 오직 리액트 함수 내에서만 사용되어야합니다. 최상위에서 사용하지 않고 조건문, 반복문 안에서 호출하게 되면 순서대로 저장하기 어려워지고 예기치 못한 버그를 초래하게 될 수 있습니다.

운영체제

• Node.js는 싱글 스레드인가?
  • 비동기 이벤트 처리를 기반으로 하는 node.js는 싱글스레드 방식입니다.
• JS는 싱글 스레드이다. 어떻게 싱글 스레드 방식으로 비동기 호출을 할 수 있는가?
  •  
• Event Loop에 대해 설명해라
  • 코드의 실행, 이벤트의 수집과 처리, 큐에 대기 중인 하위 작업을 처리하는 것이 이벤트 루프입니다.
• 가비지 컬렉션이란 무엇이며, 가비지 컬렉션이 가진 언어에는 무엇이 있나?
  • 가비지 컬렉션은 프로그램에서 더 이상 사용하지 않는 메모리르 자동으로 정리하는 것입니다. 가비지 컬렉션이 가진 언는 자바, C#, 자바스크립트 등이 있습니다.

자료구조

• Stack과 Queue의 차이점
  • Stack은 한쪽 방향으로만 입출력이 가능하며, Queue는 한쪽 방향에서 입력이 일어나면 반대 방향에서 출력을 합니다. 스택은 후입선출 방식이고, 큐는 선입 선출 방식입니다.
• Tree와 Graph의 차이점
  • 트리는 단방향 그래프로 하나의 데이터 아래 여러 개의 데이터가 존재할 수 있는 비선형 구조이며,  아래로만 뻗어 나가기 때문에 사이클이 없습니다. 하지만, 그래프의 경우 여러개의 점들이 서로 복잡하게 연결되어 있는 구조로 양방향 통신이 가능하여 사이클이 존재합니다.
• 이진 탐색 방법이란?
  • 데이터가 정렬되어 있는 배열에서 특정한 값을 찾아내는 방식의 알고리즘입니다. 배열의 중간에 있는 임의의 값을 선택하여 찾고자 하는 값과 비교하여 작다면 왼쪽의 데이터들을 대상으로 탐색하며, 클 경우에는 오른쪽에 위치한 데이터들을 대상으로 탐색하는 방식을 반복적으로 수행하여 값을 찾을 때 사용되는 알고리즘 기법입니다.

📘 추가로 공부할 내용

Study원과 함께 진행중인 프로젝트 구현(메인 플젝 후 다시시작)

나만의 포트폴리오 사이트 구현  해보기

pre-project 관련 사이트 찾아보기

📝 중요한 내용

• 기술면접

📌 나만의 CRUD를 만드는 날인데... 나는 스터디에서 Section2에서 미리 한번 제로부터 만들었던 기억을 토대로 만들어서 내가 주어진 시간안에 어느정도의 기능까지 만들 수 있는가 과연 나는 성장했는가? 에 대한 의문을 풀 수 있는 날이 될 것 같다!

📗 오늘 학습한 내용

나만의 CRUD 만들기

• Create
• Read
• Update
• Delete
• Search
• JSON Server

📘 추가로 공부할 내용

Study원과 함께 진행중인 프로젝트 구현(메인 플젝 후 다시시작)

나만의 포트폴리오 사이트 구현  해보기

pre-project 관련 사이트 찾아보기

📝 중요한 내용

• JSON Server를 열어 실제 통신을 해볼 수 있다.
• 리액트를 빌드하여 배포를 할 수있다.
• 프로젝트를 구현할 때 해야하는 부분을 정확히 알 수 있다.