You may implement this later: Cofunctors as partial implementations

Nel mondo dell'ingegneria del software, costruire un sistema spesso sembra simile all'assemblaggio di una macchina complessa dove ogni ingranaggio deve essere scelto prima che venga stretto il primo bullone. Gli ingegneri affrontano frequentemente un dilemma: devono progettare la struttura complessiva di un programma, come un database o un servizio di rete, ma non possono ancora decidere i dettagli specifici, come quale motore di archiviazione utilizzare o come gestire la replica dei dati. I metodi tradizionali per gestire questa incertezza solitamente prevedono di bloccare un unico insieme di scelte per l'intero sistema all'inizio, o di aspettare fino alla fine per riempire gli spazi vuoti. Ciò crea un processo rigido in cui il percorso da seguire è fissato molto prima che la destinazione sia chiaramente definita. La sfida consiste nel trovare un modo per costruire sistemi che possano evolversi, dove le decisioni prese all'inizio possano naturalmente plasmare le opzioni disponibili in seguito, senza costringere il programmatore a impegnarsi in una soluzione finale prematuramente.

Un ricercatore dell'Università di Oxford ha proposto un nuovo modo di intendere questo problema, utilizzando un concetto matematico chiamato cofunttore per descrivere come il software possa essere costruito a stadi. L'idea centrale è quella di trattare un sistema software non come un prodotto finito, ma come una collezione di obblighi e scelte che cambiano man mano che il sistema cresce. Immaginate la pianta di una casa che parte da un contorno di base. Man mano che l'architetto aggiunge una nuova stanza, la pianta non si limita a diventare più grande; aggiorna anche l'elenco dei materiali necessari. Se l'architetto decide di aggiungere un secondo piano, la pianta potrebbe ora richiedere una fondazione più robusta, una scelta che non era rilevante quando la casa era solo a un piano. Questo nuovo approccio permette agli ingegneri di portare questi elenchi in evoluzione attraverso il processo di progettazione, assicurando che ogni nuova decisione sia compatibile con quelle precedenti, pur lasciando aperti i dettagli finali per un momento successivo.

L'articolo sostiene che gli strumenti esistenti per la gestione delle configurazioni software siano spesso troppo rigidi. Essi richiedono tipicamente che un insieme globale di parametri venga definito sin dall'inizio, il che significa che il sistema non può adattarsi facilmente se emerge un nuovo requisito durante lo sviluppo. Ad esempio, scegliere di archiviare i dati in un certo modo potrebbe successivamente forzare una decisione su come replicare tali dati attraverso diversi server, ma i metodi standard faticano a collegare queste due decisioni in modo dinamico. L'autore suggerisce che, vedendo un sistema software come una "implementazione parziale", dove lo stato attuale del sistema determina quali scelte siano disponibili successivamente, possiamo creare un processo di ingegneria più flessibile. Non si tratta solo di posticipare le decisioni; si tratta di strutturare il sistema in modo che l'atto di prendere una decisione aggiorni naturalmente il menu delle opzioni per la successiva.

Per dimostrare ciò, l'autore utilizza l'esempio di un sistema di archiviazione dati. Inizialmente, il sistema potrebbe essere definito semplicemente come un luogo dove conservare i dati. A questo stadio, l'ingegnere non ha ancora deciso se utilizzare un database locale, un servizio remoto o un formato di file specifico. Man mano che il design progredisce, l'ingegnere potrebbe aggiungere un requisito per la persistenza dei dati, il che significa che essi devono sopravvivere ai guasti di alimentazione. Questo nuovo requisito aggiorna lo stato del sistema, introducendo un nuovo set di scelte riguardanti la durabilità. Successivamente, se l'ingegnere decide di replicare i dati in più località per sicurezza, il sistema si aggiorna nuovamente. Questa seconda modifica potrebbe introdurre un requisito per un protocollo di transazione, un dettaglio che non esisteva quando il sistema era un semplice deposito. La bellezza di questo approccio è che il sistema controlla automaticamente eventuali conflitti. Se l'ingegnere avesse scelto un semplice formato di file che non può gestire le transazioni, il sistema segnalerebbe questo conflitto immediatamente quando viene aggiunto il requisito di replica, invece di attendere che il codice venga scritto e fallire in seguito.

Il ricercatore mostra che questo metodo consente la creazione di piani di migrazione eseguibili. Invece di scrivere solo un elenco di requisiti, il sistema può generare un piano passo dopo passo su come trasformare un deposito di base in uno complesso e replicato. Questo piano può essere costruito in fasi, dove ogni passaggio è verificato rispetto allo stato attuale del sistema. Se un passaggio viene saltato o eseguito fuori ordine, il sistema può rilevare l'errore. Ad esempio, un piano che tenta di replicare i dati prima di creare un archivio duraturo verrebbe rifiutato perché la fondazione necessaria non esiste ancora. Ciò garantisce che il sistema finale sia costruito su un percorso logico solido, dove ogni cambiamento è coerente con la cronologia dei cambiamenti precedenti.

Una delle scoperte chiave è che questo approccio non richiede all'ingegnere di elencare in anticipo ogni possibile stato futuro del sistema. In molti metodi tradizionali, è necessario definire preventivamente tutte le possibili configurazioni, il che può essere travolgente e porta spesso a un'esplosione combinatoria di opzioni. Qui, il sistema traccia solo gli obblighi che sono attualmente attivi. Man mano che vengono aggiunti nuovi requisiti, appaiono nuove scelte, e man mano che i vecchi requisiti vengono soddisfatti, essi scompaiono. Ciò mantiene la complessità gestibile. L'autore osserva che, sebbene il framework matematico dietro questa idea sia sofisticato, la sua applicazione pratica è diretta: fornisce semplicemente un modo per gestire il flusso delle decisioni rispettando le dipendenze tra di esse.

L'articolo affronta anche il motivo per cui questa idea non è stata ampiamente adottata in precedenza nella programmazione. Il termine "cofunttore" è stato storicamente confuso con altri concetti, portando a una mancanza di chiarezza sulla sua utilità specifica. Inoltre, i precedenti tentativi di risolvere problemi simili, come quelli relativi agli aggiornamenti dei database o alla programmazione modulare, si sono spesso concentrati su aspetti diversi, come il mantenimento della coerenza dei dati o la fusione di moduli di codice, piuttosto che sull'evoluzione dinamica delle scelte di implementazione. L'autore suggerisce che, riformulando i cofunttori come uno strumento per l'implementazione parziale, il concetto diventa molto più accessibile e direttamente applicabile al lavoro quotidiano degli ingegneri del software.

In definitiva, il lavoro offre una nuova prospettiva su come costruiamo sistemi complessi. Suggerisce che il modo migliore per gestire l'incertezza non sia congelare il design o lasciarlo completamente aperto, ma creare una struttura in cui il design evolva naturalmente. Trattando il software come un documento vivente di scelte e obblighi, gli ingegneri possono costruire sistemi che siano robusti, adattabili e più facili da ragionare. Il risultato è un metodo che permette l'assemblaggio di sistemi intricati lasciando i dettagli concreti e finali per il momento in cui sono realmente necessari, garantendo che il percorso intrapreso sia sempre logico e coerente.