Dijkstra & Programmazione Strutturata: una disciplina che scala

Perché Dijkstra è ancora importante quando il software cresce

Il software raramente fallisce perché non può essere scritto. Fallisce perché, un anno dopo, nessuno può modificarlo in sicurezza.

Man mano che i codebase crescono, ogni piccola modifica inizia a propagarsi: una correzione di bug rompe una funzionalità lontana, un nuovo requisito costringe a riscritture e un semplice refactor si trasforma in una settimana di coordinamento accurato. La parte difficile non è aggiungere codice—è mantenere il comportamento prevedibile mentre tutto intorno cambia.

La promessa: correttezza e semplicità abbassano il costo nel lungo periodo

Edsger Dijkstra sosteneva che correttezza e semplicità dovrebbero essere obiettivi di primo piano, non optional. Il ritorno non è accademico. Quando un sistema è più facile da ragionare, i team passano meno tempo a spegnere incendi e più tempo a costruire.

• La correttezza riduce il costo degli errori: meno incidenti, meno regressioni, meno codice “non toccare”.
• La semplicità riduce il costo del cambiamento: meno assunzioni nascoste, meno casi speciali, meno sorprese durante le review.

Cosa significa davvero “scalare”

Quando si parla di “scalare”, spesso si intende le prestazioni. Il punto di Dijkstra è diverso: anche la complessità scala.

La scala si manifesta come:

• Più funzionalità: nuovi flussi, casi limite e aspettative degli utenti.
• Più persone: passaggi di consegne, stili diversi e contesti variabili.
• Più integrazioni: API esterne, fonti dati e modalità di errore.
• Più tempo: decisioni legacy, requisiti che cambiano e riscritture parziali.

L'idea centrale: la struttura rende il comportamento più prevedibile

La programmazione strutturata non è severità fine a se stessa. È scegliere flussi di controllo e decomposizioni che rendono facili le risposte a due domande:

• “Cosa succede dopo?”
• “In quali condizioni?”

Quando il comportamento è prevedibile, il cambiamento diventa di routine invece che rischioso. Per questo Dijkstra è ancora importante: la sua disciplina colpisce il vero collo di bottiglia del software che cresce—capirlo abbastanza bene da migliorarlo.

Una semplice introduzione a Edsger Dijkstra e al suo obiettivo

