Come strutturare un progetto Angular in team: cartelle, naming e convenzioni

La domanda che mi fanno di piu quando entro in un progetto esistente: "Perche i file sono organizzati cosi?"

Nella maggior parte dei casi la risposta e: non c'era una struttura decisa in partenza. Ogni sviluppatore ha aggiunto file dove sembrava piu comodo, e dopo 6 mesi il progetto e un labirinto.

Ecco come organizzo io i progetti Angular dal primo giorno.

La regola base: feature-first

Ogni funzionalita ha la sua cartella. Dentro quella cartella ci sono tutto: componenti, servizi, modelli, route e test.

src/app/
  features/
    dashboard/
      components/
      pages/
      services/
      models/
    utenti/
      components/
      pages/
      services/
      models/
  shared/
    components/
    directives/
    pipes/
  core/
    guards/
    interceptors/
    services/

Cosa va in core, cosa in shared

Questa e la distinzione piu comune da sbagliare:

• **core**: singleton services, guards, interceptors. Roba che esiste una sola volta nell'app. AuthService, HttpInterceptor, ThemeService vanno qui.
• **shared**: componenti e utility riusabili tra feature diverse. Un ButtonComponent, una DatePipe custom, un ModalComponent: tutto in shared.
• **features**: logica specifica di una singola sezione. Un componente usato solo nel dashboard sta in features/dashboard, non in shared.

Naming convention

Nomi descrittivi, sempre. Evita abbreviazioni criptiche.

utenti-list.component.ts     (non: list.component.ts)
auth.guard.ts                (non: guard.ts)
fattura-detail.component.ts  (non: detail.component.ts)

Un file deve dirti cosa fa prima ancora che tu lo apra.

Barrel exports

Ogni cartella ha un file index.ts che esporta tutto il pubblico di quella feature. Questo semplifica gli import:

// Invece di:
import { UtentiListComponent } from '../../features/utenti/components/utenti-list/utenti-list.component';

// Puoi scrivere:
import { UtentiListComponent } from '../../features/utenti';

Un file, una responsabilita

Se un componente supera le 200 righe e probabilmente fa troppe cose. Spezzalo. I componenti piccoli sono piu facili da testare, riutilizzare e revisionare in code review.

Conclusione

Una struttura chiara non serve a te oggi: serve al tuo collega che tra 6 mesi dovra aggiungere una feature. O a te stesso, quando torni sul progetto dopo 3 mesi di altra roba.