Facile da mantenere

Ci assicuriamo che la struttura delle cartelle sia la prima cosa che un futuro sviluppatore giudicherà. Vengono utilizzate strutture di cartelle coerenti e con opinioni (ad es., src/components, src/services, src/hooks, src/features).

Scriviamo codice per gli esseri umani, non solo per il compilatore. Vengono seguite convenzioni di denominazione e modelli coerenti in tutti i progetti. ESLint e Prettier sono configurati per applicare la formattazione tramite pre-commit hooks come Husky, garantendo la qualità del codice fin dall'inizio. Diamo priorità ai linguaggi tipizzati, utilizzando TypeScript invece di JavaScript per una migliore manutenibilità. Manteniamo sempre il codice leggibile e gestibile, concentrato e ridotto.

Evitiamo il caos del design codificando le decisioni di design in componenti di codice riutilizzabili. Vengono utilizzati sistemi di componenti consolidati come ShadCN, Tailwind UI o Material UI per garantire coerenza tra i progetti. Questo approccio aiuta a evitare di scrivere codice UI una tantum a meno che non sia assolutamente necessario, risparmiando tempo e garantendo coerenza nel design.

Ci assicuriamo che la logica aziendale non appartenga mai al livello UI. Vengono utilizzati livelli di servizio, hook personalizzati o moduli controller per isolare e organizzare correttamente la logica aziendale. Per le interazioni API, vengono implementati modelli moderni di recupero dei dati utilizzando SWR, React Query o wrapper personalizzati che gestiscono in modo efficiente la memorizzazione nella cache e gli stati di errore. Tutte le chiamate API sono astratte in cartelle di servizio dedicate, come services/api/user.ts, rendendo il codice più manutenibile e testabile.

Non scriviamo romanzi—solo quanto basta per integrare rapidamente il prossimo sviluppatore. README.md è sempre scritto con istruzioni di configurazione, variabili d'ambiente, istruzioni di distribuzione. Vengono aggiunti commenti brevi per logiche complesse (non esagerare con i commenti). TSDoc / JSDoc sono utilizzati per i metodi pubblici. Un CONTRIBUTING.md è aggiunto per come eseguire i test / convenzioni.

Non abbiamo bisogno del 100% di copertura, ma abbiamo bisogno di una copertura completa dove il fallimento è costoso. I test unitari sono prioritari per le funzioni critiche per il business. I test di integrazione sono utilizzati per gli endpoint API o i flussi di lavoro. Vengono scelti strumenti facili da usare: Jest + Testing Library (React), Playwright per e2e. Così possiamo mantenere un equilibrio tra copertura e tempo di immissione sul mercato.

Ogni commit attiva controlli di sicurezza. Viene impostata una semplice pipeline CI/CD che esegue: controlli di tipo (ad es., tsc --noEmit), controlli di lint/formattazione, test unitari, distribuzione automatica in staging. Vengono utilizzati strumenti comuni: GitHub Actions, Docker Compose.

Evitiamo di hardcodare qualsiasi cosa = dolore a lungo termine. Tutti i segreti/configurazioni sono memorizzati in .env o configurazioni remote (ad es., AWS SSM, ambienti Vercel). Viene utilizzata una configurazione basata sull'ambiente (process.env.NODE_ENV). Si evita di commettere .env.*, chiavi API, credenziali, ecc. E sono ben documentati.