Skip to content

docs: 챕터 7~9장을 다듬어요. #22

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
azure-553 merged 1 commit into from
May 26, 2026
Merged

docs: 챕터 7~9장을 다듬어요. #22

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions docs/good-code/1-routines.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';

## 📝 묶음 요약

7~9장은 "코드 한 단위를 어떻게 잘 만들 것인가"를 세 각도로 좁혀 들어가는 묶음이에요. 7장은 좋은 루틴(함수)의 기준을, 8장은 그 루틴이 외부와 만나는 경계에서의 방어 전략을, 9장은 코딩에 들어가기 전 의사코드로 설계를 검증하는 절차를 다뤄요.
7~9장은 "코드 한 단위를 어떻게 잘 만들 것인가"를 세 관점으로 좁혀 들어가는 묶음이에요. 7장은 좋은 루틴(함수)의 기준을, 8장은 그 루틴이 외부와 만나는 경계에서의 방어 전략을, 9장은 코딩에 들어가기 전 의사코드로 설계를 검증하는 절차를 다뤄요.

- 7장 — 추상화 수준을 맞추고 부작용 경계를 분명히 하라는 원칙은 함수형 컴포넌트와 커스텀 훅에서도 그대로 통해요.
- 8장 — "어디까지 방어할 것인가"는 TypeScript와 Zod가 깔린 환경에서 답이 달라져요. 모든 곳이 아니라 경계에서만 검증하는 바리케이드 전략이 필요해요.
Expand Down Expand Up @@ -120,8 +120,8 @@ export async function loadAndShapePayments(

**Before의 문제**

- URL 조립(How) 과 데이터 패칭(What) 이 같은 줄에 있다. encodeURIComponent, 쿼리 문자열 직접 결합은 "어떻게 요청을 보내는가"이고, 함수의 목적은 "결제 내역을 가져온다"이다.
- 배열 필터링(How) 과 뷰 변환(How) 이 패칭 직후에 한 덩어리로 이어진다. "무엇을 하는가"(필터 → 검색 → 포맷)가 구현 디테일에 묻힌다.
- URL 조립(How)과 데이터 패칭(What)이 같은 줄에 있다. encodeURIComponent, 쿼리 문자열 직접 결합은 "어떻게 요청을 보내는가"이고, 함수의 목적은 "결제 내역을 가져온다"이다.
- 배열 필터링(How)과 뷰 변환(How)이 패칭 직후에 한 덩어리로 이어진다. "무엇을 하는가"(필터 → 검색 → 포맷)가 구현 디테일에 묻힌다.

##### After ✅

Expand Down Expand Up @@ -200,7 +200,7 @@ export async function loadPayments(params: PaymentQuery): Promise<PaymentView[]>

**개선 포인트**

- loadPayments의 본문 4줄만 읽으면 "패칭 → 상태 필터 → 이름 검색 → 뷰 변환"이라는 흐름(What) 이 바로 보인다.
- loadPayments의 본문 4줄만 읽으면 "패칭 → 상태 필터 → 이름 검색 → 뷰 변환"이라는 흐름(What)이 바로 보인다.
- 각 하위 함수가 How를 캡슐화하여, loadPayments는 추상화 수준이 균일하다.
- 파라미터 4개 나열 → PaymentQuery 객체로 묶어서 순서 실수를 방지하고, query/status/page에 기본값 정책이 명시됨.

Expand Down Expand Up @@ -384,7 +384,7 @@ async function handleRefund(paymentId: string, amount: number) {

### 📖 원문 핵심

**방어적 프로그래밍의 전제**: 프로그램에 잘못된 데이터가 들어와도 손상되지 않아야 한다는 아이디어로, "garbage in, garbage out"은 오늘날 기준으로 허술하고 불안전한 프로그램의 징표예요.
**방어적 프로그래밍의 전제**: 프로그램에 잘못된 데이터가 들어와도 손상되지 않아야 한다는 아이디어로, "garbage in, garbage out"은 오늘날 기준으로 허술하고 안전하지 않은 프로그램의 징표예요.

**Assertion(단언문)**: 개발 중에 코드가 스스로를 검증하는 수단으로, 절대 발생해서는 안 되는 조건을 체크하며 전제조건과 사후조건을 문서화하는 실행 가능한 명세 역할을 해요. Assertion은 버그를 잡는 것이고 에러 처리 코드는 예상 가능한 이상 상황을 처리하는 것으로, 둘은 목적이 다르므로 혼용해서는 안 돼요.

Expand Down Expand Up @@ -444,7 +444,7 @@ function RefundForm() {

- 빈 문자열 → Number("") → 0 → 0원 환불 요청
- 문자 입력 → Number("abc") → NaN → 서버에 NaN 전송
- 음수 입력 → 1000 → 마이너스 환불
- 음수 입력 → -1000 → 마이너스 환불
- 결제 금액 초과 → 한도 없이 아무 금액이나 전송

##### After ✅
Expand Down Expand Up @@ -872,7 +872,7 @@ experience=""
<MemberOpinion
author="zinii"
emoji="🐣"
opinion={`UI 오류는 Error Boundary — 실패할 경우 대체 UI를 보여줄 수 있으니까. 네트워크 오류는 try/catch — 네트워크 응답값의 상태 기반이니까.`}
opinion={`UI 오류는 Error Boundary — 실패할 경우 대체 UI를 보여줄 수 있기 때문에. 네트워크 오류는 try/catch — 네트워크 응답값의 상태 기반이기 때문에.`}
experience=""
/>

Expand Down
Loading