ousterhout-build-deep

SKILL.md

---
name: ousterhout-build-deep
description: 코드를 작성하거나 변경할 때, 작업 완료를 호출하기 전에, 변경 사항이 내보내거나 가져올 수 있는 이름을 추가하거나, 모듈, 클래스, 컴포넌트, 헬퍼, 훅, 서비스 또는 래퍼를 생성하거나, 반복되는 코드를 중앙 집중화할 때 사용하세요. 깊이 있는 모듈을 구축하기 위한 작성자 시점 체크리스트: 경계가 숨기는 결정을 명명하고, 깊이와 불변성 테스트를 통과하며, 문제를 옮기지 말고 해결하고, 크기만으로 분할하지 말고, 짧은 설계 노트로 마무리하세요. ousterhout-quality-program의 간결한 동반자로, 이는 전체 검토 렌즈로 남아 있습니다.
---

# Build it deep (Ousterhout, author-time)

당신은 코드를 검토하는 것이 아니라 작성하고 있습니다. 작업을 완료했다고 부르기 전에 자신의 변경 사항에 대해 이것을 실행하세요.

## 1. Gate

변경 사항이 내보내기/가져오기 가능한 이름을 추가하거나, 모듈, 클래스, 컴포넌트, 헬퍼, 훅, 서비스 또는 래퍼를 생성하거나 반복된 코드를 중앙 집중화합니까? 그렇지 않으면 이 스킬을 건너뛰세요. 이름 변경, 코드모드, 구성/데이터 편집 및 한 줄 수정은 예외입니다.

## 2. 경계를 작성하기 전에

- 이 저장소가 이미 이 형태의 문제를 어떻게 해결하는지 찾아보고, 그렇지 않은 이유를 명확히 말할 수 없다면 그것을 따르세요. 의존성의 현재 문서와 타입을 읽으세요: 기억에서 떠올린 API는 주장일 뿐 출처가 아닙니다.
- 인터페이스 주석을 먼저 작성하세요: 무엇을 약속하는지, 무엇을 숨기는지. 숨겨진 결정(포맷, 정책, 규칙, 스키마 선택)을 이름 붙일 수 없다면 경계는 존재해서는 안 됩니다. 인라인으로 작성하세요.
- 도메인 언어로 이름을 지으세요. 유일하게 정직한 이름이 `utils`, `helpers` 또는 `manager`라면, 경계가 잘못된 위치에 있는 것입니다.

## 3. 두 가지 테스트

- **깊이.** 인터페이스는 노출하는 것보다 훨씬 더 많은 것을 숨겨야 합니다. 인자를 그대로 전달하는 래퍼는 이득 없는 비용입니다; 삭제하세요.
- **불변성.** 공유 규칙을 보호할 때만 공유 코드를 추출하세요. 증거는 함께 변경된 이력입니다: 복사본들이 함께 수정되거나 변경되었습니다. 독립적으로 변경되는 유사 코드는 중복 상태로 남겨두세요.

## 4. 수정은 문제를 제거해야 하며, 위치를 옮기면 안 됩니다

- 여섯 개의 캐스트를 하나의 제네릭 캐스트 헬퍼로 옮겨도 여전히 여섯 개의 캐스트입니다. 캐스트가 감추던 타입 매퍼를 작성하세요.
- 호출자가 당신이 모르는 무언가를 정말 알고 있지 않는 한, 결정을 호출자에게 미루는 매개변수나 플래그를 추가하지 마세요. 어려운 경우는 내부에서 흡수하세요.
- 모든 호출자가 처리하게 하기보다 오류가 발생할 수 없는 의미론을 선호하세요.
- 필수 도메인 복잡성을 다른 파일로 옮기는 것은 단순화가 아닙니다.

## 5. "이 부분을 정리하세요" 또는 "이 파일이 너무 크다"는 압박 아래

크기만으로 분할하지 마세요. 하나의 400줄 모듈이 하나의 결정을 숨기는 것이 네 개의 100줄 모듈이 같은 결합을 노출하는 것보다 낫습니다. 각 분할이 어떤 결정을 숨기는지 물어보세요; 없다면 분할하지 마세요.

## 6. 안전성

기존 코드: 깊게 만들기 전에 현재 동작을 테스트로 고정하세요. 새 코드: 의도한 동작을 정의하는 테스트를 작성하세요.

## 7. 보고

Gate가 작동했다면, 최종 메시지 끝에 2-4줄의 설계 노트를 남기세요: 추가한 각 경계와 숨긴 결정; 의도적으로 남긴 중복과 그 이유; 수용한 얕은 부분과 그 이유.

논쟁 중인 판단이나 전체 리뷰의 경우 `ousterhout-quality-program`을 로드하세요.

태그