“Qualsiasi sciocco può scrivere un codice comprensibile a un computer. I bravi programmatori scrivono un codice comprensibile agli esseri umani.” —Martin Fowler.

Questa citazione è il fondamento della cultura ingegneristica specifica di Maison Code Paris. Non ottimizziamo per “Righe di codice”. Non ottimizziamo per la “Velocità di digitazione”. Ottimizziamo per la Manutenibilità.

Al compilatore non interessa se dai alla variabile il nome “x” o “daysUntilExpiration”. La CPU lo esegue esattamente nello stesso nanosecondo. Ma lo sviluppatore junior che si sveglia alle 3:00 per correggere un bug critico si preoccupa profondamente. Se devono dedicare 10 minuti a decifrare i nomi delle variabili, l’azienda perde denaro. Clean Code è un atto di empatia.

Perché Maison Code ne parla

In Maison Code Paris, agiamo come la coscienza architettonica dei nostri clienti. Spesso ereditiamo stack “moderni” costruiti senza una comprensione fondamentale della scala.

Discutiamo di questo argomento perché rappresenta un punto di svolta critico nella maturità ingegneristica. Implementarlo correttamente differenzia un MVP fragile da una piattaforma resiliente di livello aziendale.

1. Denominazione: il problema più difficile in informatica

I nomi dovrebbero rivelare l’intento. Un nome di variabile dovrebbe dirti tre cose:

Che cosa fa.
Perché esiste.
Come si usa.

La regola di “nessuna mappatura mentale”

Cattivo: “dattiloscritto”. cost d = 10; // giorni lista const = []; // utenti

Il lettore deve tradurre mentalmente `d` -> `giorni`. Questo utilizza il carico cognitivo (RAM).

**Buono**:
"dattiloscritto".
const daysSinceLastLogin = 10;
const utentiattivi = [];

Il codice si legge come la prosa inglese.

La regola della lunghezza dell’ambito

Ambito piccolo (loop): i nomi brevi vanno bene. for (let i = 0; i < 10; i++) va bene.
Ambito ampio (globale/classe): i nomi devono essere espliciti. “i” è proibito. Utilizza “globalRetryCounter”.

2. Funzioni: fai una cosa

Il principio di responsabilità unica (SRP) si applica alle funzioni, non solo alle classi. Una funzione dovrebbe avere un livello di astrazione.

