ousterhout-build-deep

SKILL.md

---
name: ousterhout-build-deep
description: Verwenden Sie dies beim Schreiben oder Ändern von Code, bevor Sie die Aufgabe als erledigt markieren, immer wenn die Änderung einen exportierten oder importierbaren Namen hinzufügt, ein Modul, eine Klasse, Komponente, Hilfsfunktion, Hook, Dienst oder Wrapper erstellt oder wiederholten Code zentralisiert. Checkliste zur Autorzeit für das Erstellen tiefgehender Module: Benennen Sie die Entscheidung, die die Grenze verbirgt, bestehen Sie die Tiefen- und Invarianztests, beheben Sie Probleme, anstatt sie zu verlagern, teilen Sie niemals nur nach Größe auf und schließen Sie mit einer kurzen Designnotiz ab. Kompakter Begleiter zu ousterhout-quality-program, das die vollständige Überprüfungslinse bleibt.
---

# Build it deep (Ousterhout, author-time)

Du schreibst Code, nicht überprüfst ihn. Führe dies an deiner eigenen Änderung aus, bevor du die Aufgabe als erledigt betrachtest.

## 1. Gate

Fügt die Änderung einen exportierten/importierbaren Namen hinzu, erstellt ein Modul, eine Klasse, eine Komponente, einen Helfer, Hook, Service oder Wrapper oder zentralisiert wiederholten Code? Wenn nein, überspringe diese Fähigkeit. Umbenennungen, Codemods, Konfigurations-/Datenänderungen und Einzeiler-Fixes sind ausgenommen.

## 2. Bevor du die Grenze schreibst

- Finde heraus, wie dieses Repository bereits ein Problem dieser Art löst, und folge dem, es sei denn, du kannst begründen, warum nicht. Lies die aktuellen Dokumentationen und Typen der Abhängigkeit: eine aus dem Gedächtnis abgerufene API ist eine Behauptung, keine Quelle.
- Schreibe zuerst den Interface-Kommentar: was es verspricht, was es verbirgt. Wenn du die verborgene Entscheidung (ein Format, eine Richtlinie, eine Regel, eine Schema-Wahl) nicht benennen kannst, sollte die Grenze nicht existieren. Füge sie inline ein.
- Benenne es in der Fachsprache. Wenn der einzige ehrliche Name `utils`, `helpers` oder `manager` ist, liegt der Schnitt an der falschen Stelle.

## 3. Zwei Tests

- **Tiefe.** Das Interface muss wesentlich mehr verbergen, als es offenlegt. Ein Wrapper, der seine Argumente nur weiterreicht, ist ein Kostenfaktor ohne Nutzen; lösche ihn.
- **Invariant.** Extrahiere gemeinsamen Code nur, wenn er eine gemeinsame Regel schützt. Der Beweis ist das gemeinsame Ändern: die Kopien wurden in der Historie zusammen korrigiert oder geändert. Ähnliche, die unabhängig geändert werden, bleiben dupliziert.

## 4. Ein Fix muss das Problem entfernen, nicht verlagern

- Sechs Casts, die in einen generischen Cast-Helfer verschoben wurden, sind immer noch sechs Casts. Schreibe den typisierten Mapper, den die Casts nur überdeckt haben.
- Füge keinen Parameter oder Flag hinzu, der eine Entscheidung auf die Aufrufer abwälzt, es sei denn, die Aufrufer wissen wirklich etwas, das du nicht weißt. Nimm den schwierigen Fall intern auf.
- Bevorzuge Semantik, bei der der Fehlerfall nicht auftreten kann, anstatt jeden Aufrufer damit umgehen zu lassen.
- Wesentliche Domänenkomplexität in eine andere Datei zu verschieben ist keine Vereinfachung.

## 5. Unter Druck von "räum das auf" oder "diese Datei ist zu groß"

Teile niemals nur wegen der Größe auf. Ein 400-Zeilen-Modul, das eine Entscheidung verbirgt, ist besser als vier 100-Zeilen-Module, die dieselben Verknüpfungen durchsickern lassen. Frage, welche Entscheidung jeder Schnitt verbirgt; wenn keine, dann teile nicht.

## 6. Sicherheit

Bestehender Code: sichere das aktuelle Verhalten mit einem Test, bevor du es vertiefst. Neuer Code: schreibe den Test, der das beabsichtigte Verhalten definiert.

## 7. Bericht

Wenn das Gate ausgelöst wurde, beende deine abschließende Nachricht mit einer 2-4-zeiligen Designnotiz: jede hinzugefügte Grenze und die Entscheidung, die sie verbirgt; Duplikate, die du absichtlich belassen hast und warum; alles Oberflächliche, das du akzeptiert hast und warum.

Für einen umstrittenen Aufruf oder eine vollständige Überprüfung lade `ousterhout-quality-program`.

Tags