L’arte del rilascio

Un buon progettista software è un pragmatico

di

thumbnail

30

nov

2018

Hai lavorato sul tuo progetto. Le funzionalità sono a posto e hanno passato i test. Puoi tirare un sospiro di sollievo. Hai finito.

Ne sei proprio sicuro? Quel funzionalità a posto significa pronte per la Produzione? Il sistema è davvero pronto per essere distribuito? Funzionare in un ambiente di lavoro e può affrontare senza di te le orde di utenti veri del mondo reale?

La progettazione del software, così come viene insegnata oggi, è drammaticamente incompleta. Dice solo quello che i sistemi dovrebbero fare. E quindi non si occupa del contrario: di quello che i sistemi non dovrebbero fare. Non dovrebbero andare in crash, bloccarsi, perdere dati, violare la privacy, far perdere denaro al cliente, distruggere la vostra azienda e, possibilmente, neanche uccidere i vostri clienti.

Puntare al bersaglio giusto

La progettazione del software oggi somiglia al design di automobili nei primi anni Novanta: è scollegata dal mondo reale. Le auto, progettate esclusivamente nel comfort del laboratorio, sembravano magnifiche nei modelli e nei sistemi CAD. Vetture dalle curve aerodinamiche brillano di fronte ai grandi ventilatori che inviano un perfetto flusso laminare. I progettisti che popolano questi spazi così ricchi di serenità producono progetti eleganti, sofisticati, intelligenti, ma fragili, insoddisfacenti e, in ultima analisi, di breve durata. La maggior parte dell’architettura e della progettazione del software vede la luce in ambienti altrettanto puliti e lontani dalla realtà.

Davvero la vorreste una macchina bellissima, ma che trascorre più tempo dal meccanico che sulla strada? Certo che no! Probabilmente vorrete possedere una macchina fatta per il mondo reale. Volete una macchina progettata da qualcuno che sa che i cambi d’olio vengono fatti sempre con 3.000 chilometri di ritardo, che le gomme devono funzionare altrettanto bene da nuove e all’ultimo millimetro di battistrada e che, certamente, a un certo punto debba sopportare una gran pedata sui freni mentre tenete un hamburger in una mano e il telefono nell’altra.

Quando il nostro sistema passa il vaglio della Quality Assurance (QA), possiamo davvero dire che sia pronto per la Produzione? Il semplice passaggio della QA ci dice poco circa l’idoneità del sistema nei prossimi tre-dieci anni di vita. Potrebbe rivelarsi la Toyota Camry del software e accumulare migliaia di ore di utilizzo continuo. Oppure potrebbe finire per essere la Chevy Vega (una vettura che faticò già nel corso dei test interni) o la Ford Pinto (una macchina incline a saltare in aria, in particolari condizioni). È impossibile che un paio di giorni o anche di settimane di test possa dire ciò che avverrà nei prossimi anni.

Controllo qualità meccanico

Nel software, come nella meccanica, il controllo qualità è molto, ma non tutto.

 

I progettisti che lavorano in Produzione hanno a lungo perseguito la progettazione per la producibilità: l’approccio ingegneristico alla progettazione di prodotti che possano essere fabbricati a basso costo e con elevata qualità. Ma prima di oggi, i progettisti e i fabbricanti di prodotti vivevano in mondi diversi. I disegni appesi alla parete della Produzione comprendevano viti irraggiungibili, parti difficilmente riconoscibili e parti realizzate su ordinazione quando bastava impiegare componenti da scaffale. Inevitabilmente, ciò ha portato a una bassa qualità e a un elevato costo di produzione.

Oggi siamo in una situazione simile. Finiamo per non riuscire a terminare il nuovo sistema, perché stiamo costantemente rispondendo alle chiamate di supporto per l’ultimo progetto che, pronto solo a metà, abbiamo immesso a forza sul mercato. Per noi l’analogo della progettazione per la producibilità è la progettazione per la Produzione. Noi non mandiamo progetti ai produttori, ma inviamo il software finito ai clienti. Abbiamo bisogno di progettare i singoli sistemi software, ma anche l’intero ecosistema di sistemi interdipendenti, in modo che operino a basso costo e a elevata affidabilità.

La portata della sfida

Ai tempi, facili e tranquilli, dei sistemi client/server, la base di utenti di un sistema si sarebbe misurata in decine o centinaia di unità con, al massimo, una dozzina di utenti concorrenti. Oggi vediamo regolarmente conteggi di utenti attivi ben superiori e con una popolazione che si estende su interi continenti. E non intendo l’Antartide o l’Australia! Il primo social network, oggi, conta miliardi di utenti e non sarà l’ultimo.

Sono aumentate anche le richieste in termini di uptime. Mentre il famoso tempo di uptime a “cinque nove” (99,999 percento) era un tempo tipico per i sistemi a mainframe e per i suoi operatori, oggi anche i siti di commercio di articoli da giardino richiedono una disponibilità 24/7/365 (questa sigla mi ha sempre infastidito: da ingegnere, mi aspetterei che sia 24/365 oppure 24/7/52). Chiaramente, abbiamo compiuto enormi passi avanti anche nel considerare la scalabilità del software costruito oggi; ma aumentando la portata e la scala dei nostri sistemi, scopriamo sempre nuove occasioni di guasto, ambienti sempre più ostili e una tolleranza sempre minore ai difetti.

Uptime

Persino il più amatoriale dei siti, oggigiorno, vuole essere sempre raggiungibile.

 

La crescente portata di questa sfida (costruire software veloce che sia economico da realizzare, efficace per gli utenti ed economico anche nell’utilizzo) richiede continui raffinamenti dell’architettura e delle tecniche di progettazione. Una progettazione appropriata per i piccoli siti web di WordPress fallisce clamorosamente se applicata a sistemi distribuiti a larga scala, transazionali.