Cattivo (La funzione di Dio): “dattiloscritto”. funzione asincrona RegisterUser(req) { // 1. Analisi const {email, password} = req.body;

// 2. Convalida if (!email.includes(’@’)) lancia un nuovo errore(‘Email non valida’);

// 3. Logica del database const utente = attendono db.users.create({ e-mail, password: bcrypt.hashSync(password) });

// 4. Logica della posta elettronica attendono mailgun.messages().send({ a: email, testo: “Benvenuto!” });

// 5. Logica di risposta return { status: 200, id: user.id }; }

Questa funzione cambia se:
* Il database cambia (da Postgres a Mongo).
* Il provider di posta elettronica cambia (da Mailgun a SendGrid).
*Il formato API cambia.
È fragile.

**Buono (L'orchestratore)**:
"dattiloscritto".
funzione asincrona RegisterUser(req) {
  const accountInfo = parseRequest(req);
  validateAccount(infoaccount);
  
  const utente = attendono createUserInDatabase(accountInfo);
  attendono sendWelcomeEmail(utente);
  
  formato restituitoRisposta(utente);
}

Ora, “registerUser” è solo un orchestratore. Racconta una storia. I dettagli di implementazione sono nascosti in funzioni piccole e mirate.

3. Commenti: Il fallimento dell’espressione

I migliori ingegneri scrivono meno commenti, non di più. Perché? Perché I commenti sono un odore di codice. Se devi scrivere un commento per spiegare cosa fa il codice, il tuo codice è troppo complesso. Rifattorizzarlo.

Cattivo: “dattiloscritto”. // Controlla se l’utente ha diritto allo sconto senior if (utente.età > 65 && utente.acquisti > 10 && utente.paese === ‘FR’) { applicaSconto(); }


**Buono**:
"dattiloscritto".
se (utente.isEliggedForSeniorDiscount()) {
  applicaSconto();
}

Quando commentare?

Commenta il PERCHÉ, non il COSA. Il codice spiega cosa succede. Il commento spiega il contesto aziendale o la strana soluzione alternativa.

“dattiloscritto”. // Usiamo un ritardo di 500 ms qui perché l’API di pagamento esterna // ha una condizione di competizione se interrogata immediatamente dopo la creazione. // Vedi il biglietto n.452. attendere il ritardo(500);

Questo commento evita al prossimo sviluppatore di "ottimizzare" il ritardo.

## 4. Condizionali: evitare il codice freccia

Il "codice freccia" si verifica quando le istruzioni `if` nidificate creano una forma simile a una freccia `>`.
Spinge la logica sul lato destro dello schermo e rende difficile tenere traccia dello stato.

**Cattivo**:
"dattiloscritto".
funzione processoPagamento(ordine) {
  se (ordine) {
    se (ordine.isPaid) {
       if (importo.ordine > 0) {
          // Logica
       }
    }
  }
}

Buono (clausole di guardia): Ritorna presto. Uccidi la funzione il prima possibile. “dattiloscritto”. funzione processoPagamento(ordine) { if (!ordine) ritorno; se (!ordine.isPaid) ritorno; if (importo.ordine <= 0) return;

// Logica (senza rientro) }


## 5. Ossessione primitiva

Non passare stringhe e numeri grezzi in giro. Passa **Oggetti** che impongono regole.

**Cattivo**:
"funzione bookFlight(origine: stringa, destinazione: stringa)".
"New York" è valido? "New York" è valido? "JFK" è valido?

**Buono**:
`libro funzioneVolo(origine: AirportCode, destinazione: AirportCode)`
La classe "AirportCode" garantisce che nel sistema possano esistere solo codici IATA validi di 3 lettere.
Rendi irrappresentabili gli stati non validi.

## 7. Test come documentazione

La migliore documentazione è uno Unit Test.
I documenti diventano obsoleti. I test no.
Se vuoi sapere come funziona `calculateDiscount()`, leggi i casi di test.
* `it('dovrebbe applicare il 10% per i nuovi utenti')`
* `it('dovrebbe fallire se il carrello è vuoto')`
La scrittura dei test ti costringe a scrivere codice pulito.
Se una funzione è difficile da testare, il codice è errato.
"Non posso testarlo perché interroga il DB all'interno della funzione."
**Refactoring**: inserisce la dipendenza del DB. Adesso è verificabile.

## 8. La cultura della revisione del codice

Code Review non serve per trovare bug. Questo è lo scopo della CI.
La revisione del codice è destinata alla **condivisione della conoscenza**.
È una sessione di tutoraggio.
"Perché hai scelto un Set invece di un Array qui?"
"Questo pattern è interessante, possiamo usarlo anche nel modulo Utente?"
Gli ingegneri senior non dovrebbero limitarsi a dire "LGTM". Dovrebbero spiegare *perché* qualcosa è buono o cattivo.
Richiediamo almeno 1 "Nitpick" o "Suggerimento" per PR. Forza il coinvolgimento.

## 9. La regola dei boy scout

"Lasciate sempre il campeggio più pulito di come lo avete trovato."
Questo è l’antidoto al debito tecnico.
Stai risolvendo un bug nel modulo "Prezzi". Noti una variabile denominata "x".
**Rinominalo.**
Noti una funzione troppo lunga.
**Dividilo.**
Non chiedere il permesso. Non creare un ticket "Prezzi Refactoring". Fallo semplicemente come parte del tuo lavoro.
Se ogni ingegnere pulisse l'1% del codice che tocca, la base del codice rimarrà intatta per sempre.

## 7. ASCIUTTO vs BAGNATO (La trappola dell'astrazione)

Ci viene insegnato **DRY (Non ripeterti)**.
È una buona regola. Ma è pericoloso.
Se vedi due pezzi di codice che sembrano simili, li unisci in una funzione condivisa.
**Il problema**: ora entrambi i posti si affidano a quella funzione.
Se la caratteristica A necessita di una leggera modifica alla funzione, aggiungi un flag booleano.
"funzione fare(èFunzioneA)".
Quindi la caratteristica B necessita di una modifica.
"funzione fare(èCaratteristicaA, èCaratteristicaB)".
Presto avrai una Funzione Divina con 10 bandiere.
**WET (Write Everything Twice)** è spesso migliore.
La duplicazione è più economica dell’astrazione sbagliata.
Se due funzionalità *accidentalmente* condividono la logica ma hanno motivi aziendali diversi per modificarle, **copia e incolla il codice**.

## 8. La teoria delle "finestre rotte".

In criminologia, se un edificio ha una finestra rotta che non è riparata, i vandali presto romperanno tutte le finestre.
Il codice è lo stesso.
Se lasci una funzione disordinata, lo sviluppatore successivo penserà: "Questo file è comunque spazzatura, inserirò semplicemente la mia correzione".
Se il file è intatto, sentiranno la pressione sociale per mantenerlo intatto.
**Sii il giardiniere**. Elimina il disordine ogni giorno.

## 9. Conclusione

Clean Code non è una questione estetica. Si tratta di **Economia**.
Il codice disordinato marcisce. Diventa il "Legacy Code" che tutti hanno paura di toccare. Le funzionalità richiedono più tempo per essere create. I bug compaiono più spesso.
Clean Code è una risorsa. Ti permette di muoverti velocemente *indefinitamente*.


<hr style="margin: 1rem 0" />

### Codebase è un disastro?
La tua velocità sta rallentando a causa di "Spaghetti Code"?


**[Pianifica una verifica del codice](/services/tech)**.
Leggi informazioni su [Unit Testing](/it/blog/tech-unit-testing-it) e [Refactoring](/it/blog/tech-10x-engineer-it).

Clean Code non è una questione estetica. Si tratta di **Economia**.
Il codice disordinato marcisce. Diventa il "Legacy Code" che tutti hanno paura di toccare. Le funzionalità richiedono più tempo per essere create. I bug compaiono più spesso.
Clean Code è una risorsa. Ti permette di muoverti velocemente *indefinitamente*.

Scrivi il codice per l'umano che lo leggerà.
Perché tra 6 mesi quell'umano sarai tu.

### Codebase è un disastro?
La tua velocità sta rallentando a causa di "Spaghetti Code"?


**[Pianifica una verifica del codice](/services/tech)**.
**[Assumi i nostri architetti](/contact)**.