타입-shaped 사고

"충분한 TypeScript 후, 코드 쓰기 전 타입으로 설계 시작. 그건 버그 아냐; 업그레이드."

전환

대부분 프로그래머가 JavaScript 에서 TypeScript 와 와서 타입을 '진짜' 코드 위의 장부 정리 layer 로 다룸. Annotation 이 세금; inference 가 안도. 마인드셋이 '나 우연히 type-check 되는 JavaScript 써'.

충분한 TypeScript 후 마인드셋이 뒤집힘. 타입이 design surface 됨. 먼저 타입으로 데이터 모양과 함수 사이 관계 스케치 — 그다음 contract 가 이미 그려져서 구현이 자리잡음.

실전에서 어떻게 보이나

새 기능 설계하며 물어:

이게 작동하는 데이터의 모양? (타입.)
이게 있을 수 있는 합법 상태? (Discriminated union.)
Public API surface? (함수 signature set.)
유지해야 할 invariant? (Narrowing 체크 어디 살아야?)

답이 타입. 한 번 타입 붙으면 구현이 대부분 기계적. 어려운 사고가 타입 레벨에서 됨.

OOP universe 와 타입-shaped 사고

아빠의 'OOP 가 universe operating principle' 가 여기 적용. Class 로 세상 모델링 할 때 쓸 원칙들 — inheritance, polymorphism, encapsulation, abstraction — 이 타입에 나타나: intersection 통한 extension, generic 통한 polymorphism, `private`/`#private` 통한 encapsulation, interface 통한 abstraction. TypeScript 가 OOP 와 경쟁 아냐; 같은 원칙을 type layer 에 encoding.

타입-shaped 사고가 업그레이드. JavaScript-with-types 가 entry point; TypeScript-as-design-language 가 목적지. 1년 TypeScript 쓴 대부분이 사이 어딘가. 둘 다 유효; 목적지가 더 깊은 거.

Code

타입-first 설계·typescript

// Imperative-first 사고 — 구현이 타입 driving.
function loadConversation(id: string): unknown {
  // ... 코드 쓰고, 가면서 타입 알아냄
  return result;
}

// 타입-first 사고 — 설계가 구현 driving.
type ConversationLoadResult =
  | { status: 'success'; conversation: Conversation }
  | { status: 'not-found' }
  | { status: 'error'; error: Error };

async function loadConversation(id: string): Promise<ConversationLoadResult> {
  // 구현이 3 모양 중 하나 만들어야 — body 전에 놓임.
  try {
    const c = await fetchConversation(id);
    return c
      ? { status: 'success', conversation: c }
      : { status: 'not-found' };
  } catch (error) {
    if (error instanceof Error) return { status: 'error', error };
    return { status: 'error', error: new Error('unknown') };
  }
}

// Caller 가 discriminator 에 switch 하고 각 case 처리.
function render(r: ConversationLoadResult) {
  switch (r.status) {
    case 'success': return r.conversation.title;
    case 'not-found': return 'Not found';
    case 'error': return r.error.message;
  }
}

Exercise

작은 새 기능 (parser, state machine, 작은 CRUD 연산) 골라. 20분을 타입 설계에 — 구현 없음, 타입만. 그다음 구현. 반대로 했을 시간과 비교.

Hint

잘-bounded 된 대부분 기능엔 타입-first 가 총 시간 대략 절반으로 잘라 — 구현이 dead end 적어서. 타입이 너가 그것들 의존하는 코드 쓰기 전 설계 이슈 잡음.

전환

실전에서 어떻게 보이나

OOP universe 와 타입-shaped 사고

Code

External links

Exercise

Progress

댓글 0