From f3686d1751525d5ce4559ab82ca16219995a3772 Mon Sep 17 00:00:00 2001 From: azure-553 Date: Tue, 26 May 2026 10:04:12 +0900 Subject: [PATCH 1/2] =?UTF-8?q?fix:=20=EB=9D=84=EC=96=B4=EC=93=B0=EA=B8=B0?= =?UTF-8?q?=20=EB=B0=8F=20=EC=96=B4=EC=83=89=ED=95=9C=20=EB=AC=B8=EA=B5=AC?= =?UTF-8?q?=20=EB=8B=A4=EB=93=AC=EA=B8=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/growth/1-refactoring.mdx | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/growth/1-refactoring.mdx b/docs/growth/1-refactoring.mdx index 824de95..c0e1218 100644 --- a/docs/growth/1-refactoring.mdx +++ b/docs/growth/1-refactoring.mdx @@ -195,7 +195,7 @@ export function formatFullName(name: UserName): string { - 이름 개선: `formatUser`는 "유저 객체 전체를 포맷한다"고 읽히지만 실제로는 이름만 다룬다. `formatFullName`으로 바꾸면 함수가 하는 일이 이름에서 바로 보인다. - 타입 추가: `UserName` 인터페이스가 "이 함수에 필요한 최소 데이터"를 명시한다. `user` 전체를 받지 않으므로, 다른 컨텍스트(주문자 이름, 배송 수신인 등)에서도 재사용 가능하다. -- 테스트 가능 구조: `User` 엔티티 전체를 만들 필요 없이 `{ firstName, lastName }` 만 넘기면 테스트할 수 있다. 의존하는 데이터가 최소화되어 테스트 설정이 단순해진다. +- 테스트 가능 구조: `User` 엔티티 전체를 만들 필요 없이 `{ firstName, lastName }`만 넘기면 테스트할 수 있다. 의존하는 데이터가 최소화되어 테스트 설정이 단순해진다. #### 심화 미션 — A vs A' 비교 (calculatePrice) @@ -250,7 +250,7 @@ function calculatePrice(order: { items: { price: number; qty: number }[]; coupon **1. 가장 먼저 할 작업 — "안전망 확보"** -테스트 없이 구조를 바꾸면 기존 동작이 깨졌는지 알 수 없다. 현재 동작을 고정하는 **특성화 테스트(Characterization Test)** 를 먼저 작성한다. 입력→출력 쌍을 실제로 돌려보고 스냅샷으로 잡아두는 방식이며, "올바른 동작"이 아니라 "현재 동작"을 기록하는 것이 목적이다. +테스트 없이 구조를 바꾸면 기존 동작이 깨졌는지 알 수 없다. 현재 동작을 고정하는 **특성화 테스트(Characterization Test)**를 먼저 작성한다. 입력→출력 쌍을 실제로 돌려보고 스냅샷으로 잡아두는 방식이며, "올바른 동작"이 아니라 "현재 동작"을 기록하는 것이 목적이다. **2. 절대 하면 안 되는 작업 — "한 번에 대규모 재작성"** @@ -293,7 +293,7 @@ function calculatePrice(order: { items: { price: number; qty: number }[]; coupon **반복(Iteration)**: 한 번의 최적화로 목표를 달성하는 경우는 드물고, 여러 작은 개선을 누적해야 하며 시도한 최적화의 절반 이상은 효과가 없거나 오히려 성능을 악화시킬 수 있어요. -**코드 튜닝 접근 순서**: 올바르게 동작하는 코드 작성 → 성능 저하 확인 → 핫스팟 측정 → 설계·알고리즘 문제 여부 판단 → 코드 튜닝 → 개선 효과 측정 → 효과 없으면 원래 코드로 복원의 순서를 지켜야 해요. +**코드 튜닝 접근 순서**: 올바르게 동작하는 코드 작성 → 성능 저하 확인 → 핫스팟 측정 → 설계·알고리즘 문제 여부 판단 → 코드 튜닝 → 개선 효과 측정 → 효과가 없으면 원래 코드로 복원하는 순서를 지켜야 해요. Date: Tue, 26 May 2026 10:14:11 +0900 Subject: [PATCH 2/2] fix: lint error --- docs/growth/1-refactoring.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/growth/1-refactoring.mdx b/docs/growth/1-refactoring.mdx index c0e1218..f710631 100644 --- a/docs/growth/1-refactoring.mdx +++ b/docs/growth/1-refactoring.mdx @@ -472,7 +472,7 @@ const exists = set.has(target); // O(1) 평균 | 단계 | 도구 | 측정 항목 | | ----------- | ----------------------------------- | -------------------------------------- | -| 렌더 성능 | React Profiler | 커밋당 렌더 시간, 렌더된 컴포넌트 수 | +| 렌더 성능 | React Profiler | 커밋당 렌더 시간, 렌더된 컴포넌트 수 | | 입력 반응성 | DevTools Performance | 키 입력 → 화면 갱신까지의 총 시간(INP) | | 필터 연산 | `console.time` / `performance.mark` | 필터 함수 실행 시간(ms) |