Le basi di programmazione che separano chi copia codice da chi capisce davvero

Le basi non sono il punto di partenza: sono il fondamento permanente

Ogni sviluppatore esperto che conosco, senza eccezioni, torna continuamente ai fondamentali.

Non perché li abbia dimenticati, ma perché capire in profondità i concetti di base è quello che permette di lavorare bene su qualsiasi livello superiore.

La programmazione orientata agli oggetti, la gestione delle eccezioni, le strutture dati, i tipi, la memoria, il flusso di controllo: non sono argomenti da superare il prima possibile per arrivare ai framework "interessanti".

Sono gli strumenti con cui si pensa.

Chi li ha interiorizzati impara qualsiasi framework in pochi giorni.

Chi li ha saltati continua ad avere problemi che non riesce a spiegare.

Questa categoria non è per chi non ha mai scritto una riga di codice.

È per chi vuole costruire competenze che reggono nel tempo, non conoscenze superficiali da ripassare prima di ogni colloquio.

Il criterio che uso per misurare se le basi sono solide è semplice: riesci a spiegare perché il codice funziona, non solo che funziona?

OOP in C#: cosa capire davvero oltre la sintassi

La programmazione orientata agli oggetti viene insegnata quasi sempre con tre parole: incapsulamento, ereditarietà, polimorfismo.

Poi si passa agli esempi con Animale, Cane e Gatto, e la lezione finisce lì.

Il problema è che questi esempi non spiegano il perché.

Perché l'incapsulamento protegge la coerenza dei dati.

Perché l'ereditarietà crea accoppiamento e dovrebbe essere usata con parsimonia.

Perché il polimorfismo permette di scrivere codice aperto all'estensione senza modificare quello esistente.

In C# questi concetti si materializzano in scelte concrete: quando usare una classe e quando un record, quando un'interfaccia e quando una classe astratta, quando i modificatori di accesso proteggono il design e quando lo complicano inutilmente.

La sintassi la si impara in pochi giorni; il ragionamento che sta dietro richiede anni di pratica consapevole.

Quello che mi interessa con questa categoria è accelerare quella pratica consapevole: mostrare il ragionamento, non solo il risultato.

Gli errori ricorrenti di chi ha basi deboli e come riconoscerli

Dopo anni di code review e mentoring ho imparato a riconoscere i segnali di basi fragili.

Non sono gli errori di sintassi: quelli il compilatore li trova.

Sono i pattern di pensiero che producono codice che funziona ma che nessuno riesce a mantenere.

Il primo segnale è la dipendenza dai tutorial: chi non ha basi solide cerca sempre un esempio che assomiglia al suo problema invece di capire il problema e costruire la soluzione.

Il codice che ne risulta è spesso corretto ma non comprensibile, perché è un assemblaggio di pezzi copiati senza un ragionamento unificante.

Il secondo segnale è la paura del debugger: chi non capisce il flusso di esecuzione non sa dove guardare quando qualcosa va storto.

Il debugging diventa tentativi casuali invece di un'analisi sistematica.

Il terzo segnale è la difficoltà a nominare le cose: variabili come temp, data, result sono spesso un indicatore che non si ha ancora un modello mentale chiaro del problema che il codice deve risolvere.

Questi non sono difetti di intelligenza.

Sono difetti di metodo.

E il metodo si può correggere.

Come costruire basi solide con la pratica deliberata

La pratica che forma le competenze non è la pratica generica.

È la pratica deliberata: affrontare problemi appena oltre il proprio livello attuale, con feedback immediato sugli errori.

In pratica significa costruire piccoli progetti completi invece di seguire tutorial infiniti.

Un'applicazione da riga di comando che gestisce una lista di task insegna più di dieci tutorial su YouTube perché costringe a fare scelte, ad affrontare problemi inaspettati e a portare qualcosa fino in fondo.

Significa leggere codice altrui con l'intenzione di capirlo, non di copiarlo.

Means fare code review — anche da soli, anche sul proprio codice di ieri — chiedendosi: questo si può leggere? questo si può cambiare? questo si può testare?

E significa accettare che le basi non si "finiscono" mai.

Si approfondiscono.

Ogni volta che torni su un concetto fondamentale dopo mesi di esperienza in più, ci trovi qualcosa che non avevi capito prima.