좋은 코드란 무엇인가?
- 읽기 쉬운 코드
- 중복이 없는 코드
- 테스트가 용이한 코드
✅ Object Oriented Programming (OOP)
- 프로그래밍 패러다임이 컴퓨터 중심의 패러다임에서 인간 중심 프로그래밍 패러다임으로 바뀐 것이다.
- 현실 세계를 프로그램으로 옮겨와 프로그래밍 하는 것을 말한다.
추상화
현실 세계의 사물들을 객체라 보고, 개발하고자 하는 애플리케이션에 필요한 특징들을 뽑아와 프로그래밍하는 것을 말한다.
OOP의 장점
- 이미 작성한 코드에 대한 재사용성이 높다.
- 자주 사용되는 로직을 라이브러리로 만들어두면 계속해서 사용 가능하며, 신뢰성을 확보할 수 있다.
- 사소한 실수를 하더라도 그 에러를 컴파일 단계에서 잡아낼 수 있어 버그 발생이 줄어든다.
- 라이브러리가 제공하는 기능들을 사용할 수 있기 때문에 생산성이 높아지게 된다.
- 객체 단위로 코드가 나눠 작성되기 때문에 디버깅이 쉽고 유지보수에 용이하다.
- 데이터 모델링 시, 객체와 매핑하는 것이 수월하기 때문에 요구사항을 보다 명확하게 파악하여 프로그래밍 할 수 있다.
OOP의 단점
- 함수형 프로그래밍 패러다임의 등장 배경으로 인해 객체가 상태를 갖게된다.
- 즉, 변수가 존재하고 이 변수를 통해 객체가 예측할 수 없는 상태를 갖게 되어 애플리케이션 내부에서 버그를 발생시킬 수 있다.
객체 지향적 설계 원칙 (SOLID) ⭐
SRP(Single Responsibility Principle), 단일 책임 원칙
- 클래스는 단 하나의 책임을 가져야 한다.
OCP(Open-Closed Principle), 개방-폐쇄 원칙
- 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.
LSP(Liskov Substituation Principle), 리스코프 치환 원칙
- 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입은 정상적으로 동작해야 한다.
ISP(Interface Segregation Principle), 인터페이스 분리 원칙
- 인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.
DIP (Dependency Inversion Principle), 의존 역전 원칙
- 고수준 모듈은 저수준 모듈의 구현에 의존하면 안된다.
✅ RESTful API
REST란?
- Representational State Transfer
- 디자인 패턴이며, 하나의 아키텍처로 볼 수 있다.
- 자원 중점 아키텍처
- 설계의 중심에 자원이 있고, HTTP Method를 통해 자원을 처리하도록 설계하는 것이다.
REST 6가지 원칙
- Uniform Interface
- Stateless
- Caching
- Hierarchical System
- Code on demand
RESTful 하게 API를 디자인 한다는 것은 무엇을 의미하는가?
- 리소스와 행위를 명시적이고 직관적으로 분리한다.
- 리소스는
URL로 표현되고, 리소스가 가리키는 것은명사로 표현됨- 행위는 HTTP Method로 표현하고,
GET(조회), POST(생성), PUT(기존 엔티티 전체 수정), PATCH(기존 엔티티 일부 수정), DELETE(삭제)을 분명한 목적으로 사용
- Message 는 Header와 Body를 명확하게 분리해서 사용한다.
- Entitiy에 대한 내용은 Body에
- API 버전 정보, 응답받고자 하는 MIME 타입 등은 Header에 담는다.
- header와 body는
http header와http body로 나눌 수 있고, http body게 들어가는 json 구조로 분리할 수도 있다.
- API 버전을 관리한다.
- 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다.
REST 장단점
- 장점
- Open API를 제공하기 쉽다.
- 원하는 타입으로 데이터를 주고 받을 수 있다.
- 기존 웹 인프라(HTTP)를 그대로 사용할 수 있다.
- 단점
- 사용할 수 있는 메소드가 4가지 밖에 없다.
- 분산환경에서 부적합하다.
- HTTP 통신 모델에 대해서만 지원한다.
✅ TDD
- 테스트 코드 작성을 주도하는 개발방식
- 매우 짧은 개발 사이클의 반복에 의존하는 소프트웨어 개발 프로세스
- 자동화된 테스트 케이스를 작성하고
- 해당 테스트를 통과하는 코드를 작성하고 상황에 맞게 리팩토링하는 과정
Add a test
- 새로운 기능을 추가하기 전 테스트를 먼저 작성
- 테스트 작성을 위해선 개발자는 해당 기능의 요구사항과 명세를 분명히 이해하고 있어야 한다.
Run all tests and see if new one fails
- 새로운 기능이 제대로 작동함과 동시에 기존의 기능들이 잘 작동하는지 테스트를 통해 확인
Refactor code
좋은 코드를 위해 리팩토링
- 가독성이 좋게 coding convention을 맞추자!
- 네이밍 규칙을 적용하여 메소드명, 변수명, 클래스명에 일관성을 줘야 한다.
- 확장성에 대한 고려와 비즈니스 로직에 대한 고려, 예외처리에 대한 고려
- 코드량이 방대해지면서 리팩토링을 한다.
- 테스트 코드를 이용해서 라팩토링 시간을 단축 시킬수 있다.
✅ 함수형 프로그래밍
immutable vs mutable
- immutable은 변경 불가능, 값을 변경할 경우 새로운 객체를 생성하고 변경된 값을 주입
- mutable은 해당 객체의 값이 변경될 경우 값을 변경
first-class-citizen
- 합수는 일급 객체로 간주
- 함수를 리터럴로 정의
- 파라미터로 전달 가능
- 반환값으로 사용 가능
- 변수나 데이터 구조 안에 담을 수 있음
- 함수를 인자로 전달 가능
✅ MVC 패턴이란?
- Controller (컨트롤러)
- 조정자
- 클라이언트의 요청을 받았을 때, 그 요청에 대해 실제 업무를 수행하는 모델 컴포넌트를 호출
- 모델에 전달하기 쉽게 데이터를 가공
- 모델이 업무를 마치면 그 결과를 뷰에게 전달
- Model (모델)
- 컨트롤러가 호출할 때 요청에 맞는 역할 수행
- 비즈니스 로직을 구현하는 영역 (데이터 처리)
- View (뷰)
- 컨트롤러부터 받은 모델의 결과값을 가지고 사용자에게 출력할 화면을 만듦
- 만들어진 화면을 웹브라우저에 전송
장단점
- 장점
- 단순, 유지보수 편리, 시스템의 낮은 결합도
- 단점
- 뷰와 모델 사이의 높은 의존성
- 대규모 프로그램에서 다수의 뷰와 모델이 연결되므로 컨트롤러가 커지는 현상이 발생 (Massive-View- Controller)
✅ Git
- Git
- 버전 관리 프로그램
- 로컬에서 버전을 관리하고, 로컬에서 프로젝트 기록을 스스로 관리
- 브랜치 생성 및 관리 기능
- ⭐ 다른 개발자와 실시간으로 작업을 공유할 수 없음
- Github
- Git Repository를 위한 웹 기반 호스팅 서비스
- ⭐ 클라우드 서버를 사용해 로컬에서 관리한 소스 코드를 업로드 및 공유가 가능함
✅ 브라우저 렌더링 작동 원리는?
- DNS로 도메인을 IP주소로 바꿈
- HTTP 또는 HTTPS를 이용하여 요청
Loading- HTTP 모듈 또는 파일 시스템으로 전달 받은 리소스 스트림을 읽음DOM 생성- HTML을 파싱하여 DOM Tree 생성CSSOM 생성- CSS 파싱해서 CSS Tree 생성Render Tree 생성- DOM과 CSSOM 결합하여 렌터링 Tree 생성Layout- 렌더링 트리가 화면상에 어떤게 배치할 것인지 계산Paint- 화면상에 보여줌
✅ 웹 페이지가 사용자에게 보여지는 과정
- Prompt for unload
현재 페이지에서 다른 페이지로 이동할 때 발생하는 이벤트 - Redirect ~ Response
네트워크 통신, 요청을 받고 HTML파일 등의 리소스를 브라우저로 가져오는 과정
AppaCache - 캐싱을 확인해서 캐싱된 데이터가 있다면 바로 사용해서 퍼포먼스 효율 높일 수 있음DNS - 도메인 서버의 IP주소로 변환TCP - 이 레이어에 요청이 성공하면 Response 도착
- Processing
백엔드에서 받은 리소스 (HTML, CSS)로 DOM과 CSSOM 만들어 Rendering Tree 생성 - Load
화면 상에 보여줌
✅ CSR vs SSR
CSR
- 웹 페이지 렌더링이 클라이언트 측에서 일어난 것
- 쿠키에 사용자 정보를 저장해야 해서 위험 요소가 될 수 있음
- 데이터 트래픽이 감소하고 렌더링이 한 번이기에 페이지 이동이 빠름
- SEO(검색최적화) 사용 불가능
SSR
- 첫 페이지의 렌더링을 서버 측에서 처리
- 서버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 보여주는 방식
- SEO(검색최적화) 측면에서 유리
- 서버에서 세션으로 사용자 정보를 저장할 수 있음
💡 쿠키 vs 세션
쿠키
- 서버와 클라이언트 양쪽에서 쿠키 데이터를 사용하는 API 존재
- key/value 형태
- HTTP 통신 시, 쿠키 정보도 함께 자동으로 서버에 전송됨
- 문자열만 저장이 가능하고 용량에 제한이 있음
세션
- 메모리에 저장
- 브라우저 닫으면 소멸
✅ Token
특징
- 인증에 필요한 정보들을 암호화시킨 토큰
- 사용자는 Access Tocken을 HTTP 헤더에 실어 서버에 전송
- 임의로 생성된 비밀번호 같이 동작하며, 제한된 수명을 가지며 만료되면 새로 생성해야 함
- 별도의 저장소 관리가 필요 없어 간편
단점
- 길이가 길어 인증에 필요한 요청이 많아질수록 서버의 자원 낭비가 발생함
- 이미 발급된 토큰에 대해서는 유효기간이 완료될 때까지는 계속 사용이 가능해 악의적인 이용이 가능함
세션/쿠키와 차이점은?
클라이언트 입장에서 HTTP 헤더에 세션 ID나 토큰을 실어서 보내주는 공통점을 가지고 있지만, 서버 측면에서 차이점이 있음
- 세션/쿠키
- 세션 저장소에 유저 정보를 넣음
- 토큰
- 토큰 안에 유저 정보가 들어감 (별도의 저장소 필요 X)
- 인증을 위해 암호화
✅ HTTP 상태 코드
- 1XX (정보) - 요청을 받았으며 프로세스를 계속 진행
- 2XX (성공) - 요청을 성공적으로 받았으며 인식했고 수용했음
- 3XX (리다이렉션) - 요청 완료를 위해 추가 작업 조치가 필요
- 4XX (클라이언트 오류) - 요청의 문법이 잘못되었거나 요청을 처리할 수 없음
- 5XX (서버 오류) - 서버가 명백히 유효한 요청에 대해 충족을 실패했음
