Next.js에서의 CSR 구현Next.js의 cache 개념이 사용되지 않음 => 과거에 리액트에서 사용하는 방식과 완전히 동일클라이언트 컴포넌트("use client")를 사용하고 useEffect 또는 React의 상태 관리를 활용// app/members/page.js'use client';import { useState, useEffect } from 'react';export default function MembersPage() { const [data, setData] = useState(null); useEffect(() => { fetch('https://api.example.com/members') .then((res) => res.json()) .then(..

RenderingSSR(Server-Side Rendering): 매 요청마다 페이지를 서버에서 렌더링하여 클라이언트에 전송하는 방식특징요청 시마다 페이지가 서버에서 생성데이터를 동적으로 가져오기에 페이지는 최신 데이터를 반영유저별 동적 데이터 처리에 적합장점SEO에 유리최신 데이터 보장단점초기 로딩 시간 존재 -> Suspense를 사용하자많은 요청이 들어오면 서버 부하 발생적합한 사용처최신 데이터를 항상 보여줘야하는 페이지CSR(Client-Side Rendering): 브라우저가 초기 HTML, CSS, JavaScript 파일을 서버로부터 받아온 후, JavaScript를 통해 클라이언트(브라우저)에서 페이지를 렌더링하는 방식특징서버는 초기 HTML과 함께 JavaScript 파일을 제공하며, 이..

