개발자로 전향중

리팩터링 2판 3장 - 코드에서 나는 악취 2탄

hovinee — Tue, 24 Dec 2024 18:47:44 +0900

3.4 긴 매개변수 목록

좋종 다른 매개변수에서 값을 얻어올 수 있는 매개 변수가 있을 수 있는데, 이런 매개변수는 매개변수를 질의 함수로 바꾸기로 제거할 수 있다.

사용 중인 데이터 구조에서 값을을 뽑아 각각을 별개의 매개변수로 전달하는 코드라면 객체 통째로 넘기기를 적용해서 원본 데이터 구조를 그대로 전달한다. 함수 동작의 방식을 정하는 플래그 역할의 매개변수는 플래그 인수 제거하기로 없애준다.

3.5 전역 데이터

전역 데이터는 코드베이스 어디에서든 건드릴 수 있고 값을 누가 바꿨는지 찾아낼 메커니즘이 없다는게 문제다. 이를 방지하기 위해 우리가 사용하는 대표적인 리팩터링은 변수 캡슐화하기다

3.6 가변 데이터

함수형 프로그래밍에서는 데이터는 절대 변하지 않고, 데이터를 변경하려면 반드시 변경하려는 값에 대항하는 복사본을 만들어서 반환한다는 개념을 기본적으로 삼고 있다. 변수 캡슐화하기를 적용하여 정해놓은 함수를 거쳐야만 값을 수정할 수 있도록하면 값이 어떻게 수정되는지 감시하거나 개선하기 쉽다.

API를 만들 때는 질의 함수와 변경 함수 분리하기를 활용해서 꼭 필요한 경우가 아니라면 부작용이 있는 코드를 호출할 수 없게 한다.

리팩터링 2판 3장 - 코드에서 나는 악취 1탄

hovinee — Tue, 24 Dec 2024 18:14:46 +0900

3.1 기이한 이름

함수, 모듈, 변수, 클래스 등은 그 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 엄청나게 신경 써서 이름을 지어야한다. 마땅한 이름이 떠오르지 않는다면 설계에 근본적인 문제가 숨어 있을 가능성이 높다.

3.2 중복 코드

한 클래스에 딸린 두 메서드가 똑같은 표현식을 사용하는 경우가 있다. 이럴 때는 함수 추출하기를 써서 양쪽 모두 추출된 메서드를 호출하게 바꾸면 된다. 코드가 비슷하긴 한데 완전히 똑같지는 않다면 문장 슬라이드하기로 비슷한 부분을 한곳에 모아 추출하기를 더 쉽게 적용할 수 있는지 살펴본다. 같은 부모로부터 파생된 서브 클래스들에 코드가 중복되어 있다면, 각자 따로 호출되지 않도록 메서드 올리기를 적용해 부모로 옮긴다.

문장 슬라이드

// 리팩토링 전
const OrderProcess = () => {
  const processOrder = () => {
    validateOrder();
    const price = calculatePrice();
    sendEmail();
    const tax = calculateTax();
    saveToDatabase(price, tax);
  };

  return <button onClick={processOrder}>주문 처리</button>;
};

// 리팩토링 후 (관련 있는 로직을 모음)
const OrderProcess = () => {
  const processOrder = () => {
    // 검증 관련
    validateOrder();
    
    // 금액 계산 관련
    const price = calculatePrice();
    const tax = calculateTax();
    
    // 주문 완료 처리
    sendEmail();
    saveToDatabase(price, tax);
  };

  return <button onClick={processOrder}>주문 처리</button>;
};

메서드 올리기

메서드 올리기(Pull Up Method)는 중복된 로직을 상위로 올려서 재사용하는 리팩토링 패턴

// 중복된 로직을 상위 컴포넌트로
const withAuth = (WrappedComponent) => {
  return (props) => {
    const checkAuth = () => {
      // 공통 인증 로직
    };

    return <WrappedComponent {...props} checkAuth={checkAuth} />;
  };
};

// 각 컴포넌트에서 사용
const ProfilePage = withAuth(Profile);
const SettingsPage = withAuth(Settings);

// 공통 로직을 훅으로 추출
const useAuth = () => {
  const checkAuth = () => {
    // 공통 인증 로직
  };
  
  return { checkAuth };
};

// 각 컴포넌트에서 사용
const Profile = () => {
  const { checkAuth } = useAuth();
  // ...
};

const Settings = () => {
  const { checkAuth } = useAuth();
  // ...
};

// 공통 로직을 Context Provider로
const AuthProvider = ({ children }) => {
  const checkAuth = () => {
    // 공통 인증 로직
  };

  return (
    <AuthContext.Provider value={{ checkAuth }}>
      {children}
    </AuthContext.Provider>
  );
};

