Come pianifichi il tuo codice asincrono?

Progetterei una macchina a stati per ogni insieme di processi collegati e collegati e tengo traccia dello stato da qualche parte in un oggetto di alto livello, quindi è più facile eseguire il debug. È possibile tracciare le transizioni di stato e rilevare transizioni di stato non valide.

Come dice Frank, scrivi una macchina a stati per ogni blocco di business logic che richiede più chiamate asincrone. Quindi, è facile interrogare lo stato durante il debug, perché lo hai enumerato.

In effetti, inizia semplicemente disegnando il diagramma di stato. Se il diagramma è troppo complesso (specialmente se hai diverse chiamate asincrone durante il volo che potrebbero tornare in vari ordini), scrivi come tabella per assicurarti di aver gestito ogni combinazione possibile.

Primo: pianifichi e sviluppi un codice sincrono che funzioni perfettamente da solo. Quindi si isolano le parti che devono essere reinserite e si creano punti di accesso per quelle parti di codice.

Questo approccio è il migliore, perché aggiungerai il meccanismo di sincronizzazione solo su richiesta.

Se hai la possibilità di usare le coroutine (con rese a profondità arbitrarie dello stack di chiamate) o continuazioni, queste ti permettono di scrivere codice asincrono che assomiglia molto al codice sincrono; tutto ciò che una chiamata asincrona deve fare per sembrare sincrono è sospendere l'esecuzione dopo aver effettuato la chiamata e pianificare la ripresa dell'esecuzione per quando la risposta alla chiamata asincrona diventa disponibile. Ciò riduce notevolmente la complessità apparente complessiva. (La complessità in realtà non scompare, ma il linguaggio / runtime gestisce la maggior parte delle parti più complesse, quindi non è necessario.)

È possibile simulare questo genere di cose con i thread. Questo mi lascia sempre un po 'sporco, dato che ritengo che avere molti thread con I / O siano un'indicazione che il design del sistema non è corretto.

In caso contrario, l'approccio migliore è utilizzare lo stile di passaggio continuo in cui dividi il codice in parti sincrone e passa qualsiasi stato condiviso necessario tra di loro (nei periodi in cui stai aspettando per l'elaborazione asincrona per produrre un risultato) utilizzando un oggetto di contesto di qualche tipo. Questo è un po 'imbarazzante da comprendere in astratto: ecco un esempio un po' più concreto. Considera questo codice sincrono (pseudo-):

function DoWork() {
    let A = "foo";
    let B = 1.23;
    Call1(the.arguments);
    A.append(B);
    Call2(the.arguments);
    B += A.length;
}

DoWork();
print "finished";

Se cambiamo questo stile in passaggio continuo, otteniamo qualcosa del genere:

function DoWork(doneCallback) {
    let state = new Context();
    state.A = "foo";
    state.B = 1.23;
    state.done = doneCallback;
    DoAsyncCall1(the.arguments, callback=fn()=>DoMoreWork(state));
}
function DoMoreWork(state) {
    state.A.append(state.B);
    DoAsyncCall2(the.arguments, callback=fn()=>DoneTheWork(state));
}
function DoneTheWork(state) {
    state.B += state.A.length;
    state.done(state.A, state.B);
}

DoWork(fn(…)=>print "finished");

Ogni sezione tra le chiamate asincrone diventa la sua funzione (dovresti anche fare l'inizio di ogni ciclo che hai - purché abbia una chiamata asincrona - essere l'inizio di una funzione in modo da può modellare il ciclo richiamando). Il state che viene passato in giro è la chiave per far funzionare tutto questo ed è possibile (presupponendo un meccanismo di chiamata asincrono non orribile) di avere più insiemi di elaborazione in corso in una volta, poiché ogni parte ne conosce solo la sua piccolo mondo. Tuttavia, è importante cercare di evitare l'uso dello stato globale quando si esegue questa operazione, se per nessun altro motivo ti lascerà molto confuso. È molto più semplice far funzionare tutto questo se si utilizzano tecniche di programmazione in gran parte funzionali.