리팩토링 카탈로그기본 기술: 가장 자주 사용하는 리팩토링 기술함수 추출하기(Extract Function)구현들을 메서드로 뽑아내어 '메서드 이름'을 통해 "의도"를 표현하자!함수 인라인(Inline Function)함수 본문이 함수 이름만큼 또는 그보다 더 잘 의도를 표현하는 경우단순 우회형 메서드인 경우변수 추출하기(Extract Variable)특정 코드 부분을 변수로 추출하고 이름을 부여하여 의도를 드러내자변수 인라인(Inline Variable)불필요하거나 과하다 싶은 변수는 인라인으로 제거하자함수 선언 변경하기(Change Function Declaration)더 좋은 이름을 통해 함수의 구현을 숨기고 선언부만 보고 이해할 수 있도록 의도를 전달하자변수 캡슐화하기(Encapsulate Vari..

거대한 클래스(Large Class)어떤 클래스가 너무 많은 책임을 가지면 필드도 많아지고 중복 코드가 보이기 시작함클라이언트가 해당 클래스가 제공하는 기능 중 일부만 사용한다면, 각각의 세부 기능을 별도의 클래스로 분리할 수 있음"클래스 추출하기(Extract Class)" -> 관련있는 필드를 한 곳으로 모을 수 있음"슈퍼클래스 추출하기(Extract Superclass)" 또는 "타입 코드를 서브클래스로 교체하기" -> 상속 구조 적용클래스 내부에 산재하는 중복 코드는 메서드를 추출하여 제거 가능슈퍼클래스 추출하기(Extract Superclass)두 개의 클래스에서 비슷한 것들이 보인다면 상속을 적용하고, 슈퍼클래스로 "필드 올리기(Pull Up Field)"와 "메서드 올리기(Pull Up Me..

중재자(Meddle Man)어떤 클래스의 메서드가 대부분 다른 클래스로 메서드 호출을 위임하고 있다면, 중재자를 제거하고 클라이언트가 해당 클래스를 직접 사용하도록 코드 개선 가능 (= 불필요한 추상화/캡슐화 제거)이전에 본 "메시지 체인"의 반대에 해당하는 것관련 리팩토링"중재자 제거하기(Remove Middel Man)" -> 클라이언트가 필요한 클래슬르 직접 사용하도록 개선 가능"함수 인라인(Inline Function)" -> 메서드 호출한 쪽으로 코드를 보내서 중재자를 없앨 수 있음"슈퍼클래스를 위임으로 바꾸기(Replace Superclass with Delegate)""서브클래스를 위임으로 바꾸기(Replace Subclass with Delegate)"중재자 제거하기(Remove Midde..

추측성 일반화(Speculative Generality)나중에 이런저런 기능이 생길 것으로 예상하여 여러 경우에 필요로 할만한 기능을 미리 만들어 두었지만, 결국엔 쓰이지 않게 된 경우..XP의 YAGNI (You aren't gonna need it) 원칙을 따르자= 지금 당장 필요하지 않으면 만들지마라관련 리팩토링"계층 합치기(Collapse Hierarchy)" -> 추상 클래스를 만들었지만 크게 유효하지 않다면"함수 인라인(Inline Function)" 또는 "클래스 인라인(Inline Class)" -> 불필요한 위임이 있다면"함수 선언 변경하기(Change Function Declartion)" -> 사용하지 않는 매개변수를 가진 함수가 있다면"죽은 코드 제거하기(Remove Dead Cod..

반복되는 switch 문(Repeated Swithces)반복해서 동일한 switch 문이 존재할 경우=> 새로운 조건을 추가하거나 기존의 조건을 변경할 때 모든 switch 문을 찾아서 코드를 고쳐야 할지도 모름반복해서 등장하는 것이 아니라면 굳이 리팩토링을 적용할 필요는 없다=> 이전 시간에 사용한 "조건부 로직을 다형성으로 바꾸기(Replace Conditional with Polymorphism)" 리팩토링 적용요즘에는 switch 문이 arrow function 형태로 세련되게 나오기 때문에 이를 사용하는 것을 권장한다 (ex. jdk 17 버전 이상)이를 switch 문이 아니라, switch-expression 이라고 한다.// switch 문 (아래 코드엔 break가 없어서 버그 존재)p..

기본형 집착(Primitive Obsession)애플리케이션이 다루고 있는 도메인에 필요한 기본 타입을 만들지 않고 프로그래밍 언어가 제공하는 기본 타입을 사용하는 경우가 많음ex) 전화번호, 좌표, 돈, 범위, 수량 등기본형으로는 단위(인치 vs. 미터) 또는 표기법을 표현하기 어렵다관련 리팩토링 기술"기본형을 객체로 바꾸기(Replace Primitive with Object)""타입 코드를 서브 클래스로 바꾸기(Replace Type Code with Subclasses)""조건부 로직을 다형성으로 바꾸기(Replace Conditional with Polymorphism)""클래스 추출하기(Extract Class)""매개변수 객체 만들기(Introduce Parameter Object)"기본형을..

8. 산탄총 수술(Shotgun Surgery)어떤 한 변경 사항이 생겼을 때, 여러 모듈을 (여러 함수 또는 여러 클래스를) 수정해야 하는 상황"뒤엉킨 변경" 냄새와 유사하지만 반대의 상황임원인은 동일 -> 낮은 응집도 & 높은 결합도결과는 반대 -> 뒤엉킨 변경은 여러 가지 이유로 하나의 클래스를 계속해서 손보는 것 / 산탄총 수술은 하나의 일로 여러 곳을 손보는 것ex) 새로운 결제 방식을 도입하려면 여러 클래스의 코드를 수정해야 함변경 사항이 여러 곳에 흩어진다면 찾아서 고치기도 어렵고 중요한 변경사항을 놓칠 가능성도 생김관련 리팩토링 기술 -> 대체로 묶는 기술을 사용"함수 옮기기(Move Function)" 또는 "필드 옮기기(Move Field)" -> 필요한 변경 내역을 하나의 클래스로 모..

뒤엉킨 변경(Divergent Change)소프트웨어는 변경에 유연하게(soft) 대처할 수 있어야 함어떤 한 모듈이(함수 또는 클래스가) 여러가지 이유로 다양하게 변경되어야 하는 경우, (= 낮은 응집도, 너무 많은 책임)ex) 새로운 결제 방식 도입하거나 DB 변경할 때 동일한 클래스에 여러 메서드를 수정해야 하는 경우서로 다른 문제는 서로 다른 모듈에서 해결해야 함모듈의 책임이 분리되어 있을수록 해당 문맥을 더 잘 이해할 수 있으며 다른 문제는 신경쓰지 않아도 됨=> 단일 책임 원칙(SRP), 모듈의 높은 응집도 & 낮은 결합도관련 리팩토링 기술"단계 쪼개기(Split Phase)" -> 서로 다른 문맥의 코드를 분리 가능"함수 옮기기(Move Functions)" -> 적절한 모듈로 함수를 옮기기..