Le difficoltà che un programmatore si trova più spesso ad affrontare

Photo by Ketut Subiyanto / Pexels

Durante la programmazione di software, durante i progetti e il lavoro in team è normale incontrare delle difficoltà, delle sfide da affrontare. Spesso, queste vengono vissute come delle esperienze negative, ma in realtà possono aiutarci a crescere sia a livello lavorativo che personale. In questo articolo cercheremo di mostrarti tutti i principali problemi quotidiani con cui un programmatore si scontra, e ti spiegheremo come superarli.

Le difficoltà del programmatore

Si può dire che il lavoro del programmatore sia quello di risolvere i problemi. Sostanzialmente, quindi, ogni volta che una sfida si interpone tra noi e la consegna, significa che c’è del lavoro da fare. Proprio per questo tentare di schivarli è inutile: dimostrare la capacità di superarli è fondamentale e rappresenta la vera differenza tra un professionista e un dilettante. Andando più nel concreto, tra le prime difficoltà che un programmatore si trova a superare ci sono tutti quei passaggi determinanti per arrivare alla consegna di un progetto, per soddisfare un cliente. E quelle che per un programmatore alle prime armi sono insormontabili, una volta risolte faranno poi di lui un esperto. Tutto questo per dire che è impossibile diventare senior aggirando gli ostacoli.

Nel mondo della programmazione, le difficoltà si traducono in scadenze stringenti, opacità dei requisiti, volatilità dei requisiti. Poi ancora mancanza di competenze o conoscenze specifiche necessarie, architettura studiata con superficialità e codice scritto con errori. Tutte queste sfide possono presentarsi, ovviamente, anche a un esperto, ma quest’ultimo sarà in grado di riconoscerle e di risolverle molto più in fretta.

Due tipi di ostacoli: quelli della progettazione e quelli dello sviluppo

Possiamo dividere le difficoltà del programmatore in due categorie: quelle legate alla progettazione e quelle dello sviluppo. Gli ostacoli di progettazione riguardano i cinque pilastri di un progetto: obiettivo, scadenze, costi, valore e qualità. I primi tre sono quelli definiti nel project management classico. Gli ultimi due, invece, vengono individuati e aggiunti nell'ambito del project management di tipo agile, che raggruppa i primi tre sotto l'etichetta di vincoli. In ogni progetto alcuni di questi pilastri saranno fissati, altri saranno prioritari ma flessibili, altri invece saranno liberi di discostarsi dalle aspettative.

Pianificazione e requisiti, poi, sono ostacoli che rischiano di mettere a repentaglio i pilastri del project management. Sostanzialmente, sono le scadenze irrealistiche e/o di una definizione grossolana. Oppure troppo esigente dei requisiti del prodotto. A pagarne i costi sarà uno dei tre pilastri classici: sacrificare l’obiettivo, sacrificare le scadenze e sacrificare i costi. Sacrificare l’obiettivo significa che, per salvare costi e scadenze, è possibile fare una scrematura dei requisiti e arrivare in tempo e in budget con un prodotto meno ricco di funzionalità. Sacrificare le scadenze, invece, è l’accettazione di consegnare in ritardo. Infine, quando si decide di sacrificare i costi si decide di non arrivare in ritardo, ma si accetta di impiegare una quantità di risorse maggiore del previsto. Normalmente, il sacrificio dei costi è l'opzione meno desiderabile, anche se spesso è quello preferito dai piani alti dell’azienda. Si usa infatti per evitare brutte figure, penali e altri tipi di problemi generalmente legati ai vincoli contrattuali della fornitura. Di solito però si traduce in una strategia controproducente.

Agli ostacoli agili

La progettazione agile riconosce i pilastri della progettazione classica, ma in aggiunta analizza due elementi fondamentali per la realizzazione di un buon prodotto: valore e qualità. Gli ostacoli agili mettono a repentaglio questi due pilastri, oppure gli altri tre (i vincoli) nell'insieme: il prodotto che è stato pensato non dà realmente valore al cliente; il modo in cui il progetto è stato pianificato e viene coordinato mette a repentaglio la qualità del prodotto; chi realizza il prodotto non ha ben chiara l'esigenza del cliente e infine il codice è scritto in modo frettoloso, grossolano, incoerente… Anche in questo caso bisogna rendere sacrificale almeno un pilastro di tre: sacrificare i vincoli, il valore o la qualità.

Gli ostacoli di sviluppo

Gli ostacoli di sviluppo possono essere suddivisi in cinque macro categorie. Ci sono i Calderoni, ovvero lassi, funzioni o moduli pieni di funzionalità eterogenee non ben delineate e tutte collegate tra loro in modo caotico e imprevedibile. In questa categoria rientrano anche funzioni con più di 3 o 4 parametri e classi con più di 10 proprietà o metodi. Questo di solito deriva da una continua espansione di ciò che un componente deve fare, oppure da una scarsa chiarezza di cosa fa all'interno del programma. Le ripetizioni, poi, sono i codici copia-incolla, magari riadattati leggermente. Questo denota scarsa capacità di astrazione o scarsa attitudine a costruire componenti riutilizzabili. In altre parole rivela una propensione del programmatore a lavorare molto con le dita e poco con la testa.

L’ermetismo, poi, è caratterizzato da nomi di variabili o funzioni troppo abbreviati, termini molto simili che non chiariscono la differenza tra due elementi, variabili che nascono per fare una cosa e poi ne fanno altre ma mantengono un nome inconsistente. I cablaggi, invece, sono la compresenza di diversi livelli di astrazione. E’ il caso di parametri di configurazione (di solito stringhe di percorsi o indirizzi) "schiantati" nel codice, ma anche di complesse espressioni di basso livello (calcoli matematici, lunghi switch statements, cicli...) collocate in metodi o funzioni di alto livello, che dovrebbero descrivere un comportamento e non un’implementazione. Infine c’è l’incoerenza: nello stile o nei contenuti, l'incoerenza è un problema. Quella di stile rende meno leggibile il codice. Quella di contenuto, invece, rende inconsistente il comportamento del software.

Un altro consiglio che ci sentiamo di darvi è: non evitate le conversazioni spiacevoli. Se anche, all’interno del team, siete unici a vedere un problema, segnalatelo, così da porre le basi a una eventuale soluzione. Infine, imparate ad ascoltare le vostre emozioni, quelle dei vostri colleghi e dei committenti, e a pesare le informazioni. Solo così si riuscirà ad avere un campione di ciò che potete aspettarvi riguardo a un progetto.

Non iniziare da solo, iscriviti a Develhope.

Saveria

Saveria