Il manuale del mixer del ciclo di vita dell'API: cosa c'è dentro un'unica fonte di verità?

Da: Ariel DiFelice il 9 giugno 2023

Nel barman, il manuale del mixer è una fonte attendibile di informazioni. Questi libri possono contenere centinaia di ricette per cocktail classici, alcuni dei quali potrebbero avere 100 anni, mentre altri potrebbero riguardare drink arrivati ​​sulla scena solo di recente. I manuali del mixer possono anche essere un'ottima fonte di ispirazione per nuove ricette ancora da testare per interessanti aggiunte all'offerta di un bar o di un ristorante. Questo atto di equilibrio nel preservare il vecchio incoraggiando al tempo stesso l'esplorazione del nuovo può fornire una lezione preziosa per lo sviluppo di API nel mondo del software. L'"unica fonte di verità" di un'API è, per molti versi, il manuale del mixer dell'organizzazione del software. Ciò è particolarmente vero quando viene adottato il giusto approccio per garantire che il software rimanga funzionale e performante e offra esperienze che soddisfano i clienti e li inducono a tornare per averne di più.

Anche se potremmo pensare alla mixology e ai mixologist che praticano questa arte come termini relativamente nuovi, il primo uso documentato della parola "mixologist" risale al 1852 e "mixology" seguì poco dopo.

Quanto sono simili il lavoro, la mentalità e le passioni dei mixologist e degli sviluppatori e designer di API? Dai un'occhiata a questa definizione di mixologist e conta tu stesso le somiglianze:

"Il termine 'mixologist' si riferisce a qualcuno che studia la storia delle bevande miscelate, ha un grande apprezzamento degli ingredienti e delle tecniche utilizzate e crea regolarmente bevande miste nuove e innovative... il loro titolo di lavoro implica che svolgano una parte significativa del loro lavoro dietro le scene, creando nuovi cocktail artigianali e dando il loro tocco distintivo ai preferiti esistenti."

I migliori sviluppatori, designer e architetti di API del mondo dovrebbero riconoscere molto di quanto sopra nel proprio lavoro. Hanno un profondo rispetto per il loro mestiere e lo affinano sempre ulteriormente. Cercano di comprendere i gusti e i palati dei loro consumatori. Considerano gli input degli altri stakeholder, testano, ripetono e testano nuovamente le loro creazioni prima di "servire" tali API alla produzione.

Come i mixologist e i baristi (se li consideri due ruoli diversi), ogni professionista lungo il ciclo di vita dell'API dovrebbe comprendere le esigenze dei consumatori, dei clienti e dell'azienda, quindi progettare e sviluppare le proprie API di conseguenza. Una parte essenziale di questo processo è la validazione continua e l’adattamento alle esigenze del mercato.

Le modifiche alle API, anche quelle minori, possono avere effetti a valle significativi. E lo stesso si può dire per le modifiche apportate a un'antica ricetta di cocktail, dove l'aggiunta o la rimozione di un singolo pizzico di questo o quello può cambiare completamente il sapore di una bevanda... così come l'interesse delle persone per essa.

Anche se non esiste un tasso di modifica "standard" delle API da pianificare, è possibile che siano necessarie modifiche con ogni nuova versione del software. Ciò potrebbe significare che le modifiche vengono apportate (e devono essere testate e convalidate) ogni poche settimane, ogni mese o anche ogni giorno, a seconda della cadenza di rilascio. Possono essere apportate anche modifiche ad hoc in base alle necessità.

Ciò che è fondamentale per i team garantire è che queste modifiche non interrompano la funzionalità o le prestazioni di un'API. Per rendere ciò possibile, i team stanno sfruttando sempre più i test dei contratti API per fornire una sorta di rete di sicurezza. Ciò avviene sotto forma di test che convalida le modifiche rispetto a un "contratto" che descrive in dettaglio la funzionalità originale, concordata e, quindi, richiesta di un'API.

La capacità di prevedere gli impatti delle modifiche alle API può dipendere dalla maturità di un team di ingegneri e dalla sua capacità di collaborare tra dipartimenti, fusi orari e diversi livelli di competenza tecnica. Strumenti e linee guida che promuovono la standardizzazione e la collaborazione possono impedire che gli incidenti trascurino o siano ciechi rispetto agli effetti negativi a valle.

Che si tratti di potersi fidare di un'unica fonte di verità per la versione più aggiornata di un'API pubblicata o per l'ultima edizione del manuale di un mixer per ricette di bevande collaudate, una documentazione chiara e concisa è fondamentale. chiave. Ma non è nemmeno sufficiente che questa documentazione esista semplicemente.