Dietro le quinte
Ecco il nostro stack tecnologico
di Nicolas Lefebvre
Dall'università al co-sviluppo della nuova funzione top
7.2.2023
Traduzione: Leandra Amato
In qualità di dipendente neurolaureato, ho potuto contribuire alla nuova funzione di trasparenza sulla ritenuta di garanzia e la percentuale di resi. Da sviluppatore software junior, do uno sguardo dietro le quinte.
È un tardo pomeriggio di metà novembre del 2022. Il team Isotopes, dove avevo iniziato come junior due mesi prima, guarda un monitor con trepidazione: il mio collega Daniel e io abbiamo appena apportato le ultime modifiche al codice e per la prima volta vediamo la nostra nuova funzione per la ritenuta di garanzia e la percentuale di resi dal vivo e con dati reali. Finora avevamo lavorato solo con valori arbitrari a scopo dimostrativo.
È questo il momento che mi affascina tanto dello sviluppo del software: il momento in cui l'intera catena di automazione funziona come una macchina ben oliata. I dati che possono essere interpretati in forma grezza solo con un grande sforzo vengono elaborati in modo completamente automatico in frazioni di secondo in unità di informazione visivamente e contestualmente comprensibili e interessanti.
Ora, naturalmente, tutti i membri del team vogliono sapere come stanno andando i loro marchi preferiti. Quindi, per i prossimi dieci minuti, i produttori di smartphone, schede grafiche e cuffie saranno messi l'uno contro l'altro. Poi entrano in gioco anche i marchi di e-scooter e di droni.
Cibo per il nostro database
Ma cosa succede dietro le quinte della nuova funzione? In una prima fase, abbiamo ovviamente bisogno di dati grezzi, ovvero la ritenuta di garanzia, la percentuale di resi e la durata media dei casi di garanzia del rispettivo marchio per le categorie corrispondenti. I valori, forniti dal team di sviluppo After-Sales KickAss, vengono memorizzati per noi dal team di business intelligence Cyclops in un database BigQuery. I dati vengono aggiornati quotidianamente.
Per i geek che vogliono maggiori dettagli: recuperiamo i dati con un lavoro automatico e li conserviamo nel nostro MongoDB. Se un cliente visita la pagina dei dettagli di un prodotto, il back-end fornisce i dati corrispondenti da MongoDB. Questo viene fatto sulla base del prodotto in questione o sulla base dell'API richiamata.
Poiché il nostro negozio è accessibile in diversi paesi e la gamma di prodotti di un marchio può variare a seconda del paese, dobbiamo calcolare le classifiche visualizzate separatamente a seconda della categoria, del marchio e del paese. Ad esempio, le lavatrici di un marchio possono quindi essere prime per quanto riguarda la ritenuta di garanzia in Germania, mentre in Svizzera arrivano solo al secondo posto.
Per evitare che si acceda al database ogni volta che si richiama l'ultimo smartphone e si debbano ricalcolare tutte le classifiche, salviamo i dati più utilizzati. Questo avviene in un cosiddetto repository, dove i dati vengono conservati in-memory nella cache. Ciò comporta un minor carico sul database con un requisito di memoria relativamente basso e quindi anche tempi di caricamento più brevi per la nostra clientela. Quindi è una situazione vantaggiosa per tutti.
Da junior nel bel mezzo dell'azione
Io stesso ho trascorso la maggior parte del tempo a sviluppare questa funzione scrivendo in codice C# per il nostro ambiente .NET. Ad esempio, ho dedicato molte energie alla logica di classificazione dei marchi di cui sopra e l'ho implementata con un approccio test-driven.
Secondo il mio contratto sono impiegato come ingegnere back-end, eppure ho potuto contribuire all'intera implementazione, dalla lettura dei dati dalla BigQuery a parti della logica di visualizzazione nel front-end. Questa flessibilità e versatilità del mio lavoro è dovuta principalmente al modo in cui lavoriamo nei team: dal design dell'interfaccia utente allo sviluppo del back-end, implementiamo l'intera funzionalità per il negozio online in un unico team, ad eccezione delle dipendenze esterne, ovviamente.
L'implementazione su larga scala della funzione e l'intero processo di sviluppo sono stati per me un punto di forza: da un lato, ho potuto imparare molto sull'architettura del sistema e sullo sviluppo del software in C#, soprattutto in «pair programming» con Daniel, il Software Architect del nostro team. D'altra parte, siamo riusciti a implementare la funzione in modo efficiente e senza spese amministrative. Anche le piccole modifiche alla funzionalità possono essere messe in funzione nel più breve tempo possibile grazie al «continuous deployment (CD)». Questo permette ai ruoli meno tecnici, come i nostri team di UX designer, di avere una visione diretta dello stato attuale dello sviluppo e di ricevere un feedback immediato.
Se vuoi saperne di più sul panorama dei sistemi di Digitec Galaxus, puoi trovare il nostro Technology Stack qui.
Tornare al codice invece di scrivere articoli
Lo sviluppo di queste funzionalità, che voglio utilizzare io stesso come cliente, è una delle principali motivazioni del mio lavoro. Sono quindi impaziente di vedere i prossimi punti della lista delle cose da fare per il team Isotopes. Senza svelare troppo: ci dedicheremo alla rivendita dei prodotti e al continuo miglioramento delle informazioni dei prodotti.
Quali funzioni vorresti vedere da noi? E cosa ne pensi della nuova funzione di trasparenza? Fammelo sapere lasciando un commento in fondo alla pagina.
Marc Zuber
Software Engineer
Marc.Zuber@digitecgalaxus.chI giochi mi affascinano fin da quando ero bambino. Quello che allora era Mario Kart su N64 si è trasformato in un'ampia passione per vari argomenti tecnologici. Dalla realtà virtuale all'automazione dei processi tramite coding, sono costantemente alle prese con nuovi hobby e progetti.
Tecnologia
Segui gli argomenti e ricevi gli aggiornamenti settimanali relativi ai tuoi interessi.
37 commenti
later