// 하위 컴포넌트에서 사용
const Profile = () => {
  const { checkAuth } = useContext(AuthContext);
  // ...
};

3.3 긴 함수

함수가 길수록 이해하기 어렵다. 짧은 함수로 구성된 코드를 이해하기 쉽게 만다는 가장 확실한 방법은 좋은 이름이다. 함수 이름을 잘 지어두면 본문 코드를 볼 이유가 사라진다. 그러기 위해서는 훨씬 적극적으로 함수를 쪼개야 한다. 주석을 달아야 할 만한 부분은 무조건 함수로 만든다. 그 함수 본문에는 원래 주석으로 설명하려던 코드가 담기고, 함수 이름은 동작 방식이 아닌 의도가 드러나게 짓는다. 즉 무엇을 하는지 코드가 잘 설명해주지 못할수록 함수로 만드는게 유리하다.

함수를 짧게 만드는 99%는 함수 추출하기가 차지한다. 그렇다면 임시 변수를 질의 함수로 바꾸기로 임시 변수의 수를, 매개변수 객체 만들기와 객체 똥째로 넘기기로 매개변수의 수를 줄일 수 있을 것이다. 이 리팩터링들을 적용해도 임시 변수와 매개변수가 너무 많다면 함수를 명령으로 바꾸기를 고려해보자

각각의 리팩토링 패턴을 React 예제로 설명해드리겠습니다:

임시 변수를 질의 함수로 바꾸기

typescriptCopy// Before: 임시 변수 사용
const OrderSummary = ({ order }) => {
  const basePrice = order.quantity * order.itemPrice;
  const discountLevel = basePrice > 1000 ? 0.95 : 1;
  const finalPrice = basePrice * discountLevel;

  return <div>최종 가격: {finalPrice}</div>;
};

// After: 질의 함수로 변경
const OrderSummary = ({ order }) => {
  const getBasePrice = () => order.quantity * order.itemPrice;
  const getDiscountLevel = () => getBasePrice() > 1000 ? 0.95 : 1;
  const getFinalPrice = () => getBasePrice() * getDiscountLevel();

  return <div>최종 가격: {getFinalPrice()}</div>;
};

매개변수 객체 만들기

typescriptCopy// Before: 많은 매개변수
const ShippingInfo = ({ street, city, state, country, zipCode }) => {
  return (
    <div>
      <p>{street}</p>
      <p>{city}, {state}</p>
      <p>{country} {zipCode}</p>
    </div>
  );
};

// After: 객체로 묶기
interface Address {
  street: string;
  city: string;
  state: string;
  country: string;
  zipCode: string;
}

const ShippingInfo = ({ address }: { address: Address }) => {
  return (
    <div>
      <p>{address.street}</p>
      <p>{address.city}, {address.state}</p>
      <p>{address.country} {address.zipCode}</p>
    </div>
  );
};

객체 통째로 넘기기

typescriptCopy// Before: 객체에서 필요한 값만 추출해서 전달
const UserProfile = ({ user }) => {
  return <ProfileDetails 
    name={user.name}
    email={user.email}
    phone={user.phone}
  />;
};

// After: 객체를 통째로 전달
const UserProfile = ({ user }) => {
  return <ProfileDetails user={user} />;
};

함수를 명령으로 바꾸기 (Command Pattern)

typescriptCopy// Before: 복잡한 함수
const OrderProcessor = ({ order }) => {
  const processOrder = () => {
    const basePrice = calculateBasePrice();
    const taxes = calculateTaxes(basePrice);
    const shipping = calculateShipping(basePrice);
    const totalPrice = basePrice + taxes + shipping;
    // ... 더 많은 복잡한 로직
  };

  return <button onClick={processOrder}>주문 처리</button>;
};

// After: 명령 객체로 변환
class OrderCommand {
  constructor(order) {
    this.order = order;
  }

  calculateBasePrice() {
    // base price 계산 로직
  }

  calculateTaxes(basePrice) {
    // tax 계산 로직
  }

  calculateShipping(basePrice) {
    // shipping 계산 로직
  }

  execute() {
    const basePrice = this.calculateBasePrice();
    const taxes = this.calculateTaxes(basePrice);
    const shipping = this.calculateShipping(basePrice);
    return basePrice + taxes + shipping;
  }
}

