Il nostro Blog

Sfatiamo 10 falsi miti sulla programmazione!

 

Oggi ESSE I assume le sembianze del duo di MythBusters, l’iconico show televisivo di divulgazione scientifica in cui i protagonisti sfatano dei luoghi comuni. Lo faremo anche noi, ma in ambito informatico, in particolare quello della programmazione.

In effetti, durante la nostra più che decennale esperienza, abbiamo constatato che ci sono molti falsi miti sul coding che possono portare a fraintendimenti, errori o cattive abitudini che andrebbero corretti. Ne abbiamo scelti dieci, quelli per noi più comuni e significativi.

 

1) Il codice va sempre commentato

È risaputo, e lo abbiamo anche sottolineato in un articolo precedente, che i commenti possono essere utili per spiegare il codice, soprattutto quando è complesso. Questa idea diffusa che mette l’accento sull’importanza dei commenti potrebbe far pensare che sia necessario commentare sempre ogni riga di codice.

Ma in realtà non è così: il codice dovrebbe essere scritto in modo autoesplicativo, cosa che da sola renderebbe superfluo qualsiasi ulteriore commento. In pratica, i commenti sono importanti ma dovrebbero essere usati con parsimonia e solo quando serve. Commentare troppo il codice, infatti, potrebbe rendere inutilmente pesanti i file sorgenti, rischiando per giunta di peggiorarne la leggibilità.

 

2) La programmazione è solo per giovani

Persiste ancora negli ambienti informatici – e non solo – l’idea per cui programmare sia una cosa solo da giovani nerd e che un programmatore, dopo una certa età, dovrebbe smettere di farlo, come se non fosse più adatto a questo compito, come se fosse tenuto per forza a delegare l’attività di coding alle nuove leve.

Questo è un falso mito perché la programmazione rappresenta una carriera accessibile a persone di tutte le età. Non c’è un limite di azianità per imparare a programmare, anzi, in realtà può valere addirittura il concetto opposto: un bravo programmatore si vede spesso dall’esperienza piuttosto che dalla competenza (sebbene quest’ultima sia molto importante). Ne consegue che un senior developer (e non solo per skill ma anche per età) sia tendenzialmente preferibile – da parte di un’azienda in termini di ingaggio – a un programmatore junior.

Più che altro pensiamo che se oggigiorno nel mercato del lavoro si assumono più giovani che anziani sia perché i primi hanno pretese economiche sicuramente inferiori dei secondi. Ma questo è un altro discorso (ci teniamo comunque a sottolineare che a noi di ESSE I di questo aspetto poco importa perché assumiamo chiunque sia valido a prescindere dall’età: qui per candidarsi per lavorare con noi).

 

3) Programmare richiede una laurea in informatica

Sia chiaro: una laurea in informatica può essere molto utile. Idem una laurea in ingegneria informatica (come ad esempio quella del nostro CEO Massimiliano Aiello, qui un articolo in cui ci abbiamo fatto quattro chiacchiere). E sicuramente non è un caso se di recente abbiamo assunto Giorgia, anche lei con una laurea in ingegneria in tasca.

Ma se ci facciamo un giro tra i CV pubblici (LinkedIn) di molte persone di successo nel settore noteremo che queste spesso non sono affatto laureate.

Noi crediamo che ci siano molte risorse online efficaci per imparare a programmare senza per forza doversi laureare, anche se consigliamo di formarsi comunque presso centri riconosciuti e seri (il corsetto veloce comprato online a 50 euro magari no). E soprattutto di fare esperienza, perché oltre al titolo è quella che definisce davvero un bravo programmatore.

 

4) Il coding è un’abilità innata

Quante volte diciamo che “Tizio è portato” per qualcosa? Il talento naturale indubbiamente esiste, però ritenere la programmazione un’abilità innata è falso.

Ma cosa significa programmare? Programmare è un'attività che riguarda la creazione di una sequenza di istruzioni scritte in uno o più linguaggi che un computer può comprendere ed eseguire. Si tratta quindi di un processo analitico che può essere imparato.

Certamente non è solo questo perché la creatività e l’intuito giocano un ruolo altrettanto importante, ma anche queste soft skill possono essere sviluppate e allenate. Insomma, la programmazione può essere imparata da chiunque e non è necessario essere un genio per diventare un buon developer.

 

5) La velocità è tutto

Persiste l’idea diffusa secondo cui mentre si fa coding bisognerebbe concentrarsi molto sulla velocità di esecuzione del codice, rendendolo il più possibile snello.

Scrivere un codice di questo tipo è sicuramente buona cosa, peccato però che possa portare a errori e a codice difficile da mantenere.

Come comportarsi allora?

A nostro avviso bisogna puntare sulla velocità soprattutto lì dove certe routine vengono eseguite molte volte, a maggior ragione se il carico sul server lo richiede o se il numero di utenti che fanno girare il codice in contemporanea è significativo.

Ma in un contesto diverso, ad esempio un software che viene fatto girare localmente da pochi utenti usando poche risorse, scrivere un codice orientato alle prestazioni può rivelarsi del tutto inutile e persino controproducente data la minore leggibilità, chiarezza e manutenibilità che, in quanto ultra-ottimizzato, potrebbe avere.

 

6) Copiare e incollare il codice è scorretto

Si crede ancora che tutto ciò che viene scritto in un programma debba essere farina del proprio sacco.

