Nell’economia moderna il concetto di qualità sta diventando sempre più determinante nel decidere la sorte (successo o fallimento) di un prodotto. Nel caso di un software gestionale come Slope, la qualità si misura sotto due aspetti principali:
Per noi di Slope, un’interfaccia utente “di qualità” è una UX intuitiva ed immediata, e dall’aspetto grafico moderno e di impatto.
La qualità del funzionamento di un software è invece misurabile in termini di affidabilità e correttezza dei dati, tutto questo per garantire prestazioni elevate e tempi di risposta veloci.
In questo articolo spiegheremo qualche retroscena circa gli strumenti tecnologici e le metodologie che utilizziamo per garantire che Slope sia un software estremamente robusto e scalabile.
L’intera piattaforma Slope è coperta da test automatici. I test automatici sono degli algoritmi il cui compito è mettere alla prova una o più unità di codice che vanno a costituire le funzionalità del software gestionale.
Come pratica aziendale abbiamo definito che nessun ingegnere può rilasciare del codice che non sia coperto da un numero sufficiente di test automatici, niente eccezioni!
La scrittura di test richiede del tempo ma è un investimento sul lungo termine, proprio perché al crescere della complessità del progetto-software, il rischio di introdurre regressioni funzionali su altre componenti della piattaforma diventa rilevante.
Un software gestionale che ha una buona “test coverage” (molto codice coperto da test) sarà quindi molto più robusto e meno propenso a rotture. Un software di questo tipo potrà evolvere ed introdurre nuove funzioni in modo molto più veloce ed agile.
Avere una cultura aziendale che permette agli sviluppatori di dedicare tempo per la scrittura di test è fondamentale per creare un ottimo software, ma è ancora più importante avere infrastrutture automatiche che si occupino di eseguire i test in modo consistente ad ogni sottomissione (in gergo tecnico “push”) del codice.
Per spiegarci meglio vi facciamo l’esempio in cui uno sviluppatore va ad implementare una nuova funzione, quando questo avrà ultimato il suo lavoro (sia l’implementazione della funzione che la scrittura dei relativi test), invierà il codice al server che ospita i “repository” con tutto il codice. Automaticamente viene avviata l’esecuzione di tutti i test automatici della piattaforma.
Per eseguire i test a Slope abbiamo un cluster di server detti di “continuous integration” che si occupano di eseguire i test automatici ogni qual volta uno sviluppatore invia il codice al “repository” centrale.
Su questi server è in esecuzione “Jenkins” uno strumento di continuous integration che si occupa di verificare lo standard qualitativo del codice inviato ed esegue tutti i test.
Se l’esito dell’esecuzione dei test è positivo, il responso di Jenkins per quella specifica funzionalità sarà “verde”, altrimenti “rosso”.
Nel caso di esito negativo (“rosso”), sarà compito dello sviluppatore di sistemare il problema che ha “rotto” i test prima di poter richiedere l’integrazione della sua funzione nel codice di produzione (cioè quello che utilizzano i clienti).
Un’altra pratica che seguiamo in maniera rigida è quella della code review. Ogni singola riga di codice scritta da un ingegnere viene sempre revisionata da una seconda persona. Questa pratica offre alcuni grandi vantaggi:
Trovare bug (difetti del codice) in anticipo evita problemi spesso riscontrati nel testing del software o addirittura durante il rilascio del prodotto stesso. Fornire un prodotto non perfettamente funzionante è dannoso per l’immagine dell’azienda e per la soddisfazione del cliente.
Oltre ai vantaggi sopra citati, la revisione del codice apporta valore guidando il team nel creare un ambiente di lavoro collaborativo e produttivo. Condividendo le proprie azioni alla fine delle singole attività di lavoro, i colleghi potrebbero segnalare modi migliori per approcciarsi alla soluzione del problema migliorando il risultato finale.
L’infrastruttura hardware Slope è continuamente monitorata per misurare il carico generato dal traffico sui server che servono le applicazioni le quali compongono la piattaforma gestionale.
Nell’improbabile evenienza di cui uno dei web server dovesse diventare non raggiungibile, il team operations che si occupano della gestione dell’infrastruttura viene immediatamente informato (tramite notifiche via email ed SMS) così da intervenire e risolvere le problematiche prima che l’utilizzatore della piattaforma possa essere in qualche modo impattato dal problema.
Altro aspetto interessante è l’invio di notifiche a tutto il team di sviluppo circa errori critici generati dal sistema. Ogni qual volta l’utente si imbatte in un caso non gestito dal software questo invia una notifica agli ingegneri per informarli sull’eccezione.
In questo modo possiamo intervenire nella risoluzione del problema in maniera proattiva ed in molti casi risolvere problemi ancora prima che il cliente contatti il supporto clienti per richiedere informazioni.
Molti albergatori vedono la SEO per hotel (ottimizzazione per i motori di ricerca) come un'arte…
Recensione del libro "Revenue Management per Hotel, dalla strategia distributiva all'automazione tariffaria" di Marco Matarazzi…
Il 2025 prosegue con un appuntamento imperdibile: la partecipazione al TTG, la fiera di riferimento…
Il mercato alberghiero italiano è prevalentemente composto da hotel indipendenti, ciascuno con le proprie specificità…
Nel mondo del marketing alberghiero c'è una nostalgia palpabile per i "bei tempi" di Universal…
Nel mondo del revenue management alberghiero, le decisioni sono spesso un cocktail esplosivo di numeri,…