Le domande da porsi per ottimizzare il codice in React

In quest’ultimo passo del nostro viaggio, parliamo di ottimizzazione delle applicazioni React.

Quando si tratta di front-end, l’attore più lento in ogni processo dovrebbe essere sempre l’utente, l’essere umano che sta interagendo con l’interfaccia. Molto spesso questa cosa è semplice da ottenere, perché i computer sono molto, molto più veloci degli esseri umani.

Quando un’applicazione diventa molto grande, però, può capitare che alcune delle sue parti diventino più lente della persona che le sta usando. Come abbiamo visto in precedenza, i livelli di astrazione che semplificano il ragionamento dei programmatori informatici, peggiorano le performance dei computer.

Le domande da porsi per ottimizzare il codice

Il primo approccio all’ottimizzazione del codice non ha mai a che fare con il codice. Prima di pensare di ottimizzare il codice, possiamo porci una serie di domande che possono portare a risultati ben migliori di quelli che porterebbe codice ottimizzato, intervenendo sulle persone:

1) L’applicazione sta facendo solo ed esclusivamente quello che deve fare, oppure fa altre cose che non servono?

Le cose che non servono hanno, di solito, a che fare con:

• Requisiti che non sono più utili: funzionalità che nessuno usa, o molto pochi utenti usano, il cui codice non è mai stato eliminato.
• Operazioni che sono state delegate al front-end ma potrebbero essere fatte in altri punti dello stack – come il back-end o il database – che sono più ottimizzati per farle. Classici esempi sono la gestione di cache e la paginazione di contenuti, oppure quei casi in cui il backend invia i dati con una struttura completamente diversa da quella che serve al front-end. In questi casi, a seconda del linguaggio di programmazione con cui è scritto il back-end, della potenza del server su cui è installato e dell’esperienza di chi lo sviluppa, potrebbe avere senso spostare calcoli e trasformazioni del formato dei dati sul back-end o sul database.
• Correzione di errori generati da altre parti del sistema: problemi che non sono mai stati risolti, ma quando ne vengono individuati i sintomi vengono corretti sul posto. Per esempio, nelle applicazioni React che usano impropriamente gli effetti collaterali, è facile che gli stati e i cicli di rendering siano desincronizzati. A volte, per mancanza di tempo o semplicemente perché si è perso il controllo degli intrecci di effetti scatenati da altri effetti, la “soluzione” è aggiungere ancora più codice per forzare la sincronizzazione in caso di stati incoerenti o incompatibili.
  

Eliminare il codice di troppo, rivedere i componenti più complessi e spostare la logica nei punti giusti dello stack può aiutare a ottimizzare il sistema.

 2) L’applicazione sta rappresentando la realtà in modo coerente?

Molto spesso, soprattutto quando si implementano molte cose nuove molto velocemente, non si riesce ad avere una visione di insieme di quello che si sta rappresentando.

Questo può portare ad avere strutture di dati molto più complesse di quello che serve, perché costruite “a pezzi” aggiungendo informazioni a quello che si pensava fosse la rappresentazione della realtà.

Svuotare la mente dalle strutture dei dati e tutti i casi possibili che bisogna coprire, per riprendere in considerazione il sistema nel suo intero e la sua rappresentazione, può essere molto utile per “snellire” l’applicazione.

L’altra cosa che aiuta moltissimo in questo caso – e andrebbe fatta a partire dalla prima riga di codice quando l’applicazione è ancora vuota – è il testing (unit testing e end-to-end testing).

3) Ci sono funzionalità che è possibile astrarre e isolare?

Come abbiamo visto con molteplici esempi, isolare funzionalità indipendenti all’interno di funzioni hook ci aiuta ad avere solo:

• Componenti che contengono solo chiamate a funzioni “compilate” con gli argomenti relativi al caso specifico, come nel caso di useForm a cui passiamo solo i nomi dei campi e le funzioni di validazione che abbiamo già a disposizione.
• Componenti che contengono solo rappresentazioni grafiche delle strutture dati che viaggiano all’interno dell’applicazione, come nel caso di Query che gestisce qualsiasi chiamata di rete di tipo query.

Raggiungere uno stato del genere richiede tanto ragionamento astratto e una buona dose di esperienza ma, una volta raggiunto l’obiettivo, è incredibilmente semplice individuare e misurare le performance delle singole funzionalità, per trovare eventuali punti deboli.