Milione più, milione meno…

Durante la frenetica corsa dello sviluppo di un progetto, è fin troppo facile prendere decisioni che ottimizzano i costi di sviluppo a scapito dei costi operativi. Immaginate che il vostro sistema richieda cinque minuti di downtime a ogni release. Ci si aspetta che il sistema abbia un orizzonte di vita di cinque anni, con release mensili (la maggior parte delle aziende vorrebbe far uscire più release all’anno, ma non voglio esagerare). Potete calcolare il costo previsto dei tempi di inattività, scontato per il valore temporale del denaro. Probabilmente la cifra sarà dell’ordine di un milione di dollari (300 minuti di downtime a un costo molto modesto di 3.000 dollari al minuto).

Supponiamo ora che possiate investire 50.000 dollari per creare una sequenza di compilazione e un processo di distribuzione che eviti di incorrere in tempi di inattività durante le release. Come minimo, scongiurereste una perdita da un milione di dollari.

Usare la forza

Le decisioni iniziali sono quelle che hanno il maggiore impatto sulla forma finale del sistema, perché possono essere le più difficili da invertire. Ironia della sorte, sono anche le meno informate. All’inizio il team per lo più ignora quale sarà la struttura finale del software e tuttavia è qui che devono essere prese alcune delle decisioni più irrevocabili.

Mi dichiaro, qui e ora, fautore dello sviluppo agile. L’enfasi sulla consegna anticipata e sui miglioramenti incrementali fa sì che il software entri rapidamente in Produzione. Dal momento che la Produzione è l’unico luogo in cui si può imparare come il software reagirà agli stimoli del mondo reale, sostengo un approccio che consenta di iniziare il processo di apprendimento il più presto possibile. Anche su progetti agili, è meglio che le decisioni vengano prese con lungimiranza.

Usare la Forza

“Usare la Forza” per progettare con lungimiranza e battere i problemi immediati.

 

Sembra proprio che il progettista debba “usare la forza” per prevedere il futuro, al fine di selezionare la struttura più solida. Poiché alternative differenti spesso hanno costi simili di implementazione, ma costi radicalmente differenti nel ciclo di vita, è importante considerare gli effetti di ogni decisione in termini di disponibilità, capacità e flessibilità.

Architettura pragmatica

Sono due le attività, divergenti, che rientrano nel termine architettura. Un tipo di architettura punta verso i livelli più elevati di astrazione, che risultino maggiormente portatili su più piattaforme e meno legati ai dettagli dell’hardware, delle reti, degli elettroni e dei fotoni. La forma estrema di questo approccio si traduce in una torre d’avorio: una camera asettica alla Kubrick abitata da guru completamente avulsi dal mondo e piena di grafici e frecce, tracciati su ogni parete. I decreti emessi dalla torre d’avorio discendono sui programmatori al lavoro. Che il middleware sia JBoss, ora e per sempre!, Che le interfacce utente siano costruite con Angular 1.0!, Tutto ciò che è stato, che è e che sarà vive in Oracle!, Non commettere atti impuri con Ruby!. Se vi è mai capitato di digrignare i denti, mentre programmavate qualcosa secondo gli standard aziendali imposti mentre sarebbe dieci volte più facile farlo con qualche altra tecnologia, allora sapete già che cosa significa essere vittime di un architetto da torre d’avorio.

Al contrario, un’altra razza di architetto non solo sta fianco a fianco con i programmatori, ma è uno di loro. Questo tipo di architetto non esita a sacrificare un po’ un’astrazione o a disfarsene, se scopre che non è adatta. Questo architetto, pragmatico, è più probabile che ami discutere di questioni come l’utilizzo della memoria, i requisiti in termini di CPU, le esigenze di larghezza di banda e i vantaggi e svantaggi dell’hyperthreading e del CPU binding.

L’architetto da torre d’avorio si crogiola in una visione mistica dello stato finale della sua creazione, che vanta una perfezione cristallina, laddove l’architetto pragmatico pensa costantemente in termini di dinamica del cambiamento. Come possiamo eseguire un deployment senza riavviare tutto quanto?, Quali metriche abbiamo bisogno di raccogliere e come le analizziamo?, Quale parte del sistema ha più bisogno di essere migliorata?. Quando l’architetto da torre d’avorio ha terminato, il sistema non ammette più alcun miglioramento; ogni parte sarà perfettamente adatta al suo ruolo. Al contrario, la creazione di un architetto pragmatico prevede che ogni componente sia sufficientemente buono per i fattori di stress attuali; e l’architetto sa quali componenti dovranno essere rielaborati, a seconda di come i fattori di stress cambieranno nel corso del tempo.

Conclusione

Il software esprime tutto il suo valore solo in Produzione. Il progetto di sviluppo, il testing, le fasi di integrazione e pianificazione… tutto ciò che viene prima della Produzione è solo un preludio.

Questo articolo riprende parti dal capitolo 1 de L’arte del Rilascio. 

L'arte del Rilascio filettato

Il software in Produzione non è l’arrivo, ma la partenza.

 




Michael T. Nygard è un programmatore e un architetto software con oltre 15 anni di esperienza. Nel corso della sua carriera ha portato in produzione applicazioni per il governo degli Stati Uniti e aziende del settore bancario, finanziario, agricolo e commerciale. Alle sue competenze tecniche unisce ottime capacità di esposizione e per questo è spesso chiamato come relatore in molte conferenze di settore.

Letto 1.250 volte | Tag: , , ,

Lascia il tuo commento