Aree di competenza / Dato, applicazione ed esperienza / 3.1
Software Engineering & App Development
Il codice è la parte facile.
Un prototipo credibile oggi si costruisce in pochi giorni. Il problema vero arriva dopo: quel software diventa indispensabile a qualcuno, cambia requisiti tre volte, sopravvive a chi l’ha scritto. Ogni riga scritta oggi è un impegno di manutenzione che qualcuno dovrà onorare, e un sistema che non si osa più toccare ha smesso di servire.
Per questo sviluppiamo con rigore da ingegneria. Strutture modulari, interfacce esplicite e versionate, decisioni documentate, test a più livelli, dipendenze scelte perché dureranno e non perché sono di moda. Quando c’è un sistema esistente da modernizzare, non proponiamo di buttarlo: lo sostituiamo per parti, mentre continua a funzionare.
Un’azienda può partire da un’applicazione su misura che nessun prodotto copre; un gestore di servizi dall’ammodernamento di un sistema che regge l’operatività ma che nessuno sa più modificare. Il codice è la parte facile. La parte difficile è la sua vecchiaia, ed è lì che mettiamo il nostro lavoro.
Tre gruppi di competenza
Ogni gruppo ha un dettaglio tecnico per chi lo vuole.
- 3.1.a
Architettura, qualità e modernizzazione
Software che si può ancora cambiare fra sette anni.
Modernizziamo i sistemi esistenti per parti, senza fermarli, e strutturiamo il nuovo software perché resti modificabile. Ogni scelta tiene conto di chi dovrà mantenerlo.
Dettaglio tecnico
Il gruppo comprende la struttura del software e la sua modernizzazione. In produzione: strangler pattern per sostituire i sistemi esistenti per parti, test su più livelli (unità, integrazione, contratto, end-to-end). In progetto: domain-driven design, architetture esagonali, a microservizi e a eventi, anti-corruption layer, architecture decision record, misura e gestione del debito tecnico.
- 3.1.b
Linguaggi e framework
Strumenti scelti per durare.
Sviluppiamo con linguaggi e framework maturi, dal backend al frontend fino al software di sistema. Scegliamo lo strumento in base a quanto a lungo il sistema dovrà vivere.
Dettaglio tecnico
Il gruppo comprende linguaggi e framework di sviluppo. In produzione: Java ed ecosistema JVM, Python, TypeScript, C e C++, framework backend Spring, FastAPI e .NET, framework frontend React, Vue e Angular. In progetto: Go. Rust è seguito come linguaggio emergente per il software di sistema.
- 3.1.c
API, integrazione e messaggistica
Ogni interfaccia è un contratto.
Progettiamo le interfacce tra sistemi come contratti documentati e versionati. Un aggiornamento non deve rompere chi dipende da quel servizio.
Dettaglio tecnico
Il gruppo comprende le interfacce tra sistemi. In produzione: API REST documentate con OpenAPI, versionamento con retrocompatibilità, autenticazione OAuth 2.0, OpenID Connect e JWT. In progetto: GraphQL, gRPC e Protocol Buffers, message broker Kafka, RabbitMQ e NATS, integrazione iPaaS ed ESB, caching con Valkey, Redis e CDN.
Per il lettore tecnico
Scrivere software che funziona è diventato relativamente facile. Il problema irrisolto è la sua vecchiaia: che cosa accade a quel software fra sette anni, quando chi lo ha scritto non c’è più, le dipendenze sono cambiate e il sistema è diventato indispensabile. Il dominio sviluppa con criteri di ingegneria orientati alla durata: struttura modulare, contratti espliciti tra componenti, decisioni documentate, dipendenze scelte per la loro longevità.
Il dominio lavora su tre gruppi. L’architettura, la qualità e la modernizzazione comprendono in produzione lo strangler pattern, che sostituisce i sistemi esistenti per parti senza interrompere il servizio, e una strategia di test su più livelli (unità, integrazione, contratto, end-to-end); domain-driven design, architetture esagonali, a microservizi e a eventi, anti-corruption layer, architecture decision record e misura del debito tecnico sono portati in progetto. I linguaggi e i framework comprendono in produzione Java, Python, TypeScript, C e C++, i framework backend Spring, FastAPI e .NET e i framework frontend React, Vue e Angular; Go è portato in progetto. Le API, l’integrazione e la messaggistica comprendono in produzione API REST documentate con OpenAPI, versionamento con garanzia di retrocompatibilità e autenticazione OAuth 2.0 e OpenID Connect, e in progetto GraphQL, gRPC, message broker Kafka, RabbitMQ e NATS, integrazione iPaaS e caching.
Il principio progettuale è che un sistema che non si può modificare ha smesso di servire. Per questo ogni scelta si valuta anche per il costo di manutenzione che introduce, e ogni interfaccia tra componenti è un contratto versionato.
Il dominio si appoggia alla catena di rilascio del dominio 2.3, sviluppa le integrazioni con i gestionali del dominio 3.2 e i frontend progettati nel dominio 3.4; lo sviluppo in C e C++ si estende ai dispositivi del dominio 1.3. È una competenza necessaria ma non distintiva: si dichiara con precisione e non si usa in apertura.
Parliamo del vostro sistema
Raccontateci il requisito di servizio: che cosa deve funzionare, entro quanto, e che cosa succede quando qualcosa si rompe. La tecnologia la scegliamo dopo.