---

In SPOT. sviluppiamo software e scriviamo codice, lo facciamo lavorando in team di progetto o come membri di un gruppo di lavoro allargato, in veste di consulenti. Ci troviamo, quindi, a condividere le famose righe di codice, componendole a più mani e più teste, un po’ come se scrivessimo un libro con un altre persone. E fin qui, ci muoviamo in un terreno conosciuto.

Cosa succede, invece, quando il cliente ci chiede di prendere in mano progetti scritti da altri team? La sfida diventa quella di interpretare e individuare i punti di intervento, nel più breve tempo possibile. Scrivere codice è davvero come scrivere un testo: insieme a regole consolidate (le regole di sintassi e grammatica, per capirci), ci sono aspetti soggettivi. Per esempio uno “snippet” (porzione di codice), o una routine possono essere scritti in 10 righe, o in 6 e il risultato è il medesimo. Anche nel nostro campo, ci sono tante best practices ed esistono in letteratura modi migliori di altri, ma lo spazio di “stile personale” è vasto.

Come ci orientiamo quindi? Come nel calcio, “l’importante è il risultato e se il programma funziona siamo contenti tutti”, potrebbe sintetizzare qualcuno. Tuttavia, i buoni risultati non si ottengono se dietro non c’è una vera e propria squadra coesa, che “faccia spogliatoio”.

Nella mia esperienza di sviluppatore software, ho imparato a pormi costantemente una domanda: “se qualcuno altro dovesse mettere mano al mio codice, saprebbe dove mettere le mani?”.

Partiamo dal facile: se si scrive del codice, questo deve avere una determinata coerenza e deve essere “comprensibile”, ovvero, i miei colleghi e le mie colleghe, o anche i clienti, essendo noi una software house, devono poter fare le opportune modifiche e gli interventi necessari anche in mia assenza.

In questo senso, in SPOT., ci stiamo strutturando in modo tale da avere una code base comune, in modo che ogni nostro progetto abbia lo stesso “core“ e che più progetti abbiano una struttura di codice simile (pensiamo alle stesse librerie, di utilità comune, etc.), in modo da rendere agevoli i passaggi o gli interventi nei diversi progetti di sviluppo software.

Al di là dell’esperienza e delle specifiche capacità di ogni programmatore, molte volte il “codice è scritto male” per mancanza di tempo o voglia. Per rendere meglio l’idea, entriamo nel dettaglio di qualche curiosa composizione che ho incontrato sulla mia strada.

Fig.1

Qui ci sono due errori, il primo è che un team deve avere la convenzione di adottare una lingua “comune” nella scrittura, che nel 99,99% dei casi è l’inglese. Il secondo errore, beh forse troppo difficile da “trovare” 🙂

Fig.2

Questo è il tipico caso in cui, quando ci si mette mano dall’esterno, si rischia di perdere parecchio tempo: da fuori vedi il metodo update e pensi faccia la stessa cosa per tutti, ma finché non vedi l’implementazione mai penserai che per il tipo Custom faccia qualcosa di diverso.

Ecco perché, quando scriviamo codice, diventa strategico per il miglior lavoro di tutti, tornare alla domanda iniziale: se qualcuno altro dovesse mettere mano al mio codice, saprebbe dove mettere le mani?