ousterhout-build-deep

SKILL.md

---
name: ousterhout-build-deep
description: Usa durante la scrittura o la modifica del codice, prima di considerare il compito completato, ogni volta che la modifica aggiunge un nome esportato o importabile, crea un modulo, una classe, un componente, un helper, un hook, un servizio o un wrapper, o centralizza codice ripetuto. Checklist per l'autore per costruire moduli profondi: nomina la decisione che il confine nasconde, supera i test di profondità e invarianza, risolvi i problemi invece di spostarli, non dividere mai solo in base alla dimensione e termina con una breve nota di design. Compagno compatto di ousterhout-quality-program, che rimane la lente completa di revisione.
---

# Build it deep (Ousterhout, author-time)

Stai scrivendo codice, non revisionandolo. Esegui questo sulla tua modifica prima di dichiarare il compito completato.

## 1. Gate

La modifica aggiunge un nome esportato/importabile, crea un modulo, una classe, un componente, un helper, un hook, un servizio o un wrapper, oppure centralizza codice ripetuto? Se no, salta questa skill. Rinominazioni, codemodifiche, modifiche a configurazioni/dati e correzioni di una riga sono esenti.

## 2. Prima di scrivere il confine

- Trova come questo repository risolve già un problema di questa forma e seguilo a meno che tu non possa spiegare perché no. Leggi la documentazione e i tipi correnti della dipendenza: un'API richiamata a memoria è un'affermazione, non una fonte.
- Scrivi prima il commento dell'interfaccia: cosa promette, cosa nasconde. Se non riesci a nominare la decisione nascosta (un formato, una politica, una regola, una scelta di schema), il confine non dovrebbe esistere. Inseriscilo inline.
- Nominalo nel linguaggio del dominio. Se l'unico nome onesto è `utils`, `helpers` o `manager`, il taglio è nel posto sbagliato.

## 3. Due test

- **Profondità.** L'interfaccia deve nascondere sostanzialmente più di quanto espone. Un wrapper che inoltra i suoi argomenti è un costo senza beneficio; eliminalo.
- **Invariante.** Estrai codice condiviso solo quando protegge una regola condivisa. La prova è la co-modifica: le copie sono state corrette o modificate insieme nella storia. Somiglianze che cambiano indipendentemente restano duplicate.

## 4. Una correzione deve rimuovere il problema, non spostarlo

- Sei cast spostati in un helper generico per cast sono ancora sei cast. Scrivi il mapper tipizzato che i cast stavano mascherando.
- Non aggiungere un parametro o flag che spinga una decisione sui chiamanti a meno che i chiamanti non sappiano davvero qualcosa che tu non sai. Assorbi il caso difficile all'interno.
- Preferisci semantiche dove il caso di errore non può sorgere piuttosto che far gestire ogni chiamante.
- Spostare complessità essenziale del dominio in un altro file non è semplificazione.

## 5. Sotto pressione di "pulisci questo" o "questo file è troppo grande"

Non dividere mai solo per dimensione. Un modulo da 400 righe che nasconde una decisione batte quattro moduli da 100 righe che perdono le stesse giunzioni. Chiedi quale decisione nasconde ogni divisione; se nessuna, non dividere.

## 6. Sicurezza

Codice esistente: blocca il comportamento attuale con un test prima di approfondirlo. Codice nuovo: scrivi il test che definisce il comportamento previsto.

## 7. Report

Se il gate è scattato, termina il tuo messaggio finale con una nota di design di 2-4 righe: ogni confine che hai aggiunto e la decisione che nasconde; duplicazioni lasciate intenzionalmente e perché; qualsiasi superficialità accettata e perché.

Per una chiamata contestata o una revisione completa, carica `ousterhout-quality-program`.

Tag