const OrderProcessor = ({ order }) => {
  const processOrder = () => {
    const command = new OrderCommand(order);
    return command.execute();
  };

  return <button onClick={processOrder}>주문 처리</button>;

그렇다면 추출할 코드 덩어리는 어떻게 찾아 낼까? 한 가지 좋은 방법은 주석을 참고하는 것이다. 주석이 설명하는 코드와 함께 함수로 빼내고, 함수 이름은 주석 내용을 토대로 짓는다. 코드가 단 할줄이어도 따로 설명할 필요가 있다면 함수로 추출하는게 좋다.

리팩터링 2판 2장 - 리팩터링 원칙 2탄

hovinee — Fri, 20 Dec 2024 18:42:09 +0900

리팩터링 시 고려할 문제

새 기능 개발 속도 저하

리팩터링의 본집은 코드 베이스를 예쁘게 꾸미는데 있지 않다. 오로지 경제적인 이유로하는것이다.

코드 소유권

코드의 소유권은 팀에 두는 것이다. 팀원이라면 누구나 팀이 소유한 코드를 수정할 수 있게 한다.

브랜치

지속적인 통합 (CI) 또는 트렁크 기반 개발 (TBD)를 따라 모든 팀원이 하루에 최소 한 번은 마스터와 통합한다.머지의 복잡도를 줄일 수 있을 뿐 아니라 리팩터링과의 궁합도 좋다. 기능별 브랜치가 가져오는 리팩터링 부담은 너무나 크다. CI를 적용하는 편이 소프트웨어를 배포하는 데 훨씬 효과적이라는 객관적 증거가 있다.

테스팅

리팩터링은 단계별 변경 폭이 작아서 도중에 발생한 오류의 원인이 될만한 코드 범위가 넓지 않다. 원인을 못찾더라도 버전 관리 시스템을 이용하여 가장 최근에 정상 작동하던 상태로 되돌리면 된다. 핵심은 오류를 빨리 잡는데 있다. 리팩터링을 하기 위해서는 자가 테스트 코드를 마련해야 한다.

테스트 코드는 리팩터링을 할 수 있게 해줄 뿐만 아니라 새 기능 추가도 훨씬 안전하게 진행할 수 있도록 도와준다. 리팩터링 과정에서 버그가 생길 위험이 아주 크다는 불안감을 해소할수 있다. 테스트 코드는 꼭 필요해서라기보다는 갖춰두면 유용하다.

자가 테스트 코드는 통합과정에서 발생하는 의미 충돌을 잡는 메커니즘으로 활용할 수 있어서 자연스럽게 CI와도 밀접하게 연관된다. CI에 통합된 테스트는 지속적인 배포 (CD)의 핵심이다.

레거시 코드

테스트를 보강한다.

리팩터링 2판 2장 - 리팩터링 원칙 1탄

hovinee — Fri, 20 Dec 2024 18:29:40 +0900

리팩터링: 소프트웨어의 겉보기 동작은 그대로 유지한 채 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법

예시 코드가 없는 텍스트이기 때문에 기억에 남는 글만 기록하겠다.

두개의모자

목적이 기능추가 또는 리팩터링이냐를 명확히 구분해 작업을 한다.

리팩터링을 하면 버그를 쉽게 찾을 수 있다.

뛰어난 프로그래머는 아니지만 좋은 습관을 가진 프로그래머가 되자!

언제 리팩터링을 해야할까 (3의 법칙)

1. 처음에는 그냥 한다.

2. 비슷한 일을 두 번째로 하게 되면(중복이 생겼다는 사실에 당황스럽겠지만), 일단 계속 진행한다.

3. 비슷한 일을 세 번째 하게 되면 리팩터링 한다.

준비를 위한: 리팩터링

리팩터링하기 가장 좋은 시점은 코드베이스에 기능을 새로 추가하기 직전이다. 함수 매개변수화하기 를 적용해서 중복 코드를 없앤다.

이해를 위한: 리팩터링

코드의 의도가 명확하게 드러나도록 한다. 조건부 로직의 구조가 이상하지 않은지 함수 이름을 잘못 정해서 실제로하는 일을 파악하는 데 오래 걸리지 않는지 등등

쓰레기 줍기 리팩터링

로직이 쓸데없이 복잡하거나 똑같은 함수가 여러개일 경우 간단히 수정할 수 있는 일은 끝내고 시간이 좀 걸리는 일은 짧은 메모만 남긴 다음 하던 일을 끝내고 나서 처리한다.

계획된 리팩터링과 수시로 하는 리팩터링

리팩터링 일젖ㅇ을 따로 잡아두지 않고, 기능을 추가하거나 버그를 잡는 동안 리팩터링도 함께 한다. 보기 싫은 코드를 발견하면 리팩터링을 하자. 그런데 잘 작성된 코드 역시 수많은 리팩터링을 거쳐야한다.

리팩터링을 하지 말아야 할때

지저분한 코드를 발견해도 굳이 수정할 필요가 없다면 리팩터링하지 않는다. 내부 동작을 이해해야 할 시점에 리팩터링 효과를 볼 수 있다.

리팩터링 하는 것보다 처음부터 새로 작성하는게 쉬울 때도 리팩터링하지 않는다.

리팩터링 2판 1장 - 첫 번째 예시 3탄

hovinee — Wed, 18 Dec 2024 17:22:14 +0900

1-8 다형성을 활용해 계산 코드 재구성하기

다형성이란?

*다형성(Polymorphism)**은 객체지향 프로그래밍(OOP)의 핵심 개념 중 하나로, 같은 인터페이스나 부모 클래스를 공유하는 객체들이 서로 다른 방식으로 동작할 수 있는 능력

쉽게 말해, 같은 기능을 하더라도 객체에 따라 다른 결과를 만들어낼 수 있는 것

예시 (현실 비유):

"동물"이라는 공통된 행동: 모두 소리를 낼 수 있음.
하지만, 각 동물마다 소리는 다름:
- 개: "멍멍"
- 고양이: "야옹"
- 소: "음메"

나는 React를 쓰기 때문에..

React에서 다형성

React에서는 클래스 기반이 아닌 함수형 컴포넌트를 사용하면서, 다형성을 컴포지션(Composition), 조건부 렌더링, 동적 매핑을 통해 구현합니다.

React에서 다형성은 다음과 같이 사용할 수 있습니다:

공통 컴포넌트에 props를 전달하여 동작을 변경.
동적 렌더링을 통해 여러 컴포넌트를 같은 인터페이스로 관리.
컴포지션을 통해 재사용 가능한 컴포넌트 구성.

그냥 당연한 듯 써왔지만 다형성이란 개념이 들어가 있는 것이었다.. 다시 본문으로 돌아와서!!

예를 들어 amountFor() 함수를 보면 연극 장르에 따라 계산 방식이 달라진다. 이런 형태의 조건부 로직은 코드 수정 횟수가 늘어날수록 골칫거리로 전락하기 쉽다. 이를 방지하려면 프로그래밍 언어가 제공하는 구조적인 요소로 적절히 보완해야한다. 핵심은 조건부 로직을 다형성으로 바꾸기!

책에서 이해한 바를 GPT한테 질문했다.

리팩터링 2판 1장 - 첫 번째 예시 2탄

hovinee — Fri, 13 Dec 2024 17:09:09 +0900

1탄을 작성하기 위해 2시간 가량 집중해서 정독했는데 느낀점은 지금까지 나는 어떻게 코드를 짰던걸까? 하는 의문점이 들었다..기능을 돌아가게 하는것도 중요하지만 리팩터링을 하며 수정이 용이하고 확장 가능한 설계를 하는것이 얼마나 중요한가를 깨닫게 되었다. 정확하게는 리팩터링은 어떻게 하는것인가의 기준이 생기기 시작했다.

2탄의 시작은 책 내용 기준 1.5 중간 점검: 난무하는 중첩 함수부터이다.

지금까지는 프로그림의 논리적인인 요소를 파악하기 쉽도록 코드의 구조를 보강하는데 주안점을 두고 리팩터링을 했다면 이제 HTML 버전을 만드는 작업을 살펴보자

=> 해당 부분은 텍스트로만 봤을 때는 이해가 잘안되었다.

계산 코드가 분리됐다:
데이터 처리나 비즈니스 로직 같은 복잡한 계산 작업은 별도의 파일이나 함수로 정리되어 있다는 의미입니다.
즉, HTML을 작성할 때는 **"화면에 표시할 데이터만 신경 쓰면 된다"**는 뜻입니다.
HTML 코드만 작성하면 된다:
계산된 결과를 기반으로 UI를 출력하는 역할만 수행한다는 의미입니다. UI 코드에 로직이 섞이지 않으므로 간단한 구조로 유지할 수 있습니다.

즉 나는 react를 사용해왔기 때문에 선언형프로그램에 익숙해져있어서 당연하게 사용해왔던 것이다. 그럼 이참에 한번 집고 넘어가면 좋겠다.

1. 명령형 프로그래밍(JavaScript의 기본 방식)

명령형 프로그래밍에서는 개발자가 UI를 업데이트하기 위한 모든 단계를 명시적으로 작성해야 합니다.

예: 클릭 카운트를 증가시키는 기능

javascript
코드 복사
let count = 0; // 요소 가져오기
const button = document.querySelector("#button");
const display = document.querySelector("#display");
// 클릭 이벤트 핸들러 추가
button.addEventListener("click", () => {
count += 1;
// 상태를 업데이트
display.textContent = `Count: ${count}`;
// UI를 업데이트 });

여기서 중요한 점:
- count라는 상태를 수동으로 관리해야 합니다.
- DOM 요소(display)를 직접 가져와야 하며, 상태가 변경될 때마다 명령을 내려 UI를 갱신해야 합니다.
- 모든 동작이 명시적으로 작성되어야 하므로 코드가 장황해지고, 복잡한 애플리케이션에서는 관리가 어려워질 수 있습니다.

2. 선언형 프로그래밍(React의 접근 방식)

React는 선언형 방식을 사용하여 상태와 UI를 자연스럽게 연결합니다.
개발자는 **"무엇을 렌더링할지"**에만 집중하면 되고, UI 갱신은 React가 알아서 처리합니다.

동일한 예를 React로 작성하면:

jsx

코드 복사
import React, { useState } from "react"; 
const App = () => {
const [count, setCount] = useState(0); 

return ( <div> <p>Count: {count}</p>
<button onClick={() => setCount(count + 1)}>Click Me</button> 
</div> ); };

여기서 중요한 점:

count 상태를 관리하면 React가 DOM을 자동으로 갱신합니다.
UI 갱신 로직을 명시적으로 작성하지 않아도 됩니다.
코드는 간결하고 직관적입니다.

3. 명령형 vs 선언형 비교

특징 명령형 (JavaScript) vs 선언형 (React)

초점	"어떻게 할지(How)"를 명시적으로 작성	"무엇을 할지(What)"를 선언적으로 정의
UI 갱신 방식	DOM을 직접 조작	상태를 기반으로 UI 자동 갱신
코드 가독성	복잡하고 장황해질 수 있음	간결하고 직관적
유지보수성	상태와 UI 갱신 로직이 분리되지 않아 관리 어려움	상태와 UI를 독립적으로 관리 가능
적용 예	순수 JavaScript, jQuery 등	React, Vue.js, Angular (선언형 프레임워크)

4. 결론

일반 JavaScript는 명령형 프로그래밍 스타일에 기반을 두고 있습니다. 이는 단순한 작업에는 적합하지만, 복잡한 애플리케이션에서는 관리와 유지보수가 어려울 수 있습니다. React는 선언형 스타일을 통해 UI 갱신과 상태 관리를 자동화하여, 코드를 더 간결하고 직관적으로 작성할 수 있게 도와줍니다. 따라서 React와 같은 선언형 프레임워크는 명령형 JavaScript의 단점을 극복하기 위해 등장했다고 볼 수 있어요. 생각해보면 버츄얼돔의 사용이 엄청난 변화가 맞는거같다.

하지만 지금은 공부를 하는 단계임으로 전부다 파헤쳐보겠다.

책에서 얘기하는건 텍스트 버전과 (api, db 저장, 텍스트 출력 등), HTML 버전을 똑가은 계산 함수로 사용하게 만들고 싶다고 나와있다. 선호하는 방식은 단계쪼개기!

1. 두 단계로 나누는 것이다. 첫 단계에서는 statement() 즉 최상단 함수의 데이터를 처리하고 다음 단계는 앞서 처리한 결과를 텍스트느 HTML로 표현하자 단계를 쪼개려면 중첩 함수들을 함수 추출하기로 뽑아내야된다.

2. 본문 전체를 별도 함수로 추출하고 두 단계 사이의 중간 데이터 구조 역할을 할 객체를 만들어서 인수로 전달한다. 즉 2개의 매개변수를 전달할 필요가 없음으로 statementData = invoice.customer 이런식으로 하나로 통합시킨다.

react에서 useState 사용 data 객체를 통일시키는것과 비슷한거같다. ( 불필요한 매개변수를 줄이면 함수의 사용이 단순해지고, 읽기와 이해가 쉬워진다.)

3. 함수 옮기기!

중첩함수였던 playfor을 최상단으로 옮김

statementData.performances = invice.performance.map(enrichPerformance)


function enrichPerformance (aPerformance) {
	const result = Object.assign({}, aPerformance) // 얕은 복사 수행 (불변성) 원시값만 변경
	....
    result.play = playfor(result) 
    return result
}

4. 위처럼 변수의 인라인을 객체를 생성하여 저장시킴으로써 statementData {} 안에 play, amount, volumeCredits 등등을 객체로 추가할 수 있다. 그럼 statement 최상위 함수에서 statementData set이 형성되고 매개변수로 전달했을 때 데이터만 가져와서 사용 가능

5. 그러면 아래와 같이 첫 단계인 statement에 필요한 데이터 처리에 해당하는 코드를 모두 별도 함수로 빼낸다.

리팩터링 2판 1장 - 첫 번째 예시 1탄

hovinee — Thu, 12 Dec 2024 11:36:12 +0900

어느덧 개발자로 커리어를 쌓아간지 2년이 지났다. 뭐 일단 아무것도 모르는 신입에서 주니어로에서 0.1% 나아진 기분이다. 진행하던 프로젝트가 커지고 코드 퀄리티를 고민하게 되면서 캡슐화, 추상화, 컴포넌트 분리, 렌더링, 사이드 이펙트 등등 기초적인 코드와 리액트가 어떻게 사용되어야 좋은 코드인지 검색 또는 인강으로만 찾아봤지 책을 읽어볼 생각은 못했다..(핑계) 그러다 어느 블로그를 보고 이 책을 알게 되었고 이제부턴 나의 코드 교과서처럼 사용하기 위해 정리를 시작한다. 난 기본적으로 하나의 뿌리를 제대로 심는걸 좋아한다.

책의 코드를 복사해서 넣고 이게 어떤 쓰임새인지 등등 정리를 해도 안볼걸 알기 때문에 개념을 위주로 기록을 할 예정이다. 그리고 개념을 바탕삼아 향후 코드를 짤때는 최대한 적용 할 것이다. 모든 것의 목적은 좋은 코드를 짜는 것이고 나중에 이직을 위한 밑거름이 될 것이라 생각해서이다. 그럼 24년 12월 겨울을 시작하여 끝까지 진행해보겠다. 우선 책의 서론에서 1~4장까지 꼼꼼히 읽고 이후부터는 빠르게 훑어보라는 가이드가 있으니 1~4장은 꼼꼼히 읽어보겠다.

리팩터링이란?

겉으로 드러나는 코드의 기능은 바꾸지 않으면서 내부 구조를 개선하는 방식으로 소프트웨어 시스템을 수정하는 과정이다. 즉 리팩터링한다는 것은 코드를 작성하고 난 뒤에 설게를 개선하는 일!

책 인용: '코딩 후 설계 개선이라니 정말 이상한 말이다.' 하지만 시간이 흐르면서 코드는 수정되게 마련이고 시스템의 무결성, 즉 설계에 맞춘 구조는 점점 뒤죽박죽이 되어간다.

리팩터링을 하면 일의 균현이 바뀐다. 처음부터 완벽한 설계를 갖추기보다는 개발을 진행하면서 지속적으로 설계한다. 그 결과 개발의 시작부터 끝날 때까지 프로그램은 줄곧 우수한 설계를 유지한다.

리팩터링의 첫단계는 리팩터링할 코드 영역을 꼼꼼하게 검사해줄 테스트 코드를 마련해야한다. 리팩터링 기법들이 버그 발생 여지를 최소화하도록 구성됐다고는 하나 실제 작업은 사람이 수행하기 때문에 언제든 실수할 수 있다.

1. 코드 분석을 통해 얻은 정보는 휘발성이 강하다. 내 머리속 지우개.. 그렇기 때문에 잊지 않기 위해서는 재빨리 코드에 반영해야한다. 코드 조각을 별도 함수로 추출하는 방식으로 앞서 파악한 정보를 코드에 반영하는 것이다.

이 글을 반문하면 어떤 코드를 봤을 때 잊어버릴 수 있겠다 싶은 내용은 함수를 추출하자! => 함수 추출하기!

2. 함수를 추출하고 나면 추출된 함수 코드를 자세히 들여다 보면서 지금보다 명확하게 표현할 수 있는 간단한 방법을 검토한다. (예시: thisAmount => result 변경) 함수의 반환 값은 항상 result (고민..)를 쓴다. 그러면 그 변수의 역할을 알 수 있다. 테스트하고 커밋!

3. 임시변수를 질의함수로 바꾸기! 매개변수가 루프돌때는 필요하지만 개별적으로 얻을 때는 필요없다..

이 부분은 내용의 이해가 필요했다. 임시 변수들 때문에 로컬 범위에 존재하는 이름이 늘어나서 추출 작업이 복잡해 질 수 있다. 대신 원하는 값을 리턴해주는 함수로 만들어 사용하자. 이게 변수 인라인하기! 변수를 인라인해서 함수 선언 바꾸기

! 즉 의도가 더욱 명확해지는 코드를 짤 수 있게 되었따. 이부분은 추후 더 알아보자

4. 지역변수를 제거해서 얻는 가장 큰 장접은 추출 작업이 훨 씬 쉬워진다는 것이다. 즉 코드를 추출할 때 의존성을 줄임으로써 수정이 용이해진다는 말!

5. 함수 선언 바꾸기!를 할때 이름을 짓는 과정은 쉽지 않다. 그러니 나중에 떠오르면 그때 바꿔도 된다.

6. 반복분쪼개기! 를 통해 반복문을 둘로 나눈다. 그리고 문장 슬라이드하기를 적용해서 변수를 선언하는 문장을 반복문 바로 앞에 옮긴다. 그러면 지역 변수 값 갱신과 관련한 문장을 임시 변수를 질의 함수로 바꾸기! 가 쉬워진다.

- 반복문 쪼개기로 변수 값을 누적시키는 부분을 분리한다.

- 문장 슬라이드하기로 변수 초기화 문장을 변수 값 누적 코드 바로 앞으로 옮긴다.

- 함수 추출하기로 적립 포인트 계산 부분을 별도 함수로 추출한다.

- 변수 인라인하기로 지역 변수를 제거한다

Nextjs14 + jest + msw 도입기

hovinee — Fri, 1 Nov 2024 10:18:57 +0900

이전에 만들었던 서비스는 기능 테스트가 없었음

서비스의 규모가 점점 커짐에 따라 테스트 기능의 필요성을 느꼈고 새로 시작된 프로젝트에서는 테스트의 필요성을 느꼈다. 그러나 유닛 테스트를 하나하나 하기에는 불필요하다 느꼈고 BDD 방법론을 따라 사용자 중심의 통합 테스트를 진행하기로 함.

우선 jest 및 react-testing-library 설치!

https://nextjs.org/docs/app/building-your-application/testing/jest

Testing: Jest | Next.js

Learn how to set up Jest with Next.js for Unit Testing and Snapshot Testing.

nextjs.org

공식문서에 잘 나와있으므로 설치하고 yarn test 실행하여 잘되면 설치 완료!

Tip: 뭔말인지 잘모르겠으면 Quickstart로 레포지토리를 생성하고 설정 파일과 package.json 의존성 패키지만 가져오면 된다.

다음은 msw 설치!

https://www.npmjs.com/package/msw

msw

Seamless REST/GraphQL API mocking library for browser and Node.js.. Latest version: 2.6.0, last published: 3 days ago. Start using msw in your project by running `npm i msw`. There are 343 other projects in the npm registry using msw.

www.npmjs.com

Nextjs는 ssr을 지원하기 때문에 mocking할 때 server와 client 설정을 분리해야된다. 하지만 이건 test가 아닌 페이지에서 api를 모킹해야 될때고 테스트용도라면 client는 필요없다. nodejs 환경이기 때문에! 여러 블로그 등을 찾아보다보니 혼동이 생겨서 주의!

server.ts

import { setupServer } from 'msw/node'
import { handlers } from './handler'

export const server = setupServer(...handlers)

handler.ts

// src/shared/api/mocks/handler.ts
import { http, HttpResponse } from 'msw'
import { MOCKDATA } from './data'

export const handlers = [
  http.get('https://examples.com/meta/room-info/all', () => {
    return HttpResponse.json(MOCKDATA)
  }),
]

data.ts

export const MOCKDATA = {
  success: true,
  worlds: [
    {
      id: '1',
      hostId: 'host123',
      mapType: 'Plaza',
      title: 'Virtual Plaza',
      desc: 'A beautiful virtual plaza for social gatherings.',
      customObjectInfos: [],
    },
    {
      id: '2',
      hostId: 'host456',
      mapType: 'Meeting',
      title: 'Meeting Room A',
      desc: 'Private meeting room for teams.',
      customObjectInfos: [],
    },
  ],
}

앞에서 말했듯 broswer과 index는 test가 아닌 브라우저에서 사용할 때 필요함!

이제 부터 중요!!

nextjs에서 msw를 사용할 때 따로 해주어야할 설정이 있다! jest 2.xx 버전을 사용할 경우

const nextJest = require('next/jest')

const createJestConfig = nextJest({
  // Provide the path to your Next.js app to load next.config.js and .env files in your test environment
  dir: './',
})

// Add any custom config to be passed to Jest
const customJestConfig = {
  setupFilesAfterEnv: ['<rootDir>/jest.setup.js'],
  testEnvironment: 'jest-fixed-jsdom', //ReferenceError: TextEncoder is not defined
  testEnvironmentOptions: {
    customExportConditions: [''],
  }, //Cannot find module ‘msw/node’ (JSDOM)
}

// createJestConfig is exported this way to ensure that next/jest can load the Next.js config which is async
module.exports = createJestConfig(customJestConfig)

npm jest-fixed-jsdom 설치 후 수정

또한 cannot find module 'msw/nodw'가 나올 경우 testEnviromentOptions 추가 해주면 된다. 이유는 아래와 같다.

그럼 설정은 끝났다.

import { render, screen } from '@testing-library/react'
import '@testing-library/jest-dom'
import { server } from 'shared/api/mocks/server'
import { WorldPreview } from 'entities/world/world-preview'
import { WorldDetails } from 'shared/api/world'
import userEvent from '@testing-library/user-event'

import mockRouter from 'next-router-mock'
import { MemoryRouterProvider } from 'next-router-mock/MemoryRouterProvider'

jest.mock('next/router', () => jest.requireActual('next-router-mock'))

describe('HomePage Component', () => {
  beforeAll(() => server.listen())
  afterEach(() => server.resetHandlers())
  afterAll(() => server.close())

  it('월드리스트 보여주고 클릭시 해당 페이지 라우팅', async () => {
    // `Home` 컴포넌트 렌더링
    const response = await fetch('https://examples.com/meta/room-info/all')
    const data = await response.json()

    render(
      <div>
        {data.worlds.map((world: WorldDetails) => (
          <WorldPreview key={world.id} world={world} />
        ))}
      </div>,
      { wrapper: MemoryRouterProvider },
    )

    expect(screen.getByText('Virtual Plaza')).toBeInTheDocument()
    expect(screen.getByText('Meeting Room A')).toBeInTheDocument()

    // `data-testid`를 가진 링크 요소를 찾기
    const linkElement = screen.getByTestId(`world-${data.worlds[0].id}`)

    // 링크 클릭
    await userEvent.click(linkElement)

    // 클릭 시 페이지 라우팅
    expect(mockRouter.asPath).toEqual(
      `/world/${data.worlds[0].id}?mapType=${data.worlds[0].mapType}`,
    )
  })
})

아래처럼 처음 페이지 진입시 모킹 데이터를 통해 원하는 텍스트가 있는지 확인하고 next-router-mock을 설치하여 링크 클릭시 원하는 링크로 진입하는 것까지 확인했다. 생각보다 삽질을 많이했지만 앞으로는 안정성있는 서비스를 위해 통합테스트를 실행해야겠다..

***번외 if 서버컴포넌트에서 데이터를 모킹하고 싶다면?

nextjs에서는 다음과 같은 설정을 해야된다.

1. root 부분에 instrumentation.ts 파일을 만들고 해당 코드 입력

//test가 아닌 page에서 모킹할 때
export async function register() {
  if (process.env.NEXT_RUNTIME === 'nodejs') {
    const { server } = await import('shared/api/mocks/server')
    server.listen({ onUnhandledRequest: 'bypass' })
  }
}

2. next.config.mjs에 아래와 같이 설정

3. 서비스 워커 설치

npx msw init public/ --save

실행결과로 데이터가 잘들어온다.

[프로그래머스] 삼총사 - 브루트포스(완전탐색)

hovinee — Mon, 7 Oct 2024 18:53:38 +0900

문제설명

문제해결

function solution(number) {
    var answer = 0;
  
    // 첫 번째 학생 선택
    for (let i = 0; i < number.length - 2; i++) {
        // 두 번째 학생 선택
        for (let j = i + 1; j < number.length - 1; j++) {
            // 세 번째 학생 선택
            for (let k = j + 1; k < number.length; k++) {
                // 세 학생의 번호 합이 0인지 확인
                if (number[i] + number[j] + number[k] === 0) {
                    answer++;
                }
            }
        }
    }
    return answer;
}

[프로그래머스] 크기가 작은 부분 문자열 - 슬라이딩 윈도우

hovinee — Fri, 4 Oct 2024 19:01:32 +0900

문제 설명

문제 풀이

function solution(t, p) {
    let count = 0;
    let pLen = p.length;
    let pNum = parseInt(p); // p를 숫자로 변환
    
    for (let i = 0; i <= t.length - pLen; i++) {
        let subStr = t.slice(i, i + pLen); // t에서 p와 같은 길이의 부분 문자열 추출
        let subNum = parseInt(subStr); // 부분 문자열을 숫자로 변환
        
        if (subNum <= pNum) {
            count++; // p보다 작거나 같으면 카운트
        }
    }
    
    return count;
}

console.log(solution("3141592", "271")); // 출력: 2