자율 학습 중요성
매일, 매 시간 노트 정리
제출 예정
20~30분 수업, 나머지 자율 학습 시간 (정리 및 복습)
일별 일정
1일차 특강
2일차 소프트 스킬(?)
3일차~... 기술
ppt 참고
여는 문장
왜 여기 모여 있는가.
코딩 잘 해야 밥 먹고 사니까.
코딩이란, 프로그래밍이란
회사 - 가치 추구를 목적으로 하는 단체
소프트웨어 회사 - 가치 추구의 수단으로 소프트웨어를 선택한 단체
좋은 코드, 잘 짠 코드 - '같이 해야 하니까', 규칙적이고 예상 가능하고 읽을만한 코드인가.
코딩 - 컴퓨터가 알아먹게끔 하는 명령어를 구성하는 것.(컴퓨터한테 일 시키기 위해)
프로그래밍 - 3가지 요소
-
만들기 전
1-1. 컴퓨터가 알아 먹는지 / 내가 만들수 있는지 / 얼마나 걸릴지
1-2. 꼭 컴퓨터를 통해 수행해야 하는 일인지.
1-3. 이미 똑같은 기능을 하는 도구가 세상에 있는지. -
만들면서
2-1. 컴퓨터의 언어
2-2. 사람의 언어 (비즈니스 로직, 소통(?)) -
만들고 나서.
3-1. 회사 사람들(같이 수행하는 사람들)이 알아먹을 수 있는 코드로 작성되어 있는지.
웹 개발
브라우저가 무엇을 할 수 있는지, 어떻게 하는지 알고 있어야 함 (ex. DOM API)
https://devjin-blog.com/what-happen-browser-search/
특정 task를 위한 다양한 도구들을 익혀두고 빠르게 판단하여 사용할 것.
존재 가치가 있는 상품(프로그램)을 판단하여 만들것 (complicated).
언어
에러 발생시의 원인 파악과 해결, 해결 이후의 발생 상황 및 배경 파악
좋은 코드 판단의 기준 (알고리즘, 자료구조)
코드 아키텍쳐, 이미지/컴포넌트 최적화, 컴포넌트 디자인
소통
코드 리뷰 -
팀의 기준 혹은 개인의 기준에 따라 코드를 판단, 개선
도서 혹은 참고 -
리팩토링2, 좋은 코드는 읽기 쉬운 코드다, 디자인 패턴, 객체지향, 함수형 프로그래밍, 자바스크립트, 타입스크립트
기존 코드 분석 -
유명한 오픈 소스 라이브러리 / 프레임워크 뜯어보기
https://dongwooklee96.github.io/post/2021/05/05/%EC%98%A4%ED%94%88-%EC%86%8C%EC%8A%A4-%EB%B6%84%EC%84%9D-%EB%B0%A9%EB%B2%95.html
- git 태그를 보면서 릴리즈 버전을 가장 낮춰서 초창기 버전의 코드를 볼 것.
일 잘하는 개발자
- 요구사항을 잘 파악할 것
- 한정된자원: 우리에게 주어신 시간을 알고있기
- 함께: 동료를 배려하는 안정성과 확장성
능력의 한계
주니어로서 할 수 있는것, 해야 하는 것.
엔트리 - 특정 기능의 코드를 작성하는 법
주니어 - 코드 작성 테스트, 개발 지원
미들 - 요구사항 분석, 아키텍쳐 설계 등 시스템
시니어 - 담당 소프트웨어 요구사항 수립, 전반적 리드
머릿속 비어있는 공간들을 확인, 인지하고 그것에 대한 보완, 채워넣음
좋은 코드와 나쁜 코드를 구분할 수 있는 기준과 규칙을 만들고 경험을 쌓을 것.
-함수형, 객체지향, 디자인 패턴, 리팩토링2, 도메인 주도 개발, 컴포넌트 최적화, 오픈소스 분석
한정된 시간에 맞춰진 기능 구현
동료와 함께하는 확장성과 안정성
많은 에러 분석 경험과 브라우저/리액트 작동 원리 이해.
좋은/나쁜 코드 구분 기준을 만들고 많은 예제 학습.
웹 프로덕트 분석
유저,고객,데이터를 파악하는 것이 우선
원 데이터를 어떻게 가공하여 소비자에게 전달할 것인지
그리고 그 과정을 어떻게 할 것인지.
- 어떤 고객에게 어떤 가치를 제공할 것인가?
- 최종 결과물은 어떻게 생겼는지, 기존에 가지고 있는 데이터인지
- 어떤 유저들에게 어느 페이지의 어느 컴포넌트를 어떻게 보여줄 것인지
- 이 정보가 어느 조건에서 어떻게 바뀌어야 하는지
이러한 고민 없이 개발은 진행될 수 없음.
유저와 어드민
모바일과 PC 그리고 브라우저.
타사에서 제공하는 혹은 자체적으로 운영하는 서버
-API (application programing interface) (프론트와 백엔드 사이의 약속)
( ex. 토스 결제 서비스, 카카오 로그인 인증 서비스)
타사 api - 요구 사항 및 제한 사항들을 꼼꼼히 따져봐야 함
자사 api - 스웨거 api 혹은 지라에 기록되어 있음.
(도메인 객체)
웹 개발 역사 & 리액트 등장 배경
-
1995
넷스케이프 브랜던 아이크의 자바스크립트 구성 (모카 or 라이브 스크립트)
당시 자바의 인기, 자바 스크립트라고 이름 붙여보자(?)
첫 구성 당시에는 많이 사용되지 않았음.
많은 회사들의 표준 난립의 시기, 크로스 브라우징 이슈.
ECMA - 표준 설립을 위한 시도 -
2005
ajax의 등장(구글 지도의 탄생)
jQuery의 등장 (주류는 아니었음) -
2008
구글 크롬 브라우저의 등장(V8 엔진 탄생)
자바스크립트 성능에 대한 재조명
브라우저의 속도 향상 -
2009
nodeJS의 출시
자바스크립트의 서버 진출 -
2012
- 제이쿼리의 전성기
--- 자바스크립트 로직의 복잡도 증가 -> 돔 조작 횟수의 상승
--- 크로스 브라우징 이슈
--- 유지 보수의 난이도 상승
- 제이쿼리의 쇠퇴
--- ECMA 국제화 기구의 표준화로 인한 크로스 브라우징 이슈 해결
--- 글로벌 스코프 오염 이슈(개발자 : 글로벌 스코프 오염 때문에 코드 읽기가 불편해짐)
-
2013
모듈화 개선 + SPA + MVC/MVVM
대표적 라이브러리(백본, 앵귤러, 뷰, 리액트, ... )
- MVC : 뷰(UI) 컨트롤러(정책) 모델(데이터) (Backbone.js)
- MVVM 아키텍쳐 : angular, vue
- Flux 아키텍쳐 : React(2013)의 제안 (현재까지의 유행)
- SPA : (single page app) :
SPA : 페이스북의 좋아요 버튼으로부터 시작하는 이야기
-
historyAPI
-
장단점
- 장점
- 성능 향상 : 가상 돔을 사용한 렌더링 성능 (ex. 좋아요 버튼)- 분업화 : 서버 엔지니어와 프론트 엔지니어의 분리
- 느슨한 결합 : 하나의 JSON서버를 통해 ios/안드로이드/웹 구현이 가능
- 단점
- 초기 렌더링에 다소 시간이 걸림
- 프론트엔드 코드 양이 증가(백엔드도 마찬가지) : 필요 학습 자료 증가 = 개발 기간의 증가
- 경력자의 희소화 : 2013~2015 당시 풍부한 경험의 개발자가 드물었음.
-
구성요소
- URL경로와 뷰의 라우팅 관리(리액트 라우터)- 클라이언트 사이드에서의 브라우저 이력 관리를 통한 페이지 이동(리액트 라우터)
- 비동기를 통한 데이터
- 뷰 관리
- 모듈화된 코드 관리
리액트의 대표적인 특징
- 가상 DOM
- 선언적 UI(클래스/함수)
- 단방향 데이터 전달(Props)
- 컴포넌트 지향 / 함수 컴포넌트(16.8) 2019년 7월
- Flux 아키텍쳐 친화적
가상 DOM
리액트는 브라우저 DOM을 직접 조작하지 않음
복사본 업데이트 전/후의 가상 돔 2개를 비교 차이를 구분 (디핑)
... (리컨실레이션)(재조정)
BatchAPI
CSR의 단점
CSR과 SPA : (요즘에는 아니지만) SPA에서 CSR을 기본적으로 함(?).
SEO에 취약(검색 엔진 노출의 문제)
첫 렌더링이 느림
SSR의 등장?
SSG?
NextJS의 등장
미리 빌드를 해놓기 때문에 동적으로 그려져야 하는 정보는 미리 빌드를 해둬도 소용이 없음.
넥스트JS는 현재 기존에 제공하기로 했던 것보다 훨씬 많은 것을 제공하고 있음
덕분에 학습해야 할 내용이 줄어들기도 했으나, 성능 이슈(무거움)은 여전히 문제.
리액트는 무엇인가?
컴포넌트
리액트 팀에서 추천하는 컴포넌트 생성 규칙
- 함수로 선언을 권고
- 함수 이름은 대문자로 시작
- jsx문법을 이용한 엘리먼트 반환(XML+JS)
컴포넌트 구성 요소
스테이트, 프롭스, JSX, 렌더
JSX
HTML to JSX 변환기
1. 하나의 태그만 반환해야 한다.
2. 클래스가 아닌 클래스 네임을 사용한다.
3. 속성은 카멜 케이스를 사용.
4. 자바스크립트 코드는 중괄호로 묶어줘야 한다.
컴포넌트 라이프 사이클
마운팅 / 업데이팅 / 언마운팅
마운팅 :
스테이트, 컨텍스트, 디폴트 프롭스 저장(getDerivedFromProps)
componentWillMount
render
componentDidMount (이펙트를 구현해야 함.)
업데이팅 :
언마운팅 :
componentWillUnmount (cleanUp)
리액트 훅
v16.8 함수형 컴포넌트 (Hooks의 등장)
-
등장배경
프론트 개발자들이 클래스를 어려워 함(접근성)
자바스크립트 this 바인딩 이슈(편의성)
로직을 재사용 하기 어려움(상속이나 컴포지션)(재사용성) -
정의
-
생성 규칙
재사용 가능한 순수 함수 형태
훅의 함수명은 use 로 시작해야 함. (그래야지만 라이브러리 측에서 훅으로 인식함.)
훅은 값의 재사용이 아니라 로직의 재사용을 위한 것이다.
Writing Subject : 함수형 컴포넌트에서 클래스형 컴포넌트의 라이프 사이클 메소드를 비슷하게 사용하는 방법에 대해서 설명해 주세요
리액트는 UI용 라이브러리 일 뿐
UI외에 프론트엔드에서 다뤄야 하는 많은 영역이 있음.
그것에 해당하는 라이브러리를 학습해서 사용할 수 있고, 그렇지 않을수도 있음.
없다면 만들면 그만(?)
필수 습관
공식 문서 읽기
-외부 소스를 통해 정보를 습득했을 때
-회사 혹은 프로젝트에서 사용하게 되었을 때
-업데이트가 되었을 때, 사용중인 라이브러리의 장기적인 방향을 알고 싶을때
문서 탐색 단계
- 배경 파악 - 문제 인식
- 존재 이유
- 해결 방법 - '내가 이 방법에 동의하는가?'
- 튜토리얼 혹은 사용 케이스를 살펴봄.
- bonus - 지속 관리 여부(깃헙 저장소 최근 업데이트, 이슈 탭), 인기도
개발 환경 설정 및 도움말
확장 프로그램
Auto Import
Babel JavaScript
CSS Modules
CSS Peek
Error Lens
HTML to CSS autocompletion
Import Cost
Material Theme Icons
TODO Highlight
GitHub Copilot
열었던 링크들
Virtual DOM (React) 핵심정리
왜 내가 작성한 JavaScript Date 코드가 서버에서는 다르게 보이는 거죠?
리팩터링 2판 (리팩토링 개정판)
읽기 좋은 코드가 좋은 코드다
잘 그리기 금지
헤드 퍼스트 디자인 패턴
조직을 성공으로 이끄는 프로덕트 오너
