Questo post fa parte della serie di articoli Ma quanto mi costi?

Quando comprate un software, sito, app o gestionale che sia, acquistate sostanzialmente una montagna di codice.

Quel codice che probabilmente non guarderete mai è proprio ciò che giustifica il prezzo che avete pagato.

"Ma a me interessa il prodotto finale, non cosa c'è dietro", diranno in molti.

Questa affermazione sembra lecita: se il prodotto fa quello che deve fare la storia finisce qui. Ecco, il problema è proprio qui: la storia non finisce mai qui.

Qualsiasi software avrà bisogno di essere tenuto aggiornato e facilmente in futuro avrete bisogno di fare modifiche, aggiungere o togliere funzioni, aggiornare la grafica ecc. Qui entrano in gioco i costi nascosti.

Se inizialmente siete andati al risparmio o comunque non vi siete informati sul come viene sviluppato il vostro software i problemi futuri potrebbero essere tanti.

Costi elevati per piccole modifiche, instabilità del sistema, performance inaccettabili, impossibilità di stare al passo con gli aggiornamenti di sicurezza sono tutti segnali che vi siete affidati alle persone sbagliate.

 

Come è possibile quindi sapere se il nostro fornitore lavora bene? Basta fargli qualche domanda un pò tecnica, ad esempio:

Viene scritto tutto "da zero" o vi basate su qualche popolare framework? Potete farci vedere il codice?

Scrivere del software partendo da zero significa investire tempo (e quindi budget) per implementare funzionalità comuni che esistono già sotto forma di librerie o framework, e che funzionano bene.

Io personalmente consiglio anche di diffidare delle soluzioni sviluppate internamente di cui non si sa nulla: non c'è nessuna garanzia che siano valide e che possano essere ben supportate in futuro.

Il codice è corredato da tests?

Qualsiasi progetto serio non può essere testato controllando manualmente che ogni singola funzionalità faccia esattamente quello che deve fare. Un'operazione del genere richiede ore e ore, è prona ad errori e andrebbe ripetuta ad ogni modifica del codice!

Non si può quindi prescindere dall'avere una serie di test automatizzati che controllano il corretto funzionamento delle parti più critiche e che vengono lanciati spesso, come minimo prima di ogni messa in produzione di modifiche.

I costi si alzano, certamente, ma il livello qualitativo del prodotto finale non ha niente da spartire con il vecchio "ok, dovrebbe funzionare".

Come fate il "deploy" in produzione?

Mettere online delle modifiche è una situazione estremamente critica dove non sono permessi errori. Il nuovo codice deve andare in produzione senza introdurre problemi e downtime, in modo totalmente trasparente per l'utente finale.

Anche qui non può esistere il concetto di farlo "a mano": le procedure devono essere automatiche, robuste e ripetibili. Se sentite parlare di FTP probabilmente avete un problema!

 

Concludo facendo un sentito ringraziamento alla community Ruby.

La cosa forse più importante che mi ha insegnato è che si può lavorare bene, rendendo soddisfatti se stessi e i clienti. Scrivere tests, fare refactoring, sviluppare in coppia, automatizzare le procedure di deploy e le configurazioni dei server sono tutte cose ormai radicate da anni nella nostra comunità di sviluppatori.