Edsger W. Dijkstra (1930–2002) è stato un informatico olandese che ha influenzato il modo in cui i programmatori pensano alla costruzione di software affidabile. Ha lavorato su sistemi operativi precoci, ha contribuito agli algoritmi (compreso l'algoritmo del percorso più breve che porta il suo nome) e—soprattutto per gli sviluppatori quotidiani—ha promosso l'idea che programmare debba essere qualcosa su cui possiamo ragionare, non solo qualcosa che proviamo finché sembra funzionare.

Il suo focus principale: ragionare oltre il “funziona sulla mia macchina”

A Dijkstra interessava meno che un programma potesse produrre l'output giusto per pochi esempi e più il fatto che potessimo spiegare perché è corretto per i casi che contano.

Se puoi dichiarare cosa dovrebbe fare un pezzo di codice, dovresti essere in grado di argomentare (passo dopo passo) che lo fa davvero. Questo atteggiamento porta naturalmente a codice più facile da seguire, più facile da revisionare e meno dipendente da debug eroici.

Perché può sembrare severo—e perché questo aiuta

Alcuni scritti di Dijkstra suonano inflessibili. Criticava i trucchi “intelligenti”, i flussi di controllo approssimativi e le abitudini di codifica che rendono il ragionamento difficile. La severità non è un gusto stilistico; è ridurre l'ambiguità. Quando il significato del codice è chiaro, si spende meno tempo a discutere le intenzioni e più tempo a validare il comportamento.

Cosa significa “programmazione strutturata” (a grandi linee)

La programmazione strutturata è la pratica di costruire programmi a partire da un piccolo insieme di chiare strutture di controllo—sequenza, selezione (if/else) e iterazione (loop)—invece di salti aggrovigliati nel flusso. L'obiettivo è semplice: rendere il percorso attraverso il programma comprensibile così da poterlo spiegare, mantenere e modificare con fiducia.

Correttezza: la feature nascosta su cui gli utenti fanno affidamento

Le persone spesso descrivono la qualità del software come “veloce”, “bella” o “ricca di funzionalità”. Gli utenti vivono la correttezza in modo diverso: come la fiducia silenziosa che l'app non li sorprenderà. Quando la correttezza è presente, nessuno se ne accorge. Quando manca, tutto il resto smette di avere importanza.

“Funziona ora” vs “continua a funzionare”

“Funziona ora” solitamente significa che hai provato qualche percorso e ottenuto il risultato atteso. “Continua a funzionare” significa che si comporta come previsto nel tempo, nei casi limite e con i cambiamenti—dopo refactor, nuove integrazioni, traffico più alto e nuovi membri del team che toccano il codice.

Una funzionalità può “funzionare ora” pur restando fragile:

• dipende dall'input sempre pulito.
• assume che una chiamata di rete risponda sempre rapidamente.
• passa test che coprono solo il percorso felice.

La correttezza riguarda la rimozione di queste assunzioni nascoste—o il renderle esplicite.

Come i piccoli bug si moltiplicano nei grandi sistemi

Un bug minore raramente resta minore quando il software cresce. Uno stato scorretto, un off-by-one o una regola di gestione degli errori poco chiara vengono copiati in nuovi moduli, avvolti da altri servizi, memorizzati in cache, ritentati o “aggirati”. Col tempo, i team smettono di chiedersi “cos'è vero?” e iniziano a chiedersi “cosa succede di solito?” È allora che la risposta agli incidenti diventa archeologia.

Il moltiplicatore è la dipendenza: un piccolo malfunzionamento diventa molti malfunzionamenti a valle, ognuno con la propria soluzione parziale.

La chiarezza è uno strumento di correttezza (non solo una scelta di stile)

Il codice chiaro migliora la correttezza perché migliora la comunicazione:

• Le code review colgono problemi reali quando l'intento è ovvio.
• L'onboarding è più veloce quando le regole sono leggibili, non conoscenza tribale.
• Gli incidenti si risolvono prima quando il flusso di controllo e le modalità di errore sono facili da tracciare.

Una definizione pratica di correttezza per i team di prodotto

La correttezza significa: per gli input e le situazioni che dichiariamo di supportare, il sistema produce coerentemente gli esiti promessi—fallendo in modi prevedibili e spiegabili quando non può farlo.

Semplicità come strategia, non come preferenza stilistica

La semplicità non riguarda rendere il codice “carino”, minimale o intelligente. Riguarda rendere il comportamento facile da prevedere, spiegare e modificare senza paura. Dijkstra valorizzava la semplicità perché migliora la nostra capacità di ragionare sui programmi—soprattutto quando il codebase e il team crescono.

Cos'è la semplicità (e cosa non è)

Il codice semplice mantiene in movimento un piccolo numero di idee: flusso dati chiaro, flusso di controllo chiaro e responsabilità ben definite. Non costringe il lettore a simulare molte strade alternative nella testa.

La semplicità non è:

• meno righe a ogni costo
• trucchi “smart”, one-liner densi o astrazioni pesanti
• evitare struttura per sembrare flessibili

Complessità accidentale: ciò che non intendevi aggiungere

Molti sistemi diventano difficili da cambiare non perché il dominio sia intrinsecamente complesso, ma perché introduciamo complessità accidentale: flag che interagiscono in modi imprevisti, patch per casi speciali che non vengono rimosse e livelli che esistono per aggirare decisioni precedenti.

Ogni eccezione in più è una tassa sulla comprensione. Il costo si manifesta più tardi, quando qualcuno tenta di correggere un bug e scopre che una modifica in un'area rompe sottilmente altre.

I design semplici riducono la necessità di eroismi

Quando un design è semplice, il progresso viene da lavoro costante: modifiche recensibili, diff piccoli e meno fix d'emergenza. I team non hanno bisogno di sviluppatori “eroi” che ricordano ogni caso limite storico o che sanno fare debug alle 2 di notte. Invece, il sistema supporta normale attenzione umana.

Regola pratica: meno casi speciali, meno sorprese

Un test pratico: se continui ad aggiungere eccezioni (“a meno che…”, “eccetto quando…”, “solo per questo cliente…”), probabilmente stai accumulando complessità accidentale. Preferisci soluzioni che riducono il branching nel comportamento—una regola coerente batte cinque casi speciali, anche se la regola coerente è un po' più generale di quanto immaginavi inizialmente.

Programmazione strutturata: flusso di controllo chiaro di cui ti puoi fidare

La programmazione strutturata è un'idea semplice con grandi conseguenze: scrivi codice in modo che il suo percorso di esecuzione sia facile da seguire. In parole semplici, la maggior parte dei programmi può essere costruita da tre blocchi costitutivi—sequenza, selezione e ripetizione—senza affidarsi a salti aggrovigliati.

I tre mattoni (in termini umani)

• Sequenza: fai il passo A, poi il passo B, poi il passo C.
• Selezione: scegli un percorso in base a una condizione (es., if/else, switch).
• Ripetizione: ripeti un insieme di passi finché una condizione vale (es., for, while).

Quando il flusso di controllo è composto da queste strutture, di solito puoi spiegare cosa fa il programma leggendo dall'alto in basso, senza “teletrasportarti” nel file.

Ciò che ha sostituito: percorsi di esecuzione a spaghetti

Prima che la programmazione strutturata diventasse la norma, molti codebase si affidavano pesantemente a salti arbitrari (il classico flusso goto). Il problema non è che i salti siano sempre cattivi; è che il salto non regolamentato crea percorsi di esecuzione difficili da prevedere. Finisci per farti domande come “Come ci siamo arrivati qui?” e “In quale stato è questa variabile?”—e il codice non risponde chiaramente.

Perché la chiarezza conta per i team reali

Un flusso di controllo chiaro aiuta le persone a costruire un modello mentale corretto. Quel modello è ciò su cui fai affidamento quando fai debug, rivedi una pull request o cambi comportamento sotto pressione.

Quando la struttura è consistente, la modifica diventa più sicura: puoi cambiare un ramo senza influenzarne un altro, o rifattorizzare un loop senza perdere un percorso di uscita nascosto. La leggibilità non è solo estetica—è la base per cambiare comportamento con fiducia senza rompere ciò che già funziona.

Strumenti di ragionamento: invarianti, precondizioni e postcondizioni

Dijkstra propose un'idea semplice: se puoi spiegare perché il tuo codice è corretto, puoi cambiarlo con meno paura. Tre piccoli strumenti di ragionamento rendono questo pratico—senza trasformare il team in matematici.

Invarianti: “fatti che restano veri”

Un'invariante è un fatto che resta vero mentre una porzione di codice gira, specialmente dentro un loop.

Esempio: stai sommando i prezzi nel carrello. Un'invariante utile è: “total è la somma di tutti gli articoli processati finora.” Se questo resta vero ad ogni passo, quando il loop finisce il risultato è affidabile.

Le invarianti sono potenti perché focalizzano l'attenzione su ciò che non deve mai rompersi, non solo su ciò che dovrebbe succedere dopo.

Precondizioni e postcondizioni: contratti quotidiani

Una precondizione è ciò che deve essere vero prima che una funzione venga eseguita. Una postcondizione è ciò che la funzione garantisce dopo che termina.

Esempi quotidiani:

• Precondizione: “Puoi prelevare soldi solo se il tuo conto ha fondi sufficienti.”
• Postcondizione: “Dopo il prelievo, il saldo è ridotto di esattamente quell'importo e non diventa mai negativo.”

Nel codice, una precondizione potrebbe essere “la lista in input è ordinata”, e la postcondizione potrebbe essere “la lista in output è ordinata e contiene gli stessi elementi più quello inserito”.

Come scriverle cambia codice e review

Quando le annoti (anche informalmente), il design diventa più nitido: decidi cosa una funzione si aspetta e cosa promette, e naturalmente la rendi più piccola e focalizzata.

Nelle review, sposta il dibattito dallo stile (“Lo scriverei diversamente”) verso la correttezza (“Questa funzione mantiene l'invariante?” “Enforziamo la precondizione o la documentiamo?”).

Pratica leggera: commenta dove i bug si accumulano

Non servono prove formali per beneficiare. Scegli il loop più bug-prone o l'aggiornamento di stato più ostico e aggiungi un'invariante di una riga sopra di esso. Quando qualcuno modifica il codice dopo, quel commento funge da barriera: se una modifica rompe questo fatto, il codice non è più sicuro.

Test vs ragionamento: cosa ciascuno può (e non può) garantire

Test e ragionamento mirano allo stesso risultato—software che si comporta come previsto—ma funzionano in modi molto diversi. I test scoprono problemi provando esempi. Il ragionamento previene intere categorie di problemi rendendo la logica esplicita e verificabile.

Per cosa sono ottimi i test

I test sono una rete di sicurezza pratica. Catturano regressioni, verificano scenari reali e documentano il comportamento atteso in modo che tutto il team possa eseguirli.

Ma i test possono solo mostrare la presenza di bug, non la loro assenza. Nessuna suite di test copre ogni input, ogni variazione temporale o ogni interazione tra funzionalità. Molti fallimenti “funziona sulla mia macchina” derivano da combinazioni non testate: un input raro, un ordine specifico di operazioni o uno stato sottile che appare dopo diversi passi.

Cosa il ragionamento può garantire (e cosa no)

Il ragionamento riguarda la prova di proprietà del codice: “questo loop termina sempre”, “questa variabile non è mai negativa”, “questa funzione non restituisce un oggetto invalido”. Ben fatto, esclude intere classi di difetti—specialmente sui bordi e nei casi limite.

Il limite è lo sforzo e la portata. Prove formali complete per un intero prodotto sono raramente economiche. Il ragionamento funziona meglio se applicato selettivamente: algoritmi core, flussi sensibili alla sicurezza, logica di pagamento e concorrenza.

Un approccio bilanciato che scala

Usa i test in modo ampio e applica ragionamento più profondo dove il fallimento è costoso.

Un ponte pratico tra i due è rendere l'intento eseguibile:

• Assertion per assunzioni interne (es., “l'indice è nel range”).
• Precondizioni e postcondizioni (contratti) per input/output delle funzioni.
• Invarianti per verità persistenti (es., “il totale del carrello è la somma degli articoli”).

Queste tecniche non sostituiscono i test—they stringono la rete. Trasformano aspettative vaghe in regole verificabili, rendendo i bug più difficili da introdurre e più facili da diagnosticare.

Disciplina: come i team evitano il “debito di furbizia”

Il codice “intelligente” spesso sembra una vittoria nel momento: meno righe, un trucco elegante, un one-liner che fa sentire brillanti. Il problema è che quella furbizia non scala nel tempo né tra le persone. Sei mesi dopo, l'autore dimentica il trucco. Un nuovo collega lo legge alla lettera, perde l'assunzione nascosta e lo cambia rompendo il comportamento. Questo è il “debito di furbizia”: velocità a breve termine comprata con confusione a lungo termine.

La disciplina accelera il team

Il punto di Dijkstra non era “scrivi codice noioso” come preferenza stilistica—era che vincoli disciplinati rendono i programmi più facili da ragionare. In un team, i vincoli riducono anche l'affaticamento decisionale. Se tutti conoscono già i default (naming, struttura delle funzioni, cosa significa “done”), smetti di ridiscutere le basi in ogni pull request. Quel tempo ritorna al lavoro di prodotto.

La disciplina si manifesta in pratiche di routine:

• Code review che premiano la chiarezza sulla novità (“Qualcun altro può cambiare questo in sicurezza?”).
• Standard condivisi (formattazione, naming, gestione errori) così il codebase legge come una sola voce.
• Refactor come manutenzione, non come missione di salvataggio—piccoli pulizie continue.

Cosa significa “disciplinato” nel codice

Alcune abitudini concrete che prevengono l'accumulo di debito di furbizia:

• Funzioni piccole che fanno un solo lavoro, con input e output ovvi.
• Nomi chiari che spiegano l'intento (preferisci calculate_total() a do_it()).
• Nessuno stato nascosto: minimizza i globali e gli effetti collaterali sorprendenti; passa le dipendenze esplicitamente.
• Flusso di controllo lineare: evita logica che dipende da ordinamenti sottili, valori magici o “funziona se conosci il trucco”.

La disciplina non riguarda la perfezione—riguarda rendere prevedibile la prossima modifica.

Modularità e confini: mantenere la modifica locale

La modularità non è solo “dividere il codice in file.” È isolare le decisioni dietro confini chiari, così il resto del sistema non deve sapere (o preoccuparsi) dei dettagli interni. Un modulo nasconde le parti disordinate—strutture dati, casi limite, ottimizzazioni di performance—mentre espone una superficie piccola e stabile.

Come i moduli riducono il raggio d'azione dei cambiamenti

Quando arriva una richiesta di modifica, l'esito ideale è: un solo modulo cambia e tutto il resto resta intatto. Questo è il significato pratico di “mantenere la modifica locale.” I confini prevengono l'accoppiamento accidentale—dove aggiornare una funzionalità rompe silenziosamente tre altre perché condividevano assunzioni.

Un buon confine rende anche il ragionamento più semplice. Se puoi dichiarare cosa garantisce un modulo, puoi ragionare sul programma più ampio senza rileggere tutta l'implementazione ogni volta.

Interfacce come promesse (e come abilitano lavoro parallelo)

Un'interfaccia è una promessa: “Dato questo input, produrrò questo output e manterrò queste regole.” Quando la promessa è chiara, i team possono lavorare in parallelo:

• Una persona implementa il modulo.
• Un'altra costruisce un chiamante usando l'interfaccia.
• QA progetta test attorno al comportamento promesso.

Non è burocrazia—è creare punti di coordinamento sicuri in un codebase che cresce.

Semplici controlli di modulo che prevengono il deragliamento

Non serve una grande revisione architetturale per migliorare la modularità. Prova questi controlli leggeri:

• Input/output: riesci a elencare gli input, gli output e gli effetti collaterali in poche righe? Se no, probabilmente fa troppo.
• Ownership: chi è responsabile del suo comportamento e delle modifiche? I moduli senza proprietario diventano discariche.
• Dipendenze: dipende da “tutto” o solo da ciò che serve davvero? Meno dipendenze significano meno rotture a sorpresa.

Confini ben disegnati trasformano la “modifica” da evento di sistema a edit localizzato.

Perché queste idee vincono a scala (team, codebase e tempo)

Quando il software è piccolo, puoi “tenerlo tutto in testa.” Alla scala, questo smette di essere vero—e i modi in cui fallisce diventano familiari.

I sintomi comuni sono:

• Outage che risalgono a un caso limite sorprendente
• Release che rallentano perché ogni modifica sembra rischiosa
• Integrazioni fragili dove un aggiornamento minore rompe tre sistemi a valle

La struttura abbassa il carico cognitivo

La scommessa centrale di Dijkstra era che gli umani sono il collo di bottiglia. Flusso di controllo chiaro, unità piccole e ben definite e codice che puoi ragionare non sono scelte estetiche—sono moltiplicatori di capacità.

In un grande codebase, la struttura agisce come compressione della comprensione. Se le funzioni hanno input/output espliciti, i moduli hanno confini nominabili e il “percorso felice” non è aggrovigliato con ogni caso limite, gli sviluppatori passano meno tempo a ricostruire l'intento e più tempo a fare cambiamenti deliberati.

Scala con i team, non solo con il codice

Man mano che i team crescono, i costi di comunicazione aumentano più velocemente delle linee di codice. Il codice disciplinato e leggibile riduce la quantità di conoscenza tribale necessaria per contribuire in sicurezza.

Questo si vede subito nell'onboarding: i nuovi ingegneri possono seguire pattern prevedibili, imparare un piccolo insieme di convenzioni e fare modifiche senza un lungo tour dei “gotcha”. Il codice stesso insegna il sistema.

Gli incidenti diventano più semplici da debug e più sicuri da annullare

Durante un incidente il tempo è scarso e la fiducia è fragile. Il codice scritto con assunzioni esplicite (precondizioni), controlli significativi e flusso di controllo lineare è più facile da tracciare sotto pressione.

Ancora più importante, le modifiche disciplinate sono più facili da rollbackare. Edit più piccoli e localizzati con confini chiari riducono la probabilità che un rollback inneschi nuovi guasti. Il risultato non è perfezione—sono meno sorprese, recupero più rapido e un sistema che resta manutenibile con gli anni e i contributori.

Applicare Dijkstra senza essere dogmatici

Il punto di Dijkstra non era “scrivi codice all'antica.” Era “scrivi codice che puoi spiegare.” Puoi adottare questo mindset senza trasformare ogni feature in un esercizio di prova formale.

Trasforma i principi in abitudini quotidiane

Inizia con scelte che rendono economico il ragionamento:

• Preferisci flussi di controllo semplici: poche funzioni piccole piuttosto che una routine multi-branch “che fa tutto”.
• Riduci gli effetti collaterali: tieni la mutazione vicino a dove serve e non lasciare che le funzioni cambino silenziosamente stato globale.
• Usa contratti chiari: rendi input, output e comportamento d'errore espliciti (nei tipi, nomi e commenti).

Una buona euristica: se non riesci a riassumere in una frase cosa garantisce una funzione, probabilmente fa troppo.

Piccoli “upgrade di struttura” (senza riscritture)

Non serve un grande sprint di refactor. Aggiungi struttura alle cuciture:

• Estrai un loop complesso in una funzione nominata e definisci cosa rimane vero a ogni iterazione.
• Sostituisci condizioni “magiche” con predicati ben nominati (es., isEligibleForRefund).
• Incapsula una transizione di stato complicata dietro una singola funzione così il resto del codebase non la può usare male.

Questi upgrade sono incrementali: riducono il carico cognitivo per la modifica successiva.

Prompt per le code review che ti mantengono onesto

Quando revisioni (o scrivi) una modifica, chiedi:

• “Cosa deve essere vero qui?” (invarianti, assunzioni, stato richiesto)
• “Cosa può cambiare in sicurezza?” (quali parti possono variare senza rompere i chiamanti)

Se i reviewer non possono rispondere velocemente, il codice sta segnalando dipendenze nascoste.

Documenta il ragionamento, non solo i passi

I commenti che ripetono il codice invecchiano. Scrivi perché il codice è corretto: le assunzioni chiave, i casi limite che proteggi e cosa si romperebbe se quelle assunzioni cambiassero. Una nota breve come “Invariante: total è sempre la somma degli elementi processati” può valere più di un paragrafo di narrazione.

Se vuoi un posto leggero per raccogliere queste abitudini, mettile in una checklist condivisa (vedi /blog/practical-checklist-for-disciplined-code).

Dove si inserisce lo sviluppo assistito dall'AI (senza perdere la disciplina)

I team moderni usano sempre più l'AI per accelerare la delivery. Il rischio è noto: velocità oggi può trasformarsi in confusione domani se il codice generato è difficile da spiegare.

Un modo conforme a Dijkstra di usare l'AI è trattarla come un acceleratore del pensiero strutturato, non come un suo sostituto. Per esempio, quando costruisci in Koder.ai—una piattaforma vibe-coding dove crei app web, backend e mobile tramite chat—puoi mantenere le abitudini “prima il ragionamento” rendendo espliciti prompt e passi di review:

• Chiedi contratti chiari: “Definisci precondizioni, postcondizioni e comportamento di errore per questo endpoint.”
• Chiedi invarianti nei flussi con stato: “Cosa deve essere sempre vero dopo ogni passo di questa state machine di checkout?”
• Usa la modalità pianificazione per costringere la decomposizione in pezzi piccoli e recensibili (moduli, interfacce, responsabilità) prima di generare dettagli di implementazione.
• Appoggiati a snapshot e rollback per mantenere le modifiche piccole e reversibili—rispecchiando la disciplina di edit localizzati e percorsi di undo sicuri.

Anche se poi esporti il codice sorgente ed esegui altrove, lo stesso principio vale: il codice generato deve essere codice che sai spiegare.

Una checklist pratica per codice corretto, semplice e disciplinato

Questa è una checklist “amica di Dijkstra” leggera che puoi usare durante review, refactor o prima di mergiare. Non si tratta di fare prove tutto il giorno—si tratta di rendere correttezza e chiarezza l'impostazione predefinita.

Controllo rapido (codice nuovo e refactor)

• Posso spiegare il codice a un collega in 60 secondi? Se la spiegazione richiede molto “fidati di me”, semplifica.
• Il flusso di controllo è ovvio? Preferisci codice in linea; tieni loop e condizioni piccoli; evita uscite nascoste e annidamenti profondi.
• Quali sono le precondizioni e le postcondizioni? Scrivile in un commento, docstring o nel nome della funzione. Se non le puoi dichiarare, la funzione probabilmente fa troppo.
• Ogni funzione ha un lavoro e un confine chiaro? Input in, output out—dipendenza minima da stato globale.
• Quale invariante mantiene onesto questo loop? Anche una nota di una riga come “total è la somma degli articoli processati” previene bug sottili.
• Ci sono meno trucchi “intelligenti” del necessario? Se il codice richiede una guida, sta accumulando debito di furbizia.

Cosa misurare in modo qualitativo

• Facilità di spiegazione: Qualcuno non familiare con il modulo può dire cosa fa e perché è corretto?
• Facilità di testing: I casi limite sono naturalmente testabili o serve un setup complesso?
• Rischio di cambiamento: Quando i requisiti cambiano, puoi prevedere cosa si rompe? Se ogni modifica fa paura, i confini stanno perdendo.

Passo pratico successivo

Scegli un modulo disordinato e rifattorizza prima il flusso di controllo:

1. Estrai funzioni piccole con nomi chiari.
2. Sostituisci rami aggrovigliati con casi espliciti e più semplici.
3. Sposta i casi speciali ai margini (validazione input, return anticipati).

Poi aggiungi alcuni test mirati attorno ai nuovi confini. Se vuoi altri pattern come questo, guarda i post correlati su /blog.