concrete-first, 예측해서 일반화 안 해

"눈앞의 진짜 것을 지어. 추상은 두 번째 진짜 것에서 자리를 벌게 둬 — 추측에서가 아니라."

네가 걸어온 척추

이 퀘스트 모든 트랙에서 규칙 하나가 조용히 하중을 받아왔고, 이제 이름을 붙여: concrete-first, 예측해서 일반화 안 함. 눈앞의 구체적이고 진짜인 케이스를 지어. 일반적이고 유연하고 future-proof 한 버전은 두 번째 구체 케이스가 추상을 존재하게 강제하기 전엔 안 지어. 예측성 일반성은 미래에 대한 추측이고, 미래 추측은 보통 틀리고 늘 비싸.

어디에나 나타났어

이 퀘스트에서 concrete-first 가 나타난 곳:
  Track 4  진짜 클라이언트 하나(UI)를 위해 API 설계, 상상 말고
  Track 5  MIR 을 parts 로 감싸; 아직 필요 없는 framework 안 지음
  Track 7  forcing function 까지 web; 두 번째 컨슈머까지 dev Vite
  Track 8  v1 의 구체 scope 출하; 추측성 절반 미룸

네 개의 다른 결정, 하나의 원칙. 매번 유혹적인 수는 일반 버전을 미리 짓는 거였어 — provider-중립 API, MIR framework, production 파이프라인, 기능-완비 v1 — 그리고 매번 규율은 구체적인 것만 짓고 일반성이 진짜 두 번째 케이스를 기다리게 두는 거였어.

필요할 때 특수화해

긍정형은 '필요할 때 특수화' 야. 추상을 미리 짓지 마; 구체적인 걸 잘 짓고, 구조를 진짜 공유하는 두 번째 진짜 케이스가 나타나면 그제야 상상한 하나가 아니라 진짜 둘에서 추상을 추출해. 진짜 두 케이스에서 증류한 추상은 거의 항상 맞고; 첫 케이스가 끝나기도 전에 추측한 추상은 거의 항상 틀리고 늘 비싸. Bonfire 는 끝까지 concrete-first 고 — 그래서 더 야심 찬 전작이 얼어붙는 동안 진짜 v1 을 냈어.

Code

규칙 하나, 여러 얼굴, 퀘스트 전반·text

이 퀘스트에서 concrete-first 가 나타난 곳:
  Track 4  진짜 클라이언트 하나(UI)를 위해 API 설계, 상상 말고
  Track 5  MIR 을 parts 로 감싸; 아직 필요 없는 framework 안 지음
  Track 7  forcing function 까지 web; 두 번째 컨슈머까지 dev Vite
  Track 8  v1 의 구체 scope 출하; 추측성 절반 미룸

# 필요할 때 특수화. 추상을 진짜 TWO 케이스에서 추출,
# 상상한 ONE 에서 절대 아님.

Exercise

네 코드에서 진짜 유저가 딱 하나(호출자 하나, 구현 하나, 설정 하나)인 추상을 찾아. 정직하게 물어: 진짜 반복에서 추출됐어, 아니면 안 온 두 번째 케이스를 예측해서 지어졌어? 예측성이면, 구체 케이스로 인라인해 되돌리는 비용이 뭐고 — 네가 실제로 돈 낸 유연성이 뭐였어?

Hint

유저가 하나인 추상은 검증 안 된 추측이야. 가끔 그 추측이 싼 보험이고; 종종 보상 없는 복잡성이야. 표시는 그걸 정당화할 진짜 두 번째 케이스가 실제로 나타났느냐야.