Eppure la realtà è molto diversa perché è risaputo che i programmatori riutilizzano pezzi di codice già esistenti o librerie. Insomma, il copia e incolla – diciamolo – è una pratica molto comune, quindi ritenere che copiare e incollare il codice sia sempre scorretto non è sempre vero: probabilmente si tratta di un altro luogo comune da sfatare.

È importante semmai comprendere ciò che si sta facendo, ovvero il modo in cui il codice viene copiato e incollato, e soprattutto attribuire il dovuto merito agli autori originali. Online esistono molte librerie open source e codici sorgenti scritti da terzi che possono essere riprodotti liberamente e senza necessità di menzionare l’autore. Ma non è sempre così e faremmo bene, anche per evitare sanzioni qualora venissimo scoperti, a rispettare il volere degli autori, eventualmente citandoli e linkandoli nei nostri crediti.

E poi c’è la questione Intelligenza Artificiale con tool di AI generativa come Chat GPT che ormai sfornano pezzi di codice (o addirittura interi programmi) in pochi secondi se interrogati a dovere con appositi prompt. Anche in questo contesto il copia e incolla è tutt’altro che scorretto a prescindere, ma è necessario utilizzarlo con consapevolezza ed etica se non si vuol fare danno a terzi e a sé stessi.

 

7) I programmatori sono solitari e asociali

La figura del programmatore è sempre stata collegata a quella del nerd occhialuto chiuso in cameretta alle prese con mouse e tastiera, quindi a un’idea di coder solitario e asociale. Questa idea poggia su basi solide poiché in effetti la programmazione è un’attività che richiede una profonda immersione e concentrazione: difficilmente si può scrivere un buon codice senza “isolarsi dal mondo”.

Tuttavia, noi pensiamo che da quando questa attività è diventata sociale anche questo luogo comune possa essere sfatato.

La comunicazione e il lavoro di squadra sono ormai essenziali nello sviluppo di software: piattaforme collaborative online (di cui abbiamo parlato qui, in questo articolo sul social coding) portano sempre più programmatori a uscire dalle camerette, anzi dagli uffici o, se in smartworking, ovunque si trovino, e programmare insieme.

E quindi aprirsi al mondo esterno molto più che in passato.

 

8) La sicurezza è un problema altrui

Diciamolo: molti programmatori per anni hanno scritto codice preoccupandosi solo che funzionasse, cioè senza interrogarsi circa gli aspetti della sicurezza. Un errore tipico è spesso stato quello di non curare troppo le connessioni col database, esponendosi ad attacchi di tipo “SQL Injection” in cui un ipotetico aggressore inietta comandi SQL dannosi o manipolati in un’applicazione web, allo scopo di accedere o alterare dati nei database sottostanti.

Per fortuna negli ultimi anni, grazie anche alla sempre maggiore sensibilità diffusasi su questo tema, la maggior parte dei programmatori ha compreso che la sicurezza informatica è responsabilità di tutti i programmatori, non solo di chi è specializzato in questo campo.

Si è compreso che, sebbene creare un codice sicuro al 100% sia pura utopia, prevenire è meglio che curare e che la sicurezza non può essere aggiunta in seguito, ma deve essere considerata prima ancora di scrivere la prima riga di codice.

 

9) Tutti i bug possono essere eliminati

Accanirsi nella risoluzione dei bug potrebbe essere inutile.

Infatti, come non è possibile creare del software totalmente sicuro, non è possibile creare del software completamente privo di bug.

L’obiettivo che ogni programmatore dovrebbe perseguire è semmai ridurre al minimo i bug e gestirli in modo efficace quando si presentano. Il prossimo e ultimo punto può essere utile in tal senso.

 

10) Fare test è superfluo

Last but not the least, chiudiamo questo elenco di luoghi comuni da sfatare con un pregiudizio ancora molto diffuso: quello che porta a sottovalutare la fase di test del codice. 

Quando un software è finito, un programmatore inesperto potrebbe pensare, sulle ali dell’entusiasmo, di poterlo mettere subito in produzione, ma non testare il proprio codice è un errore grave perché la fase di test è essenziale per rilevare bug (sebbene, come abbiamo visto, sia impossibile eliminarli tutti) e difetti nel software.

Affidarsi unicamente alla correzione a posteriori sulla base dei feedback di chi lo utilizzerà è un errore da evitare perché può compromettere la credibilità della software house, quindi la brand reputation.

Perché un bug può sempre sfuggire, ma non fare bene la fase di test può comportare la scoperta – con relativa brutta figura pubblica – di molto più di un bug.

 

 

Sfatando questi 10 luoghi comuni pensiamo di aver suggerito delle buone prassi per correggere altrettanti errori di programmazione (e anche di approccio). Siamo convinti che in questo mondo – quello informatico nel quale siamo totalmente immersi – ci sia ancora molto da fare, soprattutto riguardo al tema della consapevolezza e dell’etica, ma al motto di "harmony, not just bits" riteniamo di essere sulla buona strada.

E tu che ne pensi?

Ci sono altri luoghi comuni diffusi nel mondo del coding che secondo te andrebbero sfatati? Faccelo sapere con un messaggio privato o un commento sui nostri canali social! E se ti piacciono i nostri articoli, non dimenticare di iscriverti alla nostra newsletter.

 

(foto: